Novell ZENWORKS 10 CONFIGURATION MANAGEMENT SP3 - COMMAND LINE UTILITIES REFERENCE 10.3... Technical manual

Novell®
www.novell.com
novdocx (en) 16 April 2010
AUTHORIZED DOCUMENTATION
System Planning, Deployment, and Best Practices Guide
ZENworks ® 10 Configuration Management SP3
10.3
March 30, 2010
System Planning, Deployment, and Best Practices Guide

novdocx (en) 16 April 2010
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.
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).

novdocx (en) 16 April 2010
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.

4System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010

Contents 5
Contents
novdocx (en) 16 April 2010
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
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

6System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010
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
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

Contents 7
novdocx (en) 16 April 2010
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
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

8System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010

About This Guide 9
novdocx (en) 16 April 2010
About This Guide
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®ZENworks®10 Configuration Management
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
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 (®, TM, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party
trademark.

10 System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010
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.

ZENworks Configuration Management: A Single Solution for Systems Management
1
11
novdocx (en) 16 April 2010
1
ZENworks Configuration
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®ZENworks®10 Configuration Management
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
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

12 System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010
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
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.

ZENworks Configuration Management: A Single Solution for Systems Management 13
novdocx (en) 16 April 2010
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
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 one-
time 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 user-
based 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

14 System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010
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.

Performing Pre-Design Activities
2
15
novdocx (en) 16 April 2010
2
Performing Pre-Design Activities
A firm understanding of the organization’s business and technical requirements and the existing
infrastructure components that will take part in the Novell®ZENworks®Configuration
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
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.

16 System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010
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.
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?

Performing Pre-Design Activities 17
novdocx (en) 16 April 2010
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)?
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)?

18 System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010
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
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.

Performing Pre-Design Activities 19
novdocx (en) 16 April 2010
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.

20 System Planning, Deployment, and Best Practices Guide
novdocx (en) 16 April 2010