Novell ZENworks®
Advanced Policy Management

Scott C. Villinski

Resource Management Specialist

Novell, Inc.

Ron Tanner

Product Manager

Novell, Inc.

Agenda

Policy-Driven Automation

ZENworks Policy Review

Automating Policy Assignments with DirXML

Demo

Group Policies for Applications

Imaging Policies

Making the Help Desk's Life Easier

Demo

Kiosk Mode Machines

Demo

Session Objectives

Introduce some building blocks for leveraging ZENworks

Think of this as food-for-thought

it is not a best-practices session

Your mileage may vary

but this should help get your farther down the road

Feel free to inject your own ideas

this is an open discussion

Policy-Driven Automation

Value Proposition
of Policy-Driven Automation

An intent, expressed as a statement of actions, acting upon identity, and carried out by automated procedures, that provides a basis for consistent decision making and resource allocation

Automated:

Speeds IT actions = greater responsiveness to changing business conditions

Increases quality of service = increased productivity

Reduced effort = reduced IT costs

Identity:

Securely leverages data from across the enterprise = more powerful decision making

Consistent:

Supports elimination of errors = potential for increased security

Policy

Legacy Automation
vs. Policy-Driven Automation

Legacy automation models allow selection of options associated with manual management actions, with the intent to reduce administrator effort.

Policy-Driven Automation specifies the desired interrelationships among managed resources, with the intent to eliminate administrator effort through continual, automated maintenance.

. . . its about “desired Policy” describing how IT resources of any kind work together!

It's not only about the “desired state” of a workstation. . .

Device Focused vs. Policy Driven

Device Focused

Distribute patch “A” to all PCs in the Paris office

Policy Driven

Someone moving from Order Entry to Sales must have their applications set re-provisioned, and ...

be given access to the new database, but ...

install configuration files “C” & “D” first, and ...

optionally run it from a thin-client for dial up or remote access, and ...

block access to it after business hours, and ...

Resource Management Perspective:
Policy Management

Identity

Management

Integrated Identity

Managed

Resources

Discovery

Federation

Secure Logging & Auditing

Policy

Management

Deployment &

Migration

System Imaging / Cloning

OS Migration

Data Management

Personality Management

Agent Deployment

Hardware pre-config.

Retirement

Data Management

Patch management

OS Config. management.

App distribution

License enforcement

App Config. management.

Data management

User Assistance

Personality management

Usage & Maintenance

Resource Management Perspective:
Managed Resources

Identity

Management

Integrated Identity

Managed

Resources

Discovery

Federation

Secure Logging & Auditing

Policy

Management

Workstations

Servers

Mobile

Laptops

Handhelds

O/S

Software

Web Services

Content

Other

Systems

Mgmt

Other…

ZENworks Policy Review

How are Policies Applied?

Based on this – here are some things to watch out for...

Policies can be assigned to Users, Groups or Containers

Policies can be inherited from containers higher in the tree

Policies can also be directly associated with a resource

Policies can be located anywhere in the tree, and can be assigned to any object in the tree

Naming Standards

Create naming standards and enforce them throughout the directory

Names should describe the policy and the container, group, or object it affects

Remember the 256-character limit in eDirectory for the full distinguished name

Policy Packages:
fundamental best practices

New York Container Package

ZENMSTR2113 Server Package

General UP

Placement

Place policy packages close to the workstations, users, and servers that will be accessing them

Create placement standards for each policy package and enforce them throughout the directory

Policy Packages:
fundamental best practices

O= Cool Company

OU= Portland

OU= ZENworks

OU= Applications

OU=Policies

OU= Workstations

OU= Users

Association and inheritance

Associate policy packages locally (within WAN boundaries)

Associate global policy packages to high level containers (within WAN boundaries)

Associate exceptions to lower containers, groups, or objects

Minimize the use of groups as much as possible

Policy Packages:
fundamental best practices

Global Packages

Exceptions

Global policy packages = packages that apply to 80% or more of the general user/workstation population within a geography or functional unit

Policy Packages:
fundamental best practices

O= Cool Company

OU= Portland

OU= ZENworks

OU= Applications

OU= Policies

OU= Workstations

OU= Users

Association and inheritance

Portland General User Package

Research User Package

Research Group

O= Cool Company

OU= Portland

OU= ZENworks

OU= Applications

OU= Policies

OU= Workstations

OU= Users

Portland General User Package

Research User Package

Research Group

Policy Packages:
fundamental best practices

Association

Association and inheritance

O= Cool Company

OU= Portland

OU= ZENworks

OU= Applications

OU= Policies

OU= Workstations

OU= Users

Portland General User Package

Research User Package

Research Group

Policy Packages:
fundamental best practices

Association

Association and inheritance

Association

Policy Packages:
fundamental best practices

Which policies will affect users in the research group?

Association and inheritance

O= Cool Company

OU= Portland

OU= ZENworks

OU= Applications

OU= Policies

OU= Workstations

OU= Users

Portland General User Package

Research User Package

Research Group

Association

Association

Policy Packages:
fundamental best practices

Portland General User Package

Dynamic Local User Policy - 1

Remote Control Policy - 1

Windows Desktop Preferences Policy - 1

Windows Group Policy - 1

Associated to site OU

Association and inheritance

Policy Packages:
fundamental best practices

Portland General User Package

Research User Package

Dynamic Local User Policy - 1

Remote Control Policy - 1

Windows Desktop Preferences Policy - 1

Windows Group Policy - 1

Windows Desktop Preferences Policy - 2

Windows Group Policy – 2

Associated to site OU

Associated to research group

Association and inheritance

Windows Desktop Preferences Policy - 2

Policy Packages:
fundamental best practices

Portland General User Package

Research User Package

Research Group

Dynamic Local User Policy - 1

Remote Control Policy - 1

Windows Desktop Preferences Policy - 1

Windows Group Policy - 1

Windows Group Policy – 2

Associated to site OU

Associated to research group

Effective Policies

Association and inheritance

Windows Desktop Preferences Policy - 2

Policy Packages:
fundamental best practices

Portland General User Package

Research User Package

Research Group

Dynamic Local User Policy - 1

Remote Control Policy - 1

Windows Desktop Preferences Policy - 1

Windows Group Policy - 1

Windows Group Policy – 2

Associated to site OU

Associated to research group

Effective Policies

Association and inheritance

Policy Packages:
fundamental best practices

Portland General User Package

Research User Package

Research Group

Dynamic Local User Policy - 1

Remote Control Policy - 1

Windows Desktop Preferences Policy - 1

Windows Group Policy - 1

Windows Desktop Preferences Policy - 2

Windows Group Policy – 2

Associated to site OU

Associated to research group

Effective Policies

Association and inheritance

Policy Packages:
fundamental best practices

Portland General User Package

Research User Package

Research Group

Dynamic Local User Policy - 1

Remote Control Policy - 1

Windows Desktop Preferences Policy - 1

Windows Group Policy - 1

Windows Desktop Preferences Policy - 2

Windows Group Policy – 2

Associated to site OU

Associated to research group

Effective Policies

Association and inheritance

Groups and Policies

The Management Agent searches every group that the object belongs to.

Why minimize the use of groups?

Too many groups slows down login times.

Policy of two groups I am a member of is indeterministic

Object

Group

Container

Search Order and Inheritance

Policies?

Portland Container Package

Association

OU= Portland

OU= Maintenance (users)

OU= Accounting (users)

OU= Workstations

OU= Workstations

OU= Exploration (users)

OU= Workstations

OU= Services

OU= Applications

OU= Policies

O= Cool Company

Default search order

Object

Group

Container

Search Order and Inheritance

Policies?

Portland Container Package

Association

OU= Portland

OU= Maintenance (users)

OU= Accounting (users)

OU= Workstations

OU= Workstations

OU= Exploration (users)

OU= Workstations

OU= Services

OU= Applications

OU= Policies

O= Cool Company

Default search order

Object

Group

Container

Search Order and Inheritance

Policies?

Portland Container Package

Association

OU= Portland

OU= Maintenance (users)

OU= Accounting (users)

OU= Workstations

OU= Workstations

OU= Exploration (users)

OU= Workstations

OU= Services

OU= Applications

OU= Policies

O= Cool Company

Default search order

Object

Group

Container

Search Order and Inheritance

Policies?

Portland Container Package

Association

OU= Portland

OU= Maintenance (users)

OU= Accounting (users)

OU= Workstations

OU= Workstations

OU= Exploration (users)

OU= Workstations

OU= Services

OU= Applications

OU= Policies

O= Cool Company

Default search order

eDirectory best practices

Structure at least the top levels of the tree geographically

Partition the tree around WAN boundaries

Use a uniform structure (as much as possible)

Place workstation objects close to the physical workstations

Keep objects used by the workstation (e.g., policy packages, application objects) local to the workstation

Avoid groups if possible

Automating Policy Assignments with DirXML

What's the Benefit
of DirXML and Active Directory Integration?

Leverage dynamic information in eDirectory to provide Policy-driven automation

Active Directory events trigger configuration changes for ZENworks policies

Reduce and/or eliminate redundant tasks performed by administrative staff

Increases productive, flexibility and agility

Changes made in MMC can automate Policy assignment

What DirXML Components
Does ZENworks Provide?

ZENworks 6.5 provides the following components:

DirXML engine

Novell eDirectory driver

Microsoft Active Directory driver

Windows NT driver

Password Synchronization driver

Add-on Components

Nsure Audit – for tracking eDirectory changes

flexible architecture for logging, tracking events

IDM2 for integration with the rest of your environment

http://www.novell.com/coolsolutions/tools/byproduct.html#nsureidentitymanager

ZENworks
in a Pure Windows Environment

Requirements

Synchronize users, groups, and passwords between Active Directory and eDirectory

Benefit

Adding a user to an Active Directory group would trigger assigning Policies to that user from ZENworks

Reduce need for two management interfaces (let DirXML do common management tasks)

Eliminate human errors (user names, etc)

Passwords are synchronized between two systems

Additional Examples
of Leveraging DirXML for Policy Assignment

ZENworks in a Windows environment

Continue to use AD management tools

DirXML provides object and password sync

Assigning User Policies

User policies are cumulative

Assign a generic User Policy to the container

User assigned policy would override inherited container policy

Delegated Administration

Granting necessary rights to a manager for assigning applications

Use something like eGuide or iManager as the interface

Active Directory and DirXML Demonstration

Group Policies for Applications

What's the Benefit of Group Policies?

Understand Group Policies and their interaction with applications

Tools that help manage/create ADM files

Key configuration settings

Locking workstations/users, but still allowing administrators to perform their job

Group Policies Review

Additive Group Policies

Group policies are additive (Users and Workstations)

start with local Windows Policy

applied in reverse order of policy search order

Revision Checking

Track revision of Group Policy

cached Group policy is used, unless revision changes

Group Policy Caching

policy cached to support disconnected mode

Persistent and Volatile Settings

Loopback Support

By default, User policy packages are applied last

Replace

user policies in workstation Group Policy replace User Policy

Merge

user policies associated with User and Workstation policy combined

user policies in ZENworks Workstation policy take precedence over ZENworks User policy

Policy Tools

ADM File Utilities 2.5

http://www.novell.com/coolsolutions/tools/1438.html

decompile/recompile an ADM file

Use Explorer for manipulating

Add new policies

Policy Template File Editor

http://www.novell.com/coolsolutions/tools/1711.html

A free ware tool for creating and editing ADM files

Additional ADM Files

CLIENT 4.9x ADM

http://www.novell.com/coolsolutions/tools/1903.html

Administrative Template for Novell Client 4.9x

Group Policy Template

http://www.novell.com/coolsolutions/tools/1760.html

Track your Group Policy settings with these handy templates

Internet Settings Policy Template File

http://www.novell.com/coolsolutions/tools/1515.html

Expose more of Internet Explorer's settings

Examples of Leveraging Group Policies

University lab machines

unique login

always on

full functionality (based on student's needs)

Kiosk machines

generic login

always on

limited functionality (browser)

Workstation Imaging Policies

What Should I Know
About Imaging Policies?

Registered versus unregistered workstations

Why image an application?

Understanding Add-on Images

ENGL Imaging Toolkit for ZENworks

ENGL

Registered vs. Unregistered Workstations

1st off – they are two different types of policies

Unregistered workstations use Server Policies

Registered workstations use Workstation Policies

Images delivered are based on rules

CPU, Memory, IP address, etc

Registered workstations can also have an image associated to them

Registering workstations gives you more flexibility

can inherit policies form containers or workstation groups, or directly associated

Why Image an Application?

For applications that cross all boundaries, include in the base image (i.e. Office)

Specific department applications should be add-on or NAL delivered

Understanding Add-on Images

Archived collection of files

Target workstation files left intact (unless add-on overwrites them)

Another way to distribute applications

Useful for applications/utilities that don't change often

Can still process registry files with Add-on images

Add-on images still require “processing” the files of the image

i.e. it's another method for getting the files on the workstation

ENGL Imaging Toolkit for ZENworks

Enhanced Imaging

Supports CDROM/DVD, PXE and ZEN partition imaging

Menus (multi-level, display menus based on eDirectory credentials)

Smart Windows Deployment™

Universal base image (1 x base image per operating system)

Sysprep-wrapper (OEM drivers using ZENworks add-on images)

Lights-out Distribution

Multiple schedules, tasks and targets

Schedule imaging (Set Workstation Image Flags, Send WOL)

Smart Windows Deployment with ENGL Imaging Toolkit for ZENworks

See TUT225

Examples

Lab machines/public kiosks

Every night re-image the machines, to help reduce any spyware, etc

Keeps machines in a more known environment

Redeploying an Asset

easily redeploy hardware

start with a clean slate

Making the Help Desk's Life Easier

Making Your Help Desk More Efficient

Reduce potential Help Desk calls by enforcing Workstation and Server policies:

Controlling Rogue Processes

Prohibited File Policy

Inventory Roll-up

Leverage free ware add-on tools that integrate with ZENworks

Controlling Rogue Processes

Track and log the use of rogue processes

Based on findings:

Ignore all rogue processes (allow them to run)

Terminate all rogue processes

Apply an exceptions list

Use Policy to maintain Rogue process management

Prohibited File Policy

Monitor and enforce the deletion or moving of unauthorized files

NetWare®, Linux, Solaris and Windows

Different than typical policies – it's part of Distributed Server Package

associate with a Distribution

Configure paths and files to monitor

Either delete or move files

Inventory Roll-up

A server package that can be inherited or directly associated

Point to the next higher-level server to roll inventory information to

Can cross eDirectory trees

Inventory information speeds up problem resolution

Enable tracking more than just DLL and EXE files during inventory process

i.e. track MP3, MPEG, etc

Don't forget a Dictionary Update Policy

Application Tools

Multiple Application Setting Syncer (MASS)

http://www.novell.com/coolsolutions/tools/1994.html

Recursively iterates through organization Units if they are part of the selection

Can search or search/replace through virtually every setting in an application object

Can set launch/distribution scripts for objects

Can add/update Macros in objects

Checks to ensure only application objects are updated via the Namespace entry

Remote Control Tools

ZENWSBROWSER 4

http://www.novell.com/coolsolutions/tools/1593.html

Get Remote Control to a registered ZfD workstation without using ConsoleOne®

ZenRemoteControlWrapper

http://www.novell.com/coolsolutions/tools/1972.html

Wrapper exe to launch Zen RemoteControl

Reducing Amount of Spyware

Installation and Execution of Spybot Search & Destroy with ZENworks

Significantly reduces Spyware on machines

Not all Spyware will be caught – collection of tools are necessary

http://www.novell.com/coolsolutions/appnote/3590.html

Examples

Remote Control

defining different remote control policies based on users

Auditing remote control usage

Inventory Information

enhanced inventory to track additional file types

real-time diagnostic information

faster problem resolution

Managing Rogue Processes

control which applications are permitted

reduce chances of unapproved application installation

Server Policy Demonstration

Kiosk Mode Machines

Building a Kiosk Machine

Purpose of the Kiosk

Provide public machine

with limited functionality

No user name/password required to use the machine

Minimize any Help Desk involvement

Different components of ZENworks can be leveraged

Workstation policies

Software distribution

Workstation imaging

Group policies

Building a Windows Kiosk

Take one computer

Installed Windows

remove all unnecessary programs/utilities

Patch Windows

Apply Group Policies to lockdown machine

Replace shell with Internet Explorer

1

Building a Windows Kiosk
Take Two

Take one computer

Installed Windows

remove all unnecessary programs/utilities

Patch Windows

Apply Group Policies to lockdown machine

Use Public Web Browser

http://www.teamsoftware.bizland.com/projects.html

2

Examples

Library Internet Terminal

anybody can use the machine

provides only browser support

specific application support (Library search)

Internet Cafe Workstation

may require user authentication

browser support, and additional applications (word processor)

Kiosk Mode Demonstration

ALAN

Need for both!

Zero human processes

Builds intelligence into the system

Invisible to the user

Automates for consistency and repetition

ALAN

ALAN

Your naming standards may be different for each package, but the important thing is that you have a standard and enforce it.

Names should describe the policy and the container, group, or object the policy affects.

Also remember that you do have a limit on the full distinguished name of the policy object.

Here are some examples of policy package names that are descriptive. <click>

- The New York Container Package tells you what physical site the package is associated to and therefore effects. Keeping the Container Package on there helps you know immediately what kind of package it is.

- The ZENMSTR2113 Server Package immediately lets you know that it is a server package and what server it is associated to.

- The General UP tells you that this user package applies to most of the users at a particular site. The abbreviation UP is an agreed upon standard, and therefore lets every administrator know immediately that it is a user package.

The next few slides address some of the fundamental best practices for managing policy packages. Hopefully you will have picked up a lot of these from our discussion about the Container Package. After we go through these, we’ll get into some specifics for each of the other packages in ZENworks for Desktops.

The two most important principles to consider when you’re deciding where to place your policies are:

First, policies should not be accessed across WAN links. The further the management agent has to search, the longer it takes and the more unnecessary WAN traffic. For example, in the portion of the eDirectory tree above (assuming that the geographical OU represents a WAN link), all your policy packages should be located in the OU=Portland or below.<click>

Second, keep things organized. We talked about this already. The easiest way to keep things organized is to create a policies container at each geographical location, but you don’t have to do this. You just need to decide on a standard. For example, if you decide the place the a server package in the same container as the server it will be associated to, make sure that every time anyone in the organization creates a server package, they follow this same standard.

Associate global policies to high level containers (within WAN boundaries)—objects inherit the policies associated to parent containers

Associate exceptions to the global policies to lower containers, groups, or objects

Minimize the use of groups as much as possible

In this example, Cool Company has a group of researchers at the Portland site that need a little more flexibility with their workstations than Cool Company feels like giving the average user. If I were the network administrator in Portland I would take advantage of this (hopefully) already existing <click> Research Group. If the group didn’t already exist, I would check to see that the research users aren’t members of more than one other group, and then create a new group. With that group in place, the I can now create a General User Package that applies to most of the users in the Portland site and a Research User Package that contains the exceptions that apply to the research employees.

The I can then associate the general user package to the Portland OU<click> because it applies to most of the users and the research user package to the research group.<click>

Make the point that you can do this with functional containers, too.

This all leads to a very important question: <click> Which policies will affect the research group?

In this example, Cool Company has a group of researchers at the Portland site that need a little more flexibility with their workstations than Cool Company feels like giving the average user. If I were the network administrator in Portland I would take advantage of this (hopefully) already existing <click> Research Group. If the group didn’t already exist, I would check to see that the research users aren’t members of more than one other group, and then create a new group. With that group in place, the I can now create a General User Package that applies to most of the users in the Portland site and a Research User Package that contains the exceptions that apply to the research employees.

The I can then associate the general user package to the Portland OU<click> because it applies to most of the users and the research user package to the research group.<click>

Make the point that you can do this with functional containers, too.

This all leads to a very important question: <click> Which policies will affect the research group?

In this example, Cool Company has a group of researchers at the Portland site that need a little more flexibility with their workstations than Cool Company feels like giving the average user. If I were the network administrator in Portland I would take advantage of this (hopefully) already existing <click> Research Group. If the group didn’t already exist, I would check to see that the research users aren’t members of more than one other group, and then create a new group. With that group in place, the I can now create a General User Package that applies to most of the users in the Portland site and a Research User Package that contains the exceptions that apply to the research employees.

The I can then associate the general user package to the Portland OU<click> because it applies to most of the users and the research user package to the research group.<click>

Make the point that you can do this with functional containers, too.

This all leads to a very important question: <click> Which policies will affect the research group?

In this example, Cool Company has a group of researchers at the Portland site that need a little more flexibility with their workstations than Cool Company feels like giving the average user. If I were the network administrator in Portland I would take advantage of this (hopefully) already existing <click> Research Group. If the group didn’t already exist, I would check to see that the research users aren’t members of more than one other group, and then create a new group. With that group in place, the I can now create a General User Package that applies to most of the users in the Portland site and a Research User Package that contains the exceptions that apply to the research employees.

The I can then associate the general user package to the Portland OU<click> because it applies to most of the users and the research user package to the research group.<click>

Make the point that you can do this with functional containers, too.

This all leads to a very important question: <click> Which policies will affect the research group?

Group policies in ZENworks for Destkops 4 are cumulative. This means that policies closer to the object will override policies set higher up the tree. However, within the group policy, if there are settings applied at the container level that aren’t applied at the group or object level, the object will still inherit those settings from the container The research group will inherit both group policies.

For example, if the settings necessary for the research group are only slightly different from the settings for general users, you would only have to change those few settings in the group policy in the Research User Package. The research group would then inherit all of the other settings from the Portland General User Package. Or, if the Portland General User Package has many restrictive settings enabled in the group policy that shouldn’t apply to the research group, in the Research User Package, you would have to disable all of those settings (not leave them blank) in order to make sure that the research group didn’t inherit them.

See TID 10081101 for Remote Control effective policies.

See TID 10061572 for how to prevent inheritance, for example, DLU policy

Group policies in ZENworks for Destkops 4 are cumulative. This means that policies closer to the object will override policies set higher up the tree. However, within the group policy, if there are settings applied at the container level that aren’t applied at the group or object level, the object will still inherit those settings from the container The research group will inherit both group policies.

For example, if the settings necessary for the research group are only slightly different from the settings for general users, you would only have to change those few settings in the group policy in the Research User Package. The research group would then inherit all of the other settings from the Portland General User Package. Or, if the Portland General User Package has many restrictive settings enabled in the group policy that shouldn’t apply to the research group, in the Research User Package, you would have to disable all of those settings (not leave them blank) in order to make sure that the research group didn’t inherit them.

See TID 10081101 for Remote Control effective policies.

See TID 10061572 for how to prevent inheritance, for example, DLU policy

Group policies in ZENworks for Destkops 4 are cumulative. This means that policies closer to the object will override policies set higher up the tree. However, within the group policy, if there are settings applied at the container level that aren’t applied at the group or object level, the object will still inherit those settings from the container The research group will inherit both group policies.

For example, if the settings necessary for the research group are only slightly different from the settings for general users, you would only have to change those few settings in the group policy in the Research User Package. The research group would then inherit all of the other settings from the Portland General User Package. Or, if the Portland General User Package has many restrictive settings enabled in the group policy that shouldn’t apply to the research group, in the Research User Package, you would have to disable all of those settings (not leave them blank) in order to make sure that the research group didn’t inherit them.

See TID 10081101 for Remote Control effective policies.

See TID 10061572 for how to prevent inheritance, for example, DLU policy

Group policies in ZENworks for Destkops 4 are cumulative. This means that policies closer to the object will override policies set higher up the tree. However, within the group policy, if there are settings applied at the container level that aren’t applied at the group or object level, the object will still inherit those settings from the container The research group will inherit both group policies.

For example, if the settings necessary for the research group are only slightly different from the settings for general users, you would only have to change those few settings in the group policy in the Research User Package. The research group would then inherit all of the other settings from the Portland General User Package. Or, if the Portland General User Package has many restrictive settings enabled in the group policy that shouldn’t apply to the research group, in the Research User Package, you would have to disable all of those settings (not leave them blank) in order to make sure that the research group didn’t inherit them.

See TID 10081101 for Remote Control effective policies.

See TID 10061572 for how to prevent inheritance, for example, DLU policy

Group policies in ZENworks for Destkops 4 are cumulative. This means that policies closer to the object will override policies set higher up the tree. However, within the group policy, if there are settings applied at the container level that aren’t applied at the group or object level, the object will still inherit those settings from the container The research group will inherit both group policies.

For example, if the settings necessary for the research group are only slightly different from the settings for general users, you would only have to change those few settings in the group policy in the Research User Package. The research group would then inherit all of the other settings from the Portland General User Package. Or, if the Portland General User Package has many restrictive settings enabled in the group policy that shouldn’t apply to the research group, in the Research User Package, you would have to disable all of those settings (not leave them blank) in order to make sure that the research group didn’t inherit them.

See TID 10081101 for Remote Control effective policies.

See TID 10061572 for how to prevent inheritance, for example, DLU policy

Group policies in ZENworks for Destkops 4 are cumulative. This means that policies closer to the object will override policies set higher up the tree. However, within the group policy, if there are settings applied at the container level that aren’t applied at the group or object level, the object will still inherit those settings from the container The research group will inherit both group policies.

For example, if the settings necessary for the research group are only slightly different from the settings for general users, you would only have to change those few settings in the group policy in the Research User Package. The research group would then inherit all of the other settings from the Portland General User Package. Or, if the Portland General User Package has many restrictive settings enabled in the group policy that shouldn’t apply to the research group, in the Research User Package, you would have to disable all of those settings (not leave them blank) in order to make sure that the research group didn’t inherit them.

See TID 10081101 for Remote Control effective policies.

See TID 10061572 for how to prevent inheritance, for example, DLU policy

Ever wonder why Novell is always telling you to avoid groups as much as possible? Or why our consultants may sometimes recommend taking them out of the search order?

Let’s see what happens. <click>

When the workstation logs in, the management agent first checks <click> the workstation for associated policies (if you’re using the default search order).

Then it goes and checks <click> every group and parent group that the workstation belongs to. . . As you can see, the more groups you have, the slower the search, especially if you have a lot of users and workstations logging on at the same time.

The bottom line. . . <click> your users get frustrated with a slow network and they lose productivity time waiting for their workstations to finish logging in.

This doesn’t mean that groups are all bad. But it does mean you need to minimize how much you use them and never create groups that cross WAN boundaries.

One of the benefits of ZENworks and eDirectory is that you can use groups and don’t always have to rely on your container structure to give you the optimum management of your users and workstations. We talked earlier about the lower levels of your eDirectory tree design. Some companies may have all of their workstations or users in one OU in each physical location. In this case, if you wanted a specific policy to go only to your IT administrators, you would need to associate it to a group of users because the user containers aren’t separated by functional unit. The point is to do this sparingly, and whenever possible, use an existing group.

When our consultants recommend to a customer that they take groups out of the search order, it’s usually because that customer has already designed the tree by functional unit, the customer has had no need for groups yet, or the customer has groups that span WAN links. They can add groups back into the search order when they decide they need to use them.

The default search order (which is set in the search policy) goes Object  Groups Containers. The Container Package and the Service Location Package can both only be associated to containers, but all of the other packages can be associated to objects (which may be a user, workstation, server, printer, etc.) or groups as well as containers. <click>

Here we have an example of a geographical OU. In this case, the network administrator chose to organize the tree under the geographical container according to function. The first thing that we need in this example is a container package. <click>

According to the best practices that we just went over, we’ve created the container package in the OU= Policies container and we’ve named it according to the geographical container that we’ll be associating it too. <click> We then associate it with OU= Portland because it is the top level container for this physical location. Now that we have our container package in place, when this little blue workstation in the accounting workstations container authenticates, the ZENworks Management Agent begins searching for policies. <click>

First, according to this default search order, it checks the workstation object for policies associated to it, <click> then in checks all of the groups that the workstation object is a member of, <click> and then it continues on to check the workstation’s container and parent containers. <click> . . . <click> In this example, the search stops at OU= Portland because of the Container Package that we’ve associated to it. Notice also that the management agent doesn’t search for policies associated with OU= Maintenance, or any of these other containers on the left. It follows a straight line all the way up the tree until it hits a search policy that tells it to stop searching.

The workstation object will inherit any policies associated with any of its parent containers or groups—up to the search policy. If you keep this default search order, the policies closest to the workstation object will have preference. This means that if there are differences between policies associated to the workstation object and policies associated to the Portland container. The workstation policies will be enforced, but not the Portland container policies.

Anyone know what would happen if we didn’t have this container package? <click> The management agent would walk all the way up to the root of the tree searching for policies hourly. <click> If you have several hundred workstations logging in at once, this could cause some serious performance issues.

This is important to remember when you are upgrading from an earlier version of ZENworks. If you don’t make sure that all of your container packages for ZEN 2 or 3.x are in place before you extend the schema for ZfD 4, the Novell Client will not look for ZEN 2 or 3.x policies, and you won’t be able to create any new container packages for them.

The default search order (which is set in the search policy) goes Object  Groups Containers. The Container Package and the Service Location Package can both only be associated to containers, but all of the other packages can be associated to objects (which may be a user, workstation, server, printer, etc.) or groups as well as containers. <click>

Here we have an example of a geographical OU. In this case, the network administrator chose to organize the tree under the geographical container according to function. The first thing that we need in this example is a container package. <click>

According to the best practices that we just went over, we’ve created the container package in the OU= Policies container and we’ve named it according to the geographical container that we’ll be associating it too. <click> We then associate it with OU= Portland because it is the top level container for this physical location. Now that we have our container package in place, when this little blue workstation in the accounting workstations container authenticates, the ZENworks Management Agent begins searching for policies. <click>

First, according to this default search order, it checks the workstation object for policies associated to it, <click> then in checks all of the groups that the workstation object is a member of, <click> and then it continues on to check the workstation’s container and parent containers. <click> . . . <click> In this example, the search stops at OU= Portland because of the Container Package that we’ve associated to it. Notice also that the management agent doesn’t search for policies associated with OU= Maintenance, or any of these other containers on the left. It follows a straight line all the way up the tree until it hits a search policy that tells it to stop searching.

The workstation object will inherit any policies associated with any of its parent containers or groups—up to the search policy. If you keep this default search order, the policies closest to the workstation object will have preference. This means that if there are differences between policies associated to the workstation object and policies associated to the Portland container. The workstation policies will be enforced, but not the Portland container policies.

Anyone know what would happen if we didn’t have this container package? <click> The management agent would walk all the way up to the root of the tree searching for policies hourly. <click> If you have several hundred workstations logging in at once, this could cause some serious performance issues.

This is important to remember when you are upgrading from an earlier version of ZENworks. If you don’t make sure that all of your container packages for ZEN 2 or 3.x are in place before you extend the schema for ZfD 4, the Novell Client will not look for ZEN 2 or 3.x policies, and you won’t be able to create any new container packages for them.

The default search order (which is set in the search policy) goes Object  Groups Containers. The Container Package and the Service Location Package can both only be associated to containers, but all of the other packages can be associated to objects (which may be a user, workstation, server, printer, etc.) or groups as well as containers. <click>

Here we have an example of a geographical OU. In this case, the network administrator chose to organize the tree under the geographical container according to function. The first thing that we need in this example is a container package. <click>

According to the best practices that we just went over, we’ve created the container package in the OU= Policies container and we’ve named it according to the geographical container that we’ll be associating it too. <click> We then associate it with OU= Portland because it is the top level container for this physical location. Now that we have our container package in place, when this little blue workstation in the accounting workstations container authenticates, the ZENworks Management Agent begins searching for policies. <click>

First, according to this default search order, it checks the workstation object for policies associated to it, <click> then in checks all of the groups that the workstation object is a member of, <click> and then it continues on to check the workstation’s container and parent containers. <click> . . . <click> In this example, the search stops at OU= Portland because of the Container Package that we’ve associated to it. Notice also that the management agent doesn’t search for policies associated with OU= Maintenance, or any of these other containers on the left. It follows a straight line all the way up the tree until it hits a search policy that tells it to stop searching.

The workstation object will inherit any policies associated with any of its parent containers or groups—up to the search policy. If you keep this default search order, the policies closest to the workstation object will have preference. This means that if there are differences between policies associated to the workstation object and policies associated to the Portland container. The workstation policies will be enforced, but not the Portland container policies.

Anyone know what would happen if we didn’t have this container package? <click> The management agent would walk all the way up to the root of the tree searching for policies hourly. <click> If you have several hundred workstations logging in at once, this could cause some serious performance issues.

This is important to remember when you are upgrading from an earlier version of ZENworks. If you don’t make sure that all of your container packages for ZEN 2 or 3.x are in place before you extend the schema for ZfD 4, the Novell Client will not look for ZEN 2 or 3.x policies, and you won’t be able to create any new container packages for them.

The default search order (which is set in the search policy) goes Object  Groups Containers. The Container Package and the Service Location Package can both only be associated to containers, but all of the other packages can be associated to objects (which may be a user, workstation, server, printer, etc.) or groups as well as containers. <click>

Here we have an example of a geographical OU. In this case, the network administrator chose to organize the tree under the geographical container according to function. The first thing that we need in this example is a container package. <click>

According to the best practices that we just went over, we’ve created the container package in the OU= Policies container and we’ve named it according to the geographical container that we’ll be associating it too. <click> We then associate it with OU= Portland because it is the top level container for this physical location. Now that we have our container package in place, when this little blue workstation in the accounting workstations container authenticates, the ZENworks Management Agent begins searching for policies. <click>

First, according to this default search order, it checks the workstation object for policies associated to it, <click> then in checks all of the groups that the workstation object is a member of, <click> and then it continues on to check the workstation’s container and parent containers. <click> . . . <click> In this example, the search stops at OU= Portland because of the Container Package that we’ve associated to it. Notice also that the management agent doesn’t search for policies associated with OU= Maintenance, or any of these other containers on the left. It follows a straight line all the way up the tree until it hits a search policy that tells it to stop searching.

The workstation object will inherit any policies associated with any of its parent containers or groups—up to the search policy. If you keep this default search order, the policies closest to the workstation object will have preference. This means that if there are differences between policies associated to the workstation object and policies associated to the Portland container. The workstation policies will be enforced, but not the Portland container policies.

Anyone know what would happen if we didn’t have this container package? <click> The management agent would walk all the way up to the root of the tree searching for policies hourly. <click> If you have several hundred workstations logging in at once, this could cause some serious performance issues.

This is important to remember when you are upgrading from an earlier version of ZENworks. If you don’t make sure that all of your container packages for ZEN 2 or 3.x are in place before you extend the schema for ZfD 4, the Novell Client will not look for ZEN 2 or 3.x policies, and you won’t be able to create any new container packages for them.

Structure at least the top levels of the tree geographically

Partition the tree around WAN boundaries

Use a uniform structure (as much as possible)

Place workstation objects close to the physical workstations

Keep objects used by the workstation (e.g., policy packages, application objects) local to the workstation

Avoid groups if possible

Finally, <click> DO NOT access services across WAN links. Doing so overloads WAN traffic and slows down performance. This is particularly important when you use ZENworks because you more than double the number of objects in your eDirectory tree, and your users and workstations will be accessing services on the network several times a day.

ZENworks Advanced Policies

2003-12-08T12:43:39