Getting the most out of the many features in Novell ZENworks Configuration Management starts with designing and implementing your configuration management infrastructure based on best practices. Attend this session to learn from the experts who wrote the Novell ZENworks Configuration Management Systems Deployment and Best Practices Guide, and make sure your design is ready for the real world.

1. Novell ZENworks ® ®
Configuration Management
Design and Implementation Best Practices
Mark Schouls Andy Philp
Senior Product Manager Product Manager
Novell Inc.,/mschouls@novell.com Novell Inc.,/aphilp@novell.com

2. Agenda
Pre-Design activities
Critical information required for design
Design activities
Deploying Novell ZENworks Configuration
® ®
Management
Best practice recommendations
Question and answer
2 © Novell, Inc. All rights reserved.

3. Pre-Design Activities

4. Pre-Design Activities
• There are several things you want to cover.
– Business Assessment
– Technical Assessment
– Gather other critical information
– Develop a high level design
– Complete the documentation based on the above listed
activities and put it somewhere where people can find it
4 © Novell, Inc. All rights reserved.

5. Business Assessment
• If you do not have a solid understanding of what the
overall business needs you cannot design a solution
that will meet them.
• The best way to handle this is through a set of informal
workshops.
– The idea of the meeting is to inform them enough so they begin
to give you feedback as to how they will leverage the system.
– Remember, the three main reasons you hold these workshops
is to...
> Inform them of what you are doing
> Get their buy-in
> Get their feedback in the form of requirements
5 © Novell, Inc. All rights reserved.

6. Business Assessment
(cont.)
Some ideas on how to perform the business
assessment include:
– Hold informal workshops and invite leaders from each
department to attend.
– Survey departmental leaders and find out what they need in
order to become more effective in their roles – how their staff
can become more effective given what the software you are
deploying does.
> Getting them to answer a written survey can be very effective here and can
give you a lot of detail that can be used when building the high-level, and
more detailed design.
6 © Novell, Inc. All rights reserved.

7. Technical Assessment
• The purpose of the technical assessment is to review what
you have, identify what you need, and document it all.
• The two main outputs from a technical assessment are:
– Documentation on your findings.
– A set of tasks that you will need to perform.
• It is recommended that you perform this after the Business
Assessment.
• The two assessments should take no longer than a week to
perform, depending on the size and/or complexity of the
organization and it's infrastructure.
7 © Novell, Inc. All rights reserved.

8. Technical Assessment
(cont.)
• Know of your existing infrastructure well, before you
introduce ZENworks Configuration Management (ZCM)
®
into the environment.
• Workshops work well!!
• Things you most definitely need to understand include:
– Operating systems which need to be supported.
– Number of users that will need to be supported by the solution.
– Support for roaming users.
– Number of offices/sites, and how many users at each location.
– Locations of all data centers.
– Network architecture with details on links speeds, etc.
8 © Novell, Inc. All rights reserved.

9. Technical Assessment
(cont.)
• If you need to apply any updates to your existing
servers, etc
• Structure of the DNS infrastructure
• Structure of the DHCP infrastructure
• IP subnet design
• Network access methods
• Network infrastructure components and design
• Directory services design
9 © Novell, Inc. All rights reserved.

10. Gather Other Critical Information
• You should also be very familiar with other services that
are running on the network that rely on the
infrastructure as well.
• It would be best to try and prioritize these services so
you can start to better understand bandwidth utilization,
and service levels that have been assigned to specific
functions.
• If the organization is implementing ITIL best practices
you should know about all disciplines that are currently
being leveraged.
10 © Novell, Inc. All rights reserved.

11. Gather Other Critical Information
• Other stuff you should consider exploring and asking:
– Is there a service desk in place?
– Is there an SLA process in place?
– Does a disaster recovery plan exist?
– What about a CMDB?
– Are there formal change management processes in place?
– Are there formal packaging processes in place?
– Do you have a Definitive Software Library in place?
– Any other projects on the go?
11 © Novell, Inc. All rights reserved.

12. Develop a High Level Design
• A high-level design document that outlines the
general placement of services across the company's
infrastructure.
• As a supplement to the high-level design 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 high-level so that everyone can
see what the infrastructure is going to look like once the
deployment is complete
12 © Novell, Inc. All rights reserved.

13. Documentation
• It is important that you develop your documentation and
then discuss this with all parties that have a stake in the
success of this project.
– Documentation is a must-have.
• Discussing the findings and recommendations in detail
are going to be key to the success of this phase of the
project, and the more detailed design phase.
– Incorporate any changes immediately... before you forget!!
13 © Novell, Inc. All rights reserved.

14. Outputs from Pre-Design Activities
• The main outputs include:
– Assessment document – This document highlights all of your
findings from the business and technical assessments that you
performed.
> Requirements gathered during meetings/workshops with department leaders
and others inside the organization that will have an influence on what
services Novell ZENworks will deliver.
® ®
> A detailed summary of your technical findings, and what needs to change in
order to support ZENworks in the infrastructure.
> High-level design information including general placement of services, and
other infrastructure components.
– High-level design diagram – This diagram is used to visually
understand what the infrastructure will look like after the
deployment is complete. This will be refined further.
14 © Novell, Inc. All rights reserved.

15. Critical Information Required for Design

16. Know Everything
• Design criteria
• Scalability of the Primary Server
• Scalability of the Satellite Server
• Considerations for the Database Server
• Virtualization
16 © Novell, Inc. All rights reserved.

17. Scalability of the Primary Server
Factors Influencing Scale
• There are a number of factors that directly influence the
scalability of the Primary Server. These include...
– RAM: The majority of operations are performed by two
processes – zenserver and zenloader. These can take up to
approximately 1.2 GB of RAM each.
– Disk I/O: When serving content for applications and updates.
– Other non server-hardware related factors, including...
> Refresh frequency, what are they being utilized for, number of administrators,
frequency, and quantity of uploading content into the content repository,
number of reports that are being run by administrators, and are you utilizing
load balancing.
> There are others, but you get the point.
17 © Novell, Inc. All rights reserved.

18. Scalability of the Primary Server
SuperLab Test – Average Time to Refresh
• The graphic shows scale of the Primary Server under
considerable load. The test shows increasing numbers
of Managed Devices hitting the Primary Server at the
same time during a refresh.
18 © Novell, Inc. All rights reserved.

19. Scalability of the Primary Server
SuperLab Test – Average Time to Download
• The graphic shows scale of the Primary Server under
considerable load. The test shows increasing numbers
of Managed Devices hitting the Primary Server at the
same time downloading 100MB of Bundle content.
19 © Novell, Inc. All rights reserved.

20. Scalability of the Primary Server
SuperLab Test – Administrative Tasks Under Load
• The following results are a series of Administrative
Tasks performed on a server with no load and then with
a load.
Test Name Test De scription Primary Server Under Primary Server Under
No Load Load
BOE Report Run Predefined BOE report - Bundle Deployment Status 15 seconds 18 seconds
(313 pages)
Inventory Report Run canned report “Devices By Machine / Login Name” 7 seconds 8 seconds
Policy Create policy, assign it to 60 devices and perform a Quick 7 minutes 43 seconds 7 minutes 45 seconds
Task on all 60 devices to get policy
Multicast Create Multicast bundle and multicast to 60 devices 4 minutes 20 seconds 4 minutes 27 seconds
Bundle Create an MSI Bundle of Open Office, assign it to 60 25 minutes 30 seconds 1 hour 10 minutes 17
devices and refresh all 60 using a Quick Task seconds
20 © Novell, Inc. All rights reserved.

21. Scalability of the Primary Server
Description of Daily Use Test
• The test environment in the SuperLab consists of the following
components:
– Single server running Windows Server 2003 (64 bit)
– Server hardware – Dell 2950, Quad Core 2.0 MHz, 8GB RAM
– External Microsoft SQL Server 2005 database
• Definition of “Daily Use”
– 24 hour period simulated in 4 hours
– 3 Bundle pushes of 105 chained bundles (30MB to 1KB)
– 1 full and 3 delta inventory scans
– 1 patch distribution
– 4 device refreshes
– 10 devices continually restoring images
21 © Novell, Inc. All rights reserved.

22. Scalability of the Primary Server
Achieving Scalability in the Real World
• Tests are performed in the SuperLab to find the “breaking point” of the
system and it's components, real scalability on the other hand is achieved
through...
– The proper placement of services
– A well thought out design
– The proper configuration of services within the Novell ZENworks
® ®
system itself
• There is a big difference between what we “find” and what we “suggest”.
– For Primary Servers we recommend the following as a starting point:
> Three (3) Primary Servers to – load and fault tolerance
> A dedicated database server
22 © Novell, Inc. All rights reserved.

23. Scalability of the Primary Server
Achieving Scalability in the Real World, (Cont.)
• The recommendations on the previous slide would be
further enhanced by considering the following as well:
– Exclude servers to ensure that certain Primary Servers are
dedicated to specific functions.
– Dedicate a Primary Server as the Novell ZENworks Reporting
® ®
Server.
– A dedicated Primary Server for ZENworks Control Center.
– The use of Satellite Servers for distribution, collection, and local
site authentication.
23 © Novell, Inc. All rights reserved.

24. Scalability of the Primary Server
Achieving Scalability in the Real World, (Cont.)
• Some of the major factors that you need to consider
with ZCM and Primary Servers are the following:
– They can handle between 1,000 and 1,500 concurrent
connections.
– The rule of thumb is a Primary Server for every 3,000 devices
you will register into the Zone.
– A ZENworks Zone will scale to 40,000 devices. This is what has
®
been validated in the SuperLab and what Novell recommends
®
is the upper limit to the Zone size.
24 © Novell, Inc. All rights reserved.

25. Scalability of the Primary Server
Achieving Scalability in the Real World, (Cont.)
• It is recommended that Primary Servers and the
Database Server be on the same network.
• It is NOT recommended (typically) that Primary Servers
span any WAN links.
• Network utilization issues will appear quickly, and this is
mainly due to...
– SQL traffic between Primary Servers and the Database server.
– Replication of content in the Primary Servers content repository.
– Potential spanning the WAN by Managed Devices.
25 © Novell, Inc. All rights reserved.

26. Scalability of the Satellite Server
Factors Influencing Scale
• There are a number of factors that directly influence the
scalability of the Satellite Server. These include...
– Physical memory installed on the machine.
– Disk I/O from the requests being handled by the machine.
– What services are being handled by the Satellite Server
> Collection, content, imaging, authentication.
– The number of managed devices that are hitting the server, and
how frequently.
– Frequency of distributions.
– Class of hardware.
– Class of Operating System.
26 © Novell, Inc. All rights reserved.

27. Scalability of the Satellite Server
SuperLab Test Number 1
• This is useful when you begin to estimate how many
Satellite Servers are required.
• Try to calculate estimated load during the design
phase.
Bundle Size Server OS Server OS Workstation OS Workstation OS
(MB) No. of Managed No. of Managed No. of Managed No. of Managed
Devices in Test Devices Successful Devices in Test Devices Successful
6 1004 1004 259 259
10 1004 1004 259 259
25 1004 968 259 259
50 1004 801 259 248
1200
1000
800
600 Server OS
Workstation OS
400
200
0
6 10 25 50
27 © Novell, Inc. All rights reserved.

28. Scalability of the Satellite Server
SuperLab Test Number 2
• The second test shows the results of a Satellite Server
running on a Server OS delivering multiple chained
bundles to connected managed devices.
• This information is very useful when trying to calculate
how much load you can place on the Satellite Server
(with a Server OS) when deploying applications that
are chained together.
Number of Bundle Sizes Total No. of Managed No. of Managed Devices
Bundles Devices Successful
5 10, 15, 20, 25, 30 (in MB) 999 996
4 5, 10, 15, 20 (in MB) 999 996
28 © Novell, Inc. All rights reserved.

29. Scalability of the Satellite Server
SuperLab Test Number 3
• The third test shows the results of a Satellite Server
running on a Workstation OS delivering multiple
chained bundles to connected managed devices.
• This information is very useful when trying to calculate
how much load you can place on the Satellite Server
(with a Workstation OS) when deploying applications
that are chained together.
Number of Bundle Sizes Total No. of Managed No. of Managed
Bundles Devices Devices Successful
5 10, 15, 20, 25, 30 (in MB) 259 259
4 5, 10, 15, 20 (in MB) 259 259
29 © Novell, Inc. All rights reserved.

30. Scalability of the Satellite Server
Achieving Scalability in the Real World
• Once again, tests performed in the SuperLab locate the
“breaking point” of the service.
• We assume the following...
– The Satellite Server running on server-class hardware can
handle up to 1,000 Managed Devices
– The Satellite Server running on workstation-class hardware can
handle up to 250 Managed Devices
• For larger sites (250 devices and beyond)...
– Use multiple Satellites for redundancy and load balancing
• For smaller sites (up to 250 devices)...
– Use your judgment
30 © Novell, Inc. All rights reserved.

31. The Database Server
Scalability
• The main things you need to consider when it
comes to the database server are:
– How many devices are you managing? If the number is
greater than 10,000 then you may want to consider
using Oracle or Microsoft SQL Server.
– Will you be able to utilize clustering technologies to
achieve a higher level of fault tolerance.
> You need more details on the organizational continuity and
availability management plans.
• Novell does not recommend use of the
®
Embedded Sybase database for production use.
– This is a single point of failure and should be avoided.
31 © Novell, Inc. All rights reserved.

32. The Database Server
Scalability (cont.)
• Follow vendor-specific best practices when it comes to
database backup, tuning, and maintenance.
– It is critical that you completely understand the vendors
recommendations and best practices.
– You database administrator(s) need to be very close to this
project.
Database Platform Scope / Number of devices
Sybase (embedded) Testing / Development – not recommended for production use/deployment
Sybase (remote) Production / < 1,500 up to 5,000
Microsoft SQL Server 2005 Production / < 5,000 up to 40,000
Oracle 10g Production / < 5,000 up to 40,000
32 © Novell, Inc. All rights reserved.

33. The Database Server
Backup – Sybase
• One of the most important aspects of Sybase database
maintenance is regular backups of the database files.
• Sybase provides it's own backup tool to do this, and it
is freely available for you to download off of the
Ianywhere website.
– The name of the backup tool is dbbackup.
• Details on the tool can be found here:
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/1000/en/html/dbdaen10/da-dbbackup.htm
33 © Novell, Inc. All rights reserved.

34. The Database Server
Backup – Sybase (cont.)
• Novell does not provide any support for this tool – all
®
issues related to the use of this tool must be logged
with Sybase.
• The Sybase database can be backed either when it is
running or shut down.
– When it is running you will use dbbackup.
– When it is shut down you can perform a simple file copy.
34 © Novell, Inc. All rights reserved.

35. The Database Server
Considerations – Microsoft SQL Server
• The most important aspects of managing and
maintaining your database server that is hosted on a
Microsoft SQL Server are the following:
– You must have the skills in-house, or be readily available to
them (contractor, consultant, or partner) to manage and
maintain the Microsoft SQL Server based on the best practices
that Microsoft outlines for regular database management.
– There must be regular database backup routines in place. This
should also be documented or noted in the design document.
35 © Novell, Inc. All rights reserved.

36. The Database Server
Considerations – Microsoft SQL Server (cont.)
• There must be regular database maintenance routines
in place. This should also be documented or noted in
the design document.
• Considerations for clustering (high availability) of the
database server should be made and documented.
• The organization needs to be familiar with the tools that
Microsoft provides to plan, analyze, and maintain their
Microsoft SQL Server infrastructure.
• Check out Microsoft's website for more details –
there is a wealth of information available to you.
36 © Novell, Inc. All rights reserved.

37. The Database Server
Recommendations – Oracle
• You must rely on the skills of the in-house database
administrator(s) to ensure you are installing, updating,
and maintaining the database properly.
• The individual(s) responsible for the day-to-day
management of the Oracle infrastructure must be
involved in the ZCM deployment project from day one.
• Be familiar with the documents Oracle makes available
on their website.
37 © Novell, Inc. All rights reserved.

38. The Database Server
Database Sizing and Performance
• As a general rule of thumb, Novell has seen that the
®
database size increases at a rate of approximately 1GB
per one thousand (1,000) devices in the zone.
• Best practices around fault tolerance, maintenance,
and performance need be considered alongside the
general calculations for overall database size, and they
are just as (if not more) important.
• For sites with more than 10,000 devices RAID 0+1
(mirror with stripe) is recommended.
38 © Novell, Inc. All rights reserved.

39. The Database Server
Database Sizing and Performance (cont.)
• Database servers are very sensitive to disk
performance.
– More smaller disks are always faster than fewer larger disks.
• A single 10GB drive for a 10,000 device site may not
perform adequately, although it may meet the database
sizing formula.
– Ten smaller drives will perform much better.
• Testing and monitoring are an essential part of
database configuration.
• It is very important to note that ZCM performs better
with a dedicated database server, and it is not shared
with other database applications.
39 © Novell, Inc. All rights reserved.

40. DNS and DHCP Services
• DNS forward and reverse lookup is properly configured
so that you can resolve servers using both their DNS
name and IP address.
• It helps when workstations are registered in DNS as
well – DDNS required.
• DHCP needs to be properly configured for imaging
purposes.
• PXE may need to be enabled on workstations.
40 © Novell, Inc. All rights reserved.

41. Time Synchronization
• Everything has a time stamp.
– Ensure everything is time synchronized, it's important.
• All servers in your zone must have time
synchronization configured. It is not needed for
devices but it is recommended to ensure a well
tuned infrastructure.
• For Novell eDirectory customers it may be an
®
™
option to point the ZCM servers to eDirectory
Time Sources via NTP. Usually all clients use
the same time sources via the Novell Client, so ®
the system will be in complete harmony.
41 © Novell, Inc. All rights reserved.

42. Virtualization
• Remember to plan your installation carefully, and
allocate the right amount of resources if you are going
to install in a virtualized environment.
• Currently Novell supports the following platforms:
®
– XEN
– VMware ESX
– VMware Workstation
– Microsoft Virtual Server
42 © Novell, Inc. All rights reserved.

43. Design Activities

44. Design Activities
• This is where you will spend the bulk of your “planning
and testing” time.
– You will build your design (how and what) and validate it in a lab
setting to ensure you have built everything correctly and nothing
is missing.
– We will once again stress the importance of solid and accurate
documentation to back up all of the decisions you have made.
• It is estimated that you will spend approximately 80% of
your time in this planning and testing phase, and the
remainder of your time will be spent on pilots and the
wider deployment where you simply are executing
against your plan.
44 © Novell, Inc. All rights reserved.

45. Design Activities
(cont.)
• Just because we stress the need for proper design
activities does not mean that this is, or needs to be
complex.
– It is just good project management in action.
– Once again, you want to be successful the first time and avoid
the need for major design changes after the deployment has
started.
This could be very disruptive for your end users.
45 © Novell, Inc. All rights reserved.

46. Design Activities
(cont.)
• Three recommendations need to be made:
– Hold design workshops with everyone involved, and those that
have say in how things need to look and feel – these provide
tremendous value and keep the project organized and running.
– Go through every aspect of what the system will look like, and
all of the features you will leverage.
> Document everything along the way.
– Test everything in a lab environment – your use cases, features,
functions, etc., etc.
> This does not need to be physical machines – leverage virtualization
capabilities to create your lab.
> Keep you lab running well after the project – you never know if you'll need it
again, and it can provide a lot of testing value down the road (and time).
46 © Novell, Inc. All rights reserved.

47. Deploying ZENworks Configuration
®
Management

48. Steps to a Successful Deployment
• The steps are straight forward – if you follow these
simple steps you will increase your level of success.
– Pre-deployment planning
– Pre-deployment documentation
– Pre-deployment testing
– Pilots
– Migration (if applicable)
– Wider deployment
– Post-deployment documentation and validation
48 © Novell, Inc. All rights reserved.

49. Best Practice Recommendations

50. Zone Settings
• The topics we will cover today include:
– Organized Management
– Content Replication
– Device Management
– Event and Messaging
– Infrastructure Management
– Inventory
– Licensing and administration
50 © Novell, Inc. All rights reserved.

51. Organized Management
• Folder Structures
– Functional or geographical?
• Static and Dynamic Groups
51 © Novell, Inc. All rights reserved.

52. Folder Structures
• Organize your Bundles in folders, use registration
rules/keys, and avoid dumping everything in one place
– be organized and you'll thank us later.
• Register devices into specific folders (site/location,
department, role, etc.) - decide on what makes the
most sense to you, and stick with it.
• Leverage folder structure for content assignment to
make things as simple as possible.
– User based structure from your User Source.
– Device based structure from what you've created.
52 © Novell, Inc. All rights reserved.

53. Using Groups
• Leverage Device based “Dynamic Groups” whenever
possible. These group memberships are calculated for
you and takes the guessing out of the game.
• Create “Static Groups” if you need to.
53 © Novell, Inc. All rights reserved.

54. Content Replication
• Define by bundle folders
– Good for Patch Management content
• Prioritize content deliver between sites based on type
– Control schedule, length of window and bandwidth consumption
54 © Novell, Inc. All rights reserved.

55. Primary Server Replication
• Take advantage of these settings to specify which
Primary Servers will include or exclude new content by
default.
– ZCM 10 SP3 allows this to be set at the bundle folder
– This could be very useful for complex designs.
55 © Novell, Inc. All rights reserved.

56. Satellite Server Replication
• Once again, same goes for the Satellite Servers as
well.
– This could be useful when you require a very controlled design
and implementation.
56 © Novell, Inc. All rights reserved.

57. Content Replication
• Make sure you set this up according to both your
needs, and policies set by the networking group(s).
– ZCM 10 SP3, ZCM introduces content types
57 © Novell, Inc. All rights reserved.

58. Satellite Server – Offline Replication
• If on-boarding a new remote site, consider content
export features:
– Set content schedule to “None”
– Define content requirements
– <zman ssec> command to export
– <zac cic> command to import
58 © Novell, Inc. All rights reserved.

59. Device Management
• Device refresh schedule
– How often do you need to force updates?
• Disable unnecessary modules
– Different devices have different requirements
• Inventory
– Tracking your assets
• Imaging
– Windows 7 anyone?
59 © Novell, Inc. All rights reserved.

60. Device Refresh Schedule
• In most cases the default
is OK... but modify if
required before you start
registering devices into
the Zone.
– This goes for Full and Partial
60 © Novell, Inc. All rights reserved.

61. ZENworks Agent ®
• Choose whether or not you allow your users to uninstall
the agent.
• Modify settings for individual modules.
61 © Novell, Inc. All rights reserved.

62. Inventory
• Make sure you set this up according to your
requirements.
– A “fresh” install assumes you will set this up, so do not
necessarily accept the defaults.
62 © Novell, Inc. All rights reserved.

63. Imaging
• Embrace “Universal Imaging” in your organization, and
cut down on the overhead involved in managing
multiple images.
– Are you moving to Windows 7?
• Visit the other sessions covering imaging:
– Specifically go see what ENGL have to say in their session:
EM300 - Windows 7 Deployment with Novell ZENworks ® ®
Configuration Management and ENGL Imaging Toolkit
63 © Novell, Inc. All rights reserved.

64. Infrastructure Management
• Closest Server Rules
– Define where devices go for each service type
• System Update Settings
– Define your update strategy
• Event Messaging
– Beware – DB growth!
• User Sources
– Enable user based management
• Satellite Device Roles
64 © Novell, Inc. All rights reserved.

65. Closest Server Rules
• Larger deployments will
always use custom rules.
• Designs with satellite
locations will always use
custom rules.
• The Default Rule may be
OK for small, single-site
implementations.
65 © Novell, Inc. All rights reserved.

66. System Update Settings
• Make sure you set this up according to your
requirements.
• A “fresh” install assumes you will set this up.
66 © Novell, Inc. All rights reserved.

67. System Update Agent
• Get your System Update
settings done before you
start deploying. The
defaults are OK, but may
not work for you.
67 © Novell, Inc. All rights reserved.

68. Centralized Message Logging
• For complex deployments
consider designating a
specific Primary Server as
the Maintenance Server.
– Maybe the ZCC Server.
– Select a few days to clean
up.
– Designate a time... the
default
may not work for you.
68 © Novell, Inc. All rights reserved.

69. User Sources
• ZCM 10 SP3 introduces:
– Satellite Authentication Roles
– Smart card authentication
|
69 © Novell, Inc. All rights reserved.

70. User Sources
(cont.)
• Remember, multiple sources are supported.
• Remember, multiple connections are now supported
70 © Novell, Inc. All rights reserved.

71. Satellite Server Roles
• Remember to specify the role(s) of each of your
Satellite Servers.
– The Authentication Role is
new to ZCM 10.3.
71 © Novell, Inc. All rights reserved.

72. Licensing and administration
• Also found on the “Configuration Page”
– Administrators
– Roles
– License info
72 © Novell, Inc. All rights reserved.

73. Administrators
• Make sure you set administrative accounts early on by
creating them in ZCC or referencing them from either
Novell eDirectory or Active Directory.
®
™
• Don't give everyone “god” privileges in the system. Be
specific with roles (next slide).
• Keep the “Administrator” account under lock and key
and don't give out the password.
73 © Novell, Inc. All rights reserved.

74. Roles
• You need to get specific here.
• Give out only that which they need.
74 © Novell, Inc. All rights reserved.

75. Licenses
• Use this feature to turn on (and off) functionality in
ZCC.
• Excellent feature to only show what you've licensed in
ZCC – avoids any confusion.
75 © Novell, Inc. All rights reserved.

76. Questions and Answers

78. Unpublished Work of Novell, Inc. All Rights Reserved.
This work is an unpublished work and contains confidential, proprietary, and trade secret information of Novell, Inc.
Access to this work is restricted to Novell employees who have a need to know to perform tasks within the scope
of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified,
translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc.
Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.
General Disclaimer
This document is not to be construed as a promise by any participating company to develop, deliver, or market a
product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in
making purchasing decisions. Novell, Inc. makes no representations or warranties with respect to the contents
of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any
particular purpose. The development, release, and timing of features or functionality described for Novell products
remains at the sole discretion of Novell. Further, Novell, Inc. reserves the right to revise this document and to
make changes to its content, at any time, without obligation to notify any person or entity of such revisions or
changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc.
in the United States and other countries. All third-party trademarks are the property of their respective owners.