Required Functionality; Certificate Authority; Management Structure; Application Store - Novell ZENWORKS 10 CONFIGURATION MANAGEMENT SP3 - SYSTEM PLANNING-DEPLOYMENT-BEST PRACTICES GUIDE 10.3 30-03-2010 System Planning Manual

System planning, deployment, and best practices guide
Hide thumbs Also See for ZENWORKS 10 CONFIGURATION MANAGEMENT SP3 - SYSTEM PLANNING-DEPLOYMENT-BEST PRACTICES GUIDE 10.3 30-03-2010:
Table of Contents

Advertisement

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.

Management Structure

With the previous generation of ZENworks, the technology was tied closely to Novell eDirectory
In traditional NetWare
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
®
or eDirectory file and print environments, ZENworks is structured
®
.

Advertisement

Table of Contents
loading

This manual is also suitable for:

Zenworks 10 configuration management sp3

Table of Contents