SMS_ZEN2.doc

Systems Management Server Version 2.0

Scalable Management for Windows® Based Systems

Technical Comparison of Systems Management Server 2.0 and Novell’s ZENworks 2.0

White Paper

Abstract

As information technology progresses and environments become more distributed, administrators

begin to face more challenges in the areas of management. Specifically, the problems surround tasks

like tracking hardware and software, distributing software more quickly and reliably, performing

centralized management using remote diagnostics mechanisms, and controlling which applications are

being used by which users. There are numerous offerings from multiple vendors to help resolve the

management tasks mentioned above— two of which are Microsoft® Systems Management Server 2.0

and Novell’s ZENworks 2.0. If you’re evaluating either of these products to assist in your enterprise

management design, this white paper will serve as a technical guideline in your selection process.

© 2000 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.Microsoft, the BackOffice logo, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.Other product or company names mentioned herein may be the trademarks of their respective owners.Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA0300

Executive summary.............................................................................1

Management Philosophies.................................................................4

Management Philosophy - Novell 4

ZENworks 2.0 Overview 4

Management philosophy - Microsoft 6

Systems Management Server 2.0 Overview 7

Planning tools 8

Deployment Tools 8

Diagnostics Tools 8

Management Philosophy Conclusions 9

Technical Evaluation.........................................................................11

Policy-based Desktop Management 11

Policy-based Management from Novell 11

Policy-based Management from Microsoft 13

Using Policy Management 14

Group Policy in Windows 2000 15

Policy-based Desktop Management Conclusions 15

Hardware Inventory 18

Hardware Inventory from Novell 18

Novell Hardware Inventory in the Enterprise 20

Hardware Inventory from Microsoft 21

Microsoft Hardware Inventory in the Enterprise 22

Hardware Inventory Conclusions 24

Hardware Inventory Conclusions 25

Software Inventory 27

Software Inventory from Novell 27

Software Inventory from Microsoft 28

Software Inventory Conclusions 28

Software Distribution 30

Software Distribution from Novell 30

Contents

Application Launcher 32

Application Explorer 33

Platform Differences 33

Workstation Shell 33

ZENworks Software Reporting 39

Application Report Templates 40

Software Distribution from Microsoft 40

Installer Package Contents 46

Products 46

Features 46

Components 47

Benefits of the Windows Installer Service 47

Software Distribution Conclusions 49

Remote Diagnostics Tools 55

Remote Diagnostics from Novell 55

Remote Diagnostics from Microsoft 55

Remote Diagnostics Conclusions 59

Software Metering 61

Software Metering from Novell 61

Software Metering from Microsoft 61

Software Metering Conclusions 61

Conclusions.........................................................................................64

The responsibility for managing ever more complex and distributed computing

systems has become central to the operation of most contemporary businesses

and is frequently split among a number of Information Technology (IT) groups

such as data center, network support, and desktop support. Each support group

has different responsibilities, but their management tasks fall into seven basic

disciplines. The table below shows where management tools are needed by the

three categories of system administrators. (Of course, some of the jobs of the

three management populations occasionally overlap in some of the disciplines.)

Desktop Managers

Network Managers

Data Center Managers

Change and Configuration Management

Security Management

Performance Management

Problem Management

Event Management

Batch/Output Management

Storage Management

Microsoft’s Systems Management Server and Novell’s ZENworks 2.0 both focus

in the same location on this management table—change and configuration

management for the desktop, specifically the Windows® desktop. Because of

this, the scope of discussion will be limited to change and configuration

management. For more information about these seven management disciplines,

please refer to

http://www.microsoft.com/ntserver/management/Techdetails/Overview/

mgmtoverview.asp.

Both Novell and Microsoft have placed a great deal of emphasis on how they

can help corporations with their change management problems. Novell’s

investment began with Netware Directory Services (NDS) and their release

of Netware version 4. This implementation of X.500 standards has been used by

network administrators to help ease the administration of resources across a

corporation. Recently, Novell has been releasing other products to assist

administrators in change management. These include ManageWise and

ZENworks. ManageWise 2.6 is the latest version and is an application designed

to assist administrators in managing their network and desktops. ManageWise

features include:

SNMP-based network management

Remote desktop control

Hardware and software inventory

Technical Comparison of Microsoft’s Zero Administration Initiative for Windows with Novell’s Zero Effort Networking 1.1

1

Executive summary

Software distribution

Virus protection

Trending and reporting based on discovered data

ZENworks 2.0 was released in July 1999, and is Novell’s newest offering for

change management focusing on the desktop. ZENworks provides:

Policy-based desktop management

Hardware inventory

Software inventory


Remote diagnostics

Software metering

Microsoft’s offerings in change management are similar. Microsoft designed

System Policies for Win32® API-based desktops beginning with the release of

Windows 95 as part of the Zero Administration for Windows initiative (ZAW).

These were extended to the Zero Administration Kit (ZAK) and have also been

integrated into applications like Microsoft Office and Internet Explorer. Along

with this policy-based management, Microsoft has a product called Systems

Management Server, which was designed to assist in providing desktop

management. Microsoft’s recent release of Systems Management Server 2.0

has built upon this foundation and provides:

Hardware inventory

Software inventory


Remote diagnostics

Software metering

Trending and reporting based on discovered data

On the surface, it looks like these offerings are similar in many ways. Because

of this, many users are evaluating both of these products for their change

management system. This paper serves as a guide to individuals who are in this

evaluation process. Because this document focuses on desktop change

management, the specific topics include:

“Roadmap” of each vendor’s management philosophy.

Detailed overview of Systems Management Server 2.0 and ZENworks 2.0.


2

This is followed by a detailed technical evaluation of the following features for

each product:


Hardware inventory

Software inventory


Remote diagnostics

Software metering

It is our belief that to truly address all of the issues that corporations face in

managing their enterprises, Microsoft’s Zero Administration for Windows

initiative, specifically Windows 2000 and Systems Management Server 2.0,

offers a more complete, richer set of features and addresses a greater range of

needs than does ZENworks 2.0.

The table below is a summary of the feature comparisons.

Features ZENworks 2.0 SMS 2.0 (+Windows Policies & Profiles)

Policy management

Hardware inventory

Software inventory


Software metering

Trending and reporting

Management Philosophy - NovellNovell’s management philosophy is fully focused on leveraging their directory as

a management tool. They claim to be the only fully directory-based management

solution on the market. They have made some great strides lately by

announcing NDS developments with such vendors as Cisco, Lucent, Oracle,

and Sun. According to Novell’s Web site, Novell Directory Services (NDS) is a

multiple-platform, distributed database that stores information about the

hardware and software resources available on your network. This could include

user information, machine information, routers and other hardware pieces,

security parameters, and even configuration information for each of these parts.

You can see that Novell views the directory as the single most important

element in managing a network and network resources. Novell has also been


3

Management Philosophies

investing a good deal of time and money to encourage other vendors to use the

Novell Directory Services as much as possible. Novell now claims that there are

over 500 applications on the market that are “directory enabled”, or are designed

to work with NDS. With the recent announcements, this number is growing

quickly. Because of this, every directory-enabled application begins adding more

and more objects to this directory to keep it as the central management tool.

From a technology standpoint, Novell’s management strategy consists of

multiple products. These include:

ZENworks 2.0

ManageWise 2.6

Netware Replication Services (NRS)

ConsoleOne

ZENworks 2.0 and ManageWise 2.6 are at the forefront, but Novell also

recommends using Netware Replication Services (NRS) in some areas of

enterprise management as well. This will be discussed later in the software

distribution section. Novell has also been working on a single Java-based

console applet called ConsoleOne that fits into their future management

software as well. All of these applications use NDS in some way to access and

store information. Netware Replication Services becomes a feature in this

management if you decide to use it to help with the distribution of applications

across an enterprise.

ZENworks 2.0 OverviewNovell shipped version 2.0 of its Zero Effort Networking (ZENworks) product in

July 1999. The goal of ZENworks is to help network administrators reduce the

total cost of ownership (TCO) by providing directory-based management. The

ZENworks product is not new. It began as a bundle of two existing products:

Workstation Manager (WM) and Application Launcher. Novell modified both

these products and added a third to create the ZENworks 1.0 bundle in May

1998. With the addition of software metering and Year 2000 remediation in their

version 1.1 in December 1998, Novell created a product that has gained

popularity with many network administrators. Most notably, the ZENworks

product is gaining acceptance and market share in small to medium-sized

organizations. By adding software inventory, the features of ZENworks 2.0 now

are:


Simple hardware inventory information on desktops

Software inventory based on entries placed in the Software List Editor

Software Installation including application repair


4

Remote desktop control

Software metering for applications run through the Application Launcher

ZENworks is completely dependent on Novell NDS, and will provide varying

levels of management to any Microsoft Windows desktop (Windows 3.1 or later,

Windows 95, Windows 98, Windows NT® 3.51, Windows NT 4.0) running the

latest Netware client. There is no support for Mac or OS/2, and because of the

reliance on NDS, only Novell versions 4.x and 5.x will support ZENworks and

cannot be running in bindery emulation mode. There are three forms that

ZENworks can be acquired in:

ZENworks Starter Pack – Free with Netware versions 4.11 and 5.0.

Contains the user, workstation, printer and RAS configuration features in

Workstation Manager, and the software delivery and repair features of

Application Launcher.

ZENworks Full Product – $59 per node according to Novell’s Web site.

Contains everything above plus remote control, trouble ticket tool, hardware

inventory information, and software metering.

Zero Effort Networking is an initiative like Microsoft’s Zero Administration for

Windows initiative. Zero Effort Networking is really a combination of multiple

products. It starts with ZENworks and ManageWise, but Novell recommends

that you also use other Novell products, such as Netware Replication Services

(NRS), to help support key issues of management. In fact, the September 17,

1999 issue of PCWeek –

(http://www.zdnet.com/pcweek/stories/news/0,4153,1017289,00.html) indicated

that Novell plans to begin branding a host of applications under the Zero Effort

Networking (ZEN) name. The publication claims that, “Novell executives want to

concentrate revenue-generating efforts on the Provo, Utah, company's directory

applications, which it will brand under the ‘Zen’ name to be consistent with its

existing ZENworks management software.” Although Novell calls its

management product ZENworks 2.0, the fact is that it agrees that some of the

pieces of enterprise management, like extensive inventory, don’t belong in NDS,

so they include ManageWise in their Zero Effort Networking direction.

ZENworks 2.0 and ManageWise 2.6 are still significantly out of sync. Novell

might tell you that because both products use NDS in some capacity, they are

“integrated.” This is like saying that two corporations who publish data about

themselves in the telephone book are business partners. Specifically, the

inventories are dramatically different, and the inventory from ManageWise

cannot be used as a basis for delivering software with ZENworks. For example,

you cannot use ManageWise to obtain hardware and software inventory, and

then use ZENworks to distribute drivers for machines with a specific network

adapter or video adapter. Giga agrees when it calls the integration of

ManageWise and ZENworks, “insufficiently integrated for the full value of a

directory and repository management architecture to be realized.” According to


5

http://www.zdnet.com/pcweek/stories/news/0,4153,1017289,00.html

Novell, “ManageWise 2.6 is ready for integration with a future version of

ZENworks, which allows these components to be used simultaneously without

having to choose one over the other.” This means that for right now, users will

have to choose one over the other, or use both in a non-integrated fashion.

Management philosophy - MicrosoftMicrosoft is committed to making the Windows operating system the best-

managed environment and the best environment on which to run enterprise

management solutions. To achieve this goal, Microsoft has four objectives:

Build an infrastructure into Windows that exposes management information

and allows programmatic control.

Provide basic data, security, and configuration management in the operating

system.

Make sophisticated management solutions, such as Systems Management

Server, available.

Integrate with enterprise-management platforms by exposing services and

interfaces that applications can use.

Microsoft has launched an initiative called the Zero Administration for Windows

initiative (ZAW) to meet this challenge. It encompasses many technologies,

some of them already available and some under development. ZAW

establishes a management infrastructure in Microsoft Windows, exposes this

infrastructure, and builds the tools to utilize it. The ZAW includes infrastructure

components such as Windows Management Instrumentation (WMI), which is

based on the industry-standard Web-Based Enterprise Management (WBEM);

management solutions such as Systems Management Server and Microsoft

Management Console; new developments such as policy-based management in

Microsoft Windows 2000; and interfaces for enterprise management vendors.

The ZAW includes the following technologies:

Systems Management Server 2.0.

Microsoft Management Console (MMC).

Windows Management Instrumentation (WMI) and Web-Based Enterprise

Management (WBEM).

Directory Services Administration.

Web-Based Administration of the Windows NT Operating System.

Windows Script Host (WSH).

Policy-based management using System Policies.


6

Zero Administration Kit (ZAK).

The Zero Administration for Windows initiative includes IntelliMirror™

management technologies and Remote Operating System Installation with

Windows 2000. (For more information on these technologies, see

http://www.microsoft.com/windows2000/library/technologies/management/

default.asp) This builds on the existing policy-based management and the new

hierarchical Active Directory™ service included in Windows 2000 to allow for

administration based on extensive enterprise policy. This also includes

integrating basic software distribution into the Windows 2000 platform with self-

repairing applications via the Windows Installer Service. These powerful

features, combined with Systems Management Server 2.0, provide very

compelling management architecture.

Systems Management Server 2.0 OverviewMicrosoft developed Systems Management Server in 1994, starting with version

1.0. Since then, Systems Management Server has evolved, with new features

and industry standards, to reach millions of corporate desktops worldwide. The

current version, Systems Management Server 2.0, includes detailed hardware

inventory, software inventory and metering, software distribution and installation,

and remote troubleshooting tools. These integrated features make Systems

Management Server 2.0 the most scalable way to reduce the cost of change

and configuration management for Windows-based desktop and server

systems. Systems Management Server 2.0 is built on industry-standard

management protocols, which ensure compatibility with complementary

management tools. Systems Management Server 2.0 is tightly integrated with

Microsoft SQL Server™ and Windows NT Server, making it easy to install,

configure, and maintain Systems Management Server in any size network.

Planning tools

Hardware Inventory – Using industry standards, Systems Management Server

automatically gathers hardware inventory data that administrators can use to

plan hardware updates or identify machines capable of running new software

and operating systems.

Software Inventory - Reports every application installed on every PC to help

administrators identify computers with software that is out of date or software

that is not approved.

Software Metering - Tracks and controls application use based on application

name, user, time of day, and license availability.

Compliance Checking - Compares inventory to a predefined list of hardware or

software, which can then be used either to update non-compliant software by


7

http://www.microsoft.com/windows2000/library/technologies/management/default.asp

http://www.microsoft.com/windows2000/library/technologies/management/default.asp

using software deployment or to restrict access by using the software metering

tools.

Deployment Tools

Software Targeting – Allows usage of existing hardware and software

inventory, user and group security information, or infrastructure information such

as IP subnet to target software recipients.

Software Distribution – Automated processes that guarantee software is

available to the targeted machines while not compromising available bandwidth

or slow network links.

Software Installation – Multiple processes that allow software to be installed

on a heterogeneous assortment of desktops while still maintaining security and

consistency, and then returning status reports on successes or failures.

Diagnostics Tools

Remote Control – Allows administrators or helpdesk staff to remotely control

the mouse and keyboard of a user to assist in troubleshooting.

Remote Tools – These include Remote Chat, Remote Reboot, Remote File

Transfer, and Remote Execute, as well as remote network connectivity

verification.

Network Monitor – A tool that helps capture frames directly from the network-

traffic data stream, examine them, analyze ongoing patterns of use, and

diagnose specific network problems.

Network Trace – A tool that provides route connectivity diagrams representing

servers, network devices such as routers and hubs, IP addresses and subnets.

HealthMon – A tool that that provides a central, graphical, real-time status view

of Windows NT 4.0 Service Pack 4 or later and Microsoft BackOffice® servers.

Management Philosophy ConclusionsAs technologies are becoming more integrated into NDS, the size of the NDS

structure is growing substantially. This would be less of an issue if the directory

were incredibly scalable. However, the NDS structure is a very segmented

approach to directory services where small pieces (partitions) are kept in

multiple places across an enterprise. Novell suggests in all documentation that

these partitions should be no larger than 1,500 objects, due to performance

restrictions. This is because the data in the partitions is not indexed; rather, it is

flat table lookups. Consequently, this management strategy is feeding all of this

information into a “perceived” single storage mechanism, which in reality would

be dozens of smaller replicas that have to be managed across an enterprise. An


8

application like ZENworks will at least double the size of the NDS structure and

force administrators to frequently redesign and partition their directory to stay

within these parameters. In fact, in Novell’s own training materials for

ZENworks, step one of its outline to implement ZENworks includes “redesign

your NDS tree.” With ZENworks 2.0, the inventory collected has been

distributed between the directory and a database, which is a step in the right

direction. The impact on an enterprise of using the directory for some inventory

storage can still be significant, however.

Giga Information Group, an e-business consulting company, agrees with using a

directory for desktop configuration policies and a repository for asset inventory,

and has stated that:

“…effective desktop management must be both directory- and

repository-enabled and…the information from both databases must be

accessible by the desktop management tools. If the solution is just

repository-enabled, then it is very difficult to maintain long-term policies

for desktop configuration based on a user's function within the

organization. On the other hand, if the solution is only directory enabled,

then all of the asset inventory data has to be stored in the directory

itself, which quickly leads to a bloated directory, or the scope of data

gathered during the inventory has to be drastically paired down.”

Giga Information Group, “Windows 2000 – The Grim Reaper for SMS?”:

Kriebel, Norbert, February 24, 1999.

Directories need to act as policy and location devices, not management

information stores. Microsoft stores the process-management information locally

on the client, so that the frequent changes that happen on the desktop do not

flood a directory with traffic or information, and the changes can be recorded

incrementally to preserve network performance. This is done through Windows

Management Instrumentation. Management is not a piece of software—it’s a

mindset that needs to be included in all technologies. Microsoft is building the

core management infrastructure into our operating system. The purpose of a

directory in infrastructure utilization is to help individuals find information more

easily. In fact, the first words in the OSI Electronic Directory Service (EDS)

CCITT X.500 recommendations are, “The Directory is a knowledge base and

acts like a phone book for computing networks in which objects have ‘user-

friendly’ names.” This is the premise on which the X.500 standards were

originally created.

Let’s look at the limitations of integrating ZENworks with NDS, using a phone

book as an analogy for the directory:

A bigger phone book with all the data about a business or individual is not

always the best phone book. Certain types of information do not belong in a

directory.

If parts of the phone book must be localized to provide only the information


9

about locations around you, make sure your local phone books can support

enough entries without needing multiple phone books for a single location.

Having a directory that is limited to only 1500 objects per partition does not

lend itself to true enterprise information management.

If a phone book is only used for a few businesses, then it is not as

beneficial. For example, Novell has been encouraging vendors to write

applications that take advantage of NDS, and a few are out there now (of

which a sizeable amount are their own). Compare these results to the

thousands of independent software vendors (ISVs) using the Microsoft

security structure already, and lining up to write applications for Active

Directory tomorrow. In fact, Microsoft announced partnerships with Entevo

Corp., Fastlane Technologies, Inc., and Mission Critical software to develop

applications around the Active Directory that were released with Windows

2000. These vendors are industry leaders in developing advanced directory

management solutions. These tools, combined with joint ventures between

Microsoft and other industry leaders like Cisco, make incredible numbers of

applications available that are Microsoft Active Directory-enabled.

The phone book is only as good as the phone. Without that, the information

is useless. In the context of network operating systems, the directory is not

the end-all component. Directory services are valuable, and that is why

Microsoft put so much effort into Active Directory for Windows 2000, but the

operating system must still perform basic tasks like running mission-critical

applications across the enterprise, and allowing your development staff to

create such applications. In these areas, Novell is playing catch-up.

As addressed earlier, Systems Management Server and ZENworks 2.0 both

focus on change and configuration management for desktop managers.

Throughout this technical comparison, the areas evaluated will be specific topics

that both vendors use as ways to characterize their product offering. These

include:


Hardware and software inventory


Remote diagnostics

Software metering


10

Technical Evaluation

Policy-based Desktop Management

Policy-based Management from Novell

Novell began offering policy-based management for the Win32 platforms

(Windows 95, Windows 98, Windows NT Workstation) in 1999 with the

ZENworks Starter Pack that is free for Netware 4.11 and Netware 5.0 users,

and is included in the full ZENworks 2.0 package. The philosophy behind policy

management in ZENworks is similar to that in Windows NT—a single location

that allows administrators to make rules and have the system enforce them. The

policy process from Novell includes:

All management done through the standard Novell management applet,

NetWare Administrator Utility (NWAdmin).

All policy settings stored in the NDS hierarchy, and then replicated as

needed.

Some settings are dynamically obtained from the client; some require a

login to update changes.

Each policy is specific to an operating system (OS), so if users roam, the

administrator would need to make a policy for them for any OS they may

work on.

Novell has extended the basic system policies that Microsoft developed by

adding features unique to Novell clients as well as some printer and RAS

configuration elements.

Here’s a detailed list, by OS, of what can be done via policy in ZENworks.

These are taken directly from the ZENworks training manual:

Workstation policy packages:

Windows 3.x Workstation package - just specifies files (.com, .bat, .ini, etc)

to download from the network to a desktop.

Windows 95 Workstation package.

Windows 95 Computer Printer - assigns printers/printer

drivers to Windows 95 workstations and installs them.

Windows 95 Computer System - defines applications that are

automatically deployed to Windows 95 workstation.

Windows 95 RAS Configuration - configures a phonebook

entry for a Windows 95 workstation to RAS with.

Windows NT Workstation package.

Windows NT Computer Printer.

Windows NT Computer System.


11

Both Windows NT and Windows 95 Workstation packages.

Novell Client Configuration - all the parameters needed to

configure the Novell client software.

Remote Control - used to specify whether remote control is

allowed for this workstation, as well as visible/audible properties when

being remote controlled.

Restrict Login – restricts which machines a user can or

cannot login to.

Workstation Inventory - Inventory includes operating system,

CPU, RAM, BIOS, drives, buses, services, resources, display (not

available with just the ZENworks Starter Pack—need full ZENworks

product).

User policy packages:

Windows 95 user packages.

Windows 95 Desktop Preferences - control panel icons for

mouse, keyboard, accessibility, schemes, and display - (you set them

here, and they apply to the desktop).

Windows 95 User System Policies - this is Poledit.exe for

user settings, including Zero Administration Kit templates.

Windows NT user packages.

Dynamic Local User - allows you to dynamically create an

NTW local account based on your NDS login, and then remove it upon

logoff.

Windows NT Desktop Preferences and User System Policies

- identical to Windows 95 above.

Windows NT User Printer - printers/drivers assigned by user.

User packages on all systems.

Help Desk - an applet that allows a user to look up a phone

number or e-mail address for help desk personnel and then e-mail them

from this applet if they have MAPI enabled mail.

Remote Control - same as workstation above, but can

administer remote control based on the local user.

Workstation Import - sets rules about how workstation

information is brought into NDS structure.


12

Policy-based Management from Microsoft

Microsoft has had policy management since Windows 95 was first released and

extended it with Windows NT Workstation 4.0 and the Zero Administration Kit.

Although policy management is not a part of Systems Management Server 2.0,

it’s worth investigating the similarities and differences in this area between

Novell and Microsoft. In Windows NT 4.0, the Microsoft System Policy process

looks like this:

Policy Editor Tool

Using Policy Management

Policy management begins with an applet called Policy Editor.


13

An administrator opens this applet and creates a single policy file that has

restrictions for all users, groups, and workstations throughout the enterprise.

These restrictions include items such as registry editing tools and other

system configurations that could be detrimental to the user’s system if the

user makes changes.

These restrictions can also include specifying desktop look and feel, along

with application availability.

These restrictions have been extended to include Office 97 and Internet

Explorer restrictions.

This file is stored on the primary domain controller and then replicated to all

backups to guarantee availability regardless of where a user is

authenticated.

When an administrator changes this file, the natural replication process

updates the file across the enterprise.

The user then picks up the settings upon next login.

Group Policy in Windows 2000In Windows 2000, the administrator uses Group Policy to define user and

computer configurations for groups of users and computers. Administrators can

create a specific desktop configuration for a particular group of users and

computers by using the Group Policy Microsoft Management Console (MMC)

snap-in. The Group Policy settings are contained in a Group Policy Object

(GPO), which is in turn associated with selected Active Directory containers,

such as sites, domains, or organizational units (OUs).

With the Group Policy snap-in you can specify policy settings for the following:

Registry-based policies. Includes Group Policy for the Windows 2000

operating system and its components as well as applications. To manage

these settings, use the Administrative Templates node of the Group Policy

snap-in.

Security options. Includes options for local computer, domain, and network

security settings.

Software installation and maintenance options. Used to centrally manage

application installation, updates, and removal.

Scripts options. Includes scripts for computer startup and shutdown, and

user logon and logoff.

Folder redirection options. Allows administrators to redirect users' special

folders to the network.


14

Using Group Policy, you can define the state of users' work environments once

and rely on the system to enforce the policies you define.

Policy-based Desktop Management Conclusions

The Microsoft and Novell policy-based desktop management solutions are

similar in the following ways:

They are free with the current network operating system.

They control user- and workstation-specific items.

Policy is stored in one location and then replicated as needed.

Policy is OS dependent – different policy for different OS.

However, there are some items that are available through Microsoft policies that

are not available through Novell’s:

Novell now supports extensible policies in ZENworks 2.0. This allows you to

use .ADM files to manage applications like Microsoft Office, Internet

Explorer, and any other customizations you would like to extend to the

Windows Registry that have been existent since the release of Windows 95.

However, there is still a tradeoff with the Novell solution. You should not use

both extensible policies and the hard-coded policies that Novell includes with

ZENworks because, according to Novell’s documentation, you cannot be

sure of the order in which they will be executed, and therefore, which policy

settings will be in effect. Novell has not created a way to bring all templates

together into one and provide a hierarchy for the application of restrictions to

a user or group. Microsoft has done this since Windows 95.

With Novell policy implementations, you have to update code on the clients

to make sure they have the ZENworks-supported client code, if you haven’t

already done so. There are no updates with any Microsoft client code.

With Novell policy implementations, you also have to install software on

each server that you want to function as a ZENworks server. This means

you’d need to visit each 4.11 server and install the Starter Pack to get

started with policy management. (A native 5.0 server could install the starter

pack on initial installation). With the Microsoft solution, there is no extra

software to install.

Novell policy implementations require the extra tasks of the workstation

import policy to get clients into the ZENworks management infrastructure.

With the Microsoft solution, create the policy, assign users and groups, (or

sites, domains, and organizational units in the case of Windows 2000)

and you are ready to go.

If an administrator is not careful, the extensive searching (walking the tree)


15

for policy objects for each user at logon can create excessive LAN traffic.

You’ll notice a few items, such as Workstation Import and Dynamic Local User,

listed in the Novell policy descriptions above that are not included in Microsoft’s

Zero Administration for Windows initiative. The reason these items are not listed

is because they are add-ins that Netware systems need and that a Windows-

based networking architecture does not require. The Workstation Import object

defines how a workstation is brought into the NDS structure to be managed. The

process for this can be tedious because you must create the import object for

the group or user that you want to be able to use ZENworks functionality. That

user then has to logoff and logon again to register with NDS. The administrator

must import all workstations that have registered themselves into NDS, and

each machine requires another logoff and logon to be fully registered into the

ZENworks/NDS structure. As new machines are added across your enterprise,

you have to periodically import the registered PCs into NDS so they can be

managed with ZENworks. This can be done manually, or via a series of scripts.

With the policy implementations in the Microsoft solution, a user need only log

in. No other follow up is needed to enter the user into the management

infrastructure.

The Dynamic Local User object applies only to Windows NT Workstation clients.

This allows you to circumvent the local security authority on a Windows NT

Workstation so that a user account for the local user is created in the local

Security Accounts Manager database upon logon and then, if you so choose,

deleted at logoff. Because there is no integration between the security provided

at the local or PC level on a Windows NT Workstation and at the server level

with Netware/NDS, this keeps Netware administrators from having to maintain

the local Windows NT Workstation account and the Netware server account.

This process does not need to be done in a Windows NT Domain.

Microsoft applauds the efforts that Novell has made in adopting many of the

system policy initiatives that Microsoft has been integrating into operating

systems since Windows 95. This has allowed companies with an installed Novell

base to use many of the Microsoft-designed total cost of ownership reductions

from our Zero Administration for Windows initiative. Overall, you can see that

Novell has done a fine job of integrating existing technology into its Netware

product line to add that level of value to its existing client base. However, you

can see where some of these pieces cost more to set up and configure for your

enterprise.


16

Hardware Inventory

Hardware Inventory from Novell

Novell’s inventory is only available in the full version of ZENworks, and not the

starter pack. The inventory process for ZENworks involves setting up a

workstation inventory policy as stated above and collecting inventory. The basic

inventory components are as follows:

Inventory Scan Programs

Platform-dependent scan programs that determine the hardware and software

configurations of workstations. These scan programs are located on the

ZENworks server, and when executed on the workstations, they collect the

workstations’ inventory information.

Inventory Gatherer

A NetWare Loadable Module (NLMTM) on the inventory server that collates the

hardware and software information, which is sent by the inventory scan

programs. The scan information is stored as temporary files with an .STR

extension.

Inventory Storer

A Java-based component on the inventory server that stores the collected

inventory information (.STR files) from the Inventory Gatherer to the inventory

database.

Inventory Database

A database that functions as a repository of workstation hardware and software

information. In ZENworks 2, the database is a Relational Database

Management System (RDBMS) maintained in Sybase on a NetWare server.

Console

A Windows-based snap-in to the ZENworks Console, NetWare Administrator.

This snap-in starts a Windows program that checks for Java Runtime

Environment (JRE), and starts the requested Java program, which accesses the

database.

You use the Console to access the information.

The Inventory Gatherer and Inventory Storer are located on the same NetWare

server, referred to as the Inventory Server. The ZENworks install program

configures the ZENworks server as the inventory server, by default.

The NetWare server that contains the ZENworks inventory database is referred

to as the Inventory Database Server.


17

Some other details on this process include:

The inventory is divided between the NDS tree and a new Relational

Database Management System (RDBMS) maintained in Sybase. In NDS, a

new object is added for each machine you’ll be inventorying and a few

inventory attributes are stored here, with the rest stored in the Sybase

database.

The inventory includes floppy disk drive, hard disk drive, BIOS, bus, mouse,

keyboard, display adapters, network cards, memory, serial ports, and

parallel ports.

The inventory scan programs for scanning workstations (Windows 95,

Windows 98, Windows NT) also include scanning based on the industry-

standard Desktop Management Interface (DMI) specification version 2.0.

These programs use the Management Interface (MI) of DMI to look for the

hardware and software components installed on the PC. It scans for all

components that are instrumented on the workstation through DMI. The

data collected by these components is stored in the DMI MIF database on

the workstation. The scan programs will query the DMI service layer to

retrieve this information. The DMI data is supported on the Novell Inventory

Database, but to accumulate the DMI data, you need to access the DMI

service layer from the desktop vendor that you are inventorying and then

deploy that service layer to each desktop using the software distribution

capabilities provided by ZENworks 2.0 (see Software Distribution below).

The inventory can then be used for reporting in one of two ways. You can

generate any of the pre-defined hardware and software inventory reports.

Once you run the reports, you can print them from the reporting tool. You

can also connect to the database through any standard ODBC connection

and use any tool supporting ODBC connectivity.

Hardware inventory process


18

Novell Hardware Inventory in the Enterprise

The above section details the inventory-gathering process for ZENworks 2.0, but

there is much more to inventory management than gathering. The way you

handle and distribute inventory across an enterprise is a large part of performing

systems management. The ZENworks 2.0 management of inventory is broken

into four configurations:

Configuration 1: Central Inventory Server - In this type of inventory

configuration, the inventory server components and database are located on

a central NetWare server. This type of configuration is designed for

enterprises of less than 3,000 workstations that are not distributed across a

WAN.

Configuration 2: Multiple Inventory Servers and a Single Database Server -

In this type of inventory configuration, there are multiple inventory servers.

These inventory servers are connected to one inventory database server.

This is for LANs with greater than 3,000 workstations or a WAN with offices

ranging from 5 to 100 workstations where an Inventory Server is local and

reports across the WAN to a central Database Server.

Configuration 3: Multiple Inventory Servers and a Single Inventory

Database-Cum-Inventory Server - In this type of inventory configuration,

one or more inventory server components are connected to the inventory

database, which is also an inventory server. This is used like Configuration

2 above.

Configuration 4: Multiple Inventory Configurations - In this type of inventory

configuration, the organization has multiple inventory servers and database

servers. This scenario is designed for any configuration with more than

10,000 workstations, as well as a WAN environment where any of the

branch locations have greater than 100 workstations. However, multiple

database servers will not share the inventory data across multiple inventory

deployments. The inventory reports that you generate will pertain to a single

inventory database only. If you want to consolidate multiple database

information, follow any one of these methods:

From the NetWare Administrator Console, connect to a

single database. Use the ZENworks Reporting Tool to export data from

each database in the available report format, such as a Comma

Separated Value report. You can then merge the database information

into any database or third-party merge tool.

Use third-party Java Database Connectivity (JDBC) or Open

Database Connectivity (ODBC) tools to generate the database

applications, which read data from the various databases. However,

merging databases at the enterprise level is a complex task.


19

Hardware Inventory from Microsoft

Systems Management Server hardware inventory is easy to configure. Here are

the steps:

Discover resources in your enterprise based on IP settings, Windows NT

user and group settings, or a host of other discovery methods.

Make these resources Systems Management Server resources by having

Systems Management Server automatically configure scripts to do so, or

even push the client pieces automatically in the case of Windows NT.

The Systems Management Server client software is automatically

distributed to the client, including the industry-standards based hardware

inventory agent.

Client agents collect an inventory of the hardware on the client and store the

results on the client.

This information is passed through a client access point (CAP) to the site

database.

Over 200 properties are collected and reported, including details such as:

Number of disk drives.

Type of processor.

Amount of memory.

Operating system.

Monitor and display settings.

Computer name and IP address.

Information about peripherals connected to the resource.

Network type.

BIOS Information.

A history is tracked of all of this inventory information to assist in further

troubleshooting.

Microsoft Hardware Inventory in the Enterprise

Microsoft realizes the value of being able to manage the inventory you’ve

gathered and has therefore put a significant investment into making sure that

SMS 2.0 will scale to the largest enterprises. Customers of over 100,000

workstations have been using SMS 1.2 for years, and with SMS 2.0 they will be

able to support over 300,000 workstations in an enterprise. SMS 2.0 does this

by implementing a Site Hierarchy.


20

Site Hierarchy Model

In the simplest network LAN environment, you can manage your entire

organization as one SMS site. Each LAN should have at least one site and no

site should span more than one LAN. With SMS, you can organize your existing

WAN network into several SMS sites: each site will have an SMS site server,

which is a Windows NT Server computer where SMS has been installed. A site

hierarchy defines the relationship of all of the SMS sites in an organization. The

topmost site in the hierarchy is known as the central site.

In general, management and configuration data moves down the hierarchy from

higher-level sites, and resource and client data move up the hierarchy from

lower-level sites. More specifically, a parent site sends management instructions

and data intended for client distribution down to its child sites. Child sites report

their status (including information about SMS itself and the status of resources

and clients being monitored by SMS) up to their parent sites.

Because SMS summarizes and compresses data that it passes among sites, it

is more efficient to include a hierarchy of SMS sites if your organization has

large networks or networks connected by slow links. After you install a primary

site, you can create a hierarchy by adding child sites, each of which can be

either a primary or a secondary site. SMS bases site classification on whether

the site stores system data.

Primary site

A primary site stores system data (for itself and its sub-sites) in a Microsoft SQL

Server database called the SMS site database. Primary sites have

administrative tools that enable you to manage the site and its sub-sites directly.

The SMS Setup program creates each primary site as a stand-alone site. To

create a hierarchy, you can attach child primary sites to parent primary sites.

Secondary site

A secondary site, which has client computers but lacks an SMS site database

and an SMS Administrator console, passes its data to its parent primary site.

Secondary sites are useful when you have a remote site that will not have an

onsite administrator. You can set up the site in a separate location over a WAN

link and administer it from its primary site.

You add a secondary site directly from the primary site that will serve as the

parent site. Alternatively, you can install the secondary site from the Systems

Management Server 2.0 compact disc at the secondary site server and then

specify the parent site during installation. In either case, you must install the

parent site before you can install the secondary site. Further, you cannot attach

additional sites beneath secondary sites. Because secondary sites cannot

administer sub-sites, a secondary site cannot be a parent site.

Sites are also described by their relationship to other sites in the hierarchy, as

follows:


21

Parent site

A parent site is a primary site that includes at least one other site beneath it in

an SMS hierarchy. Only a primary site can have child sites.

Child site

A child site is a site that reports to a site above it in the hierarchy. SMS copies

all information collected at a child site to the parent site, which in turn reports all

of the accumulated data to its parent site. A primary site can have one or more

child sites, but a secondary site cannot have a child site — it can only be a child

site.

Central site

The central site is the primary site at the top of the hierarchy; it is the one site in

a hierarchy that is not a child to any other site. Therefore, the SMS site

database at the central site acquires the data of the entire hierarchy. The central

SMS site database stores the inventory information for the central site and all its

sub-sites. Lower-level sites always report inventory information up the hierarchy,

all the way up to the central site. So, at the central site, you can view all sites

and discovered resources in the SMS system.

Below is a diagram that illustrates a site hierarchy with four sites. The Chicago

site at the top of the hierarchy is the central site. The NYC and London sites are

both primary sites, and both are child sites of the central site. The Milan site is a

secondary site that is a child site of the London site.


22

Site hierarchy with four sites


23

Hardware Inventory Conclusions

According to research on management done by Northeast Consulting

Resources, Inc (http://www.ncri.com/sms_vs_zen.html), interviewees felt that

inventory and software distribution, were the most important features of a

management package. In addition, NCRI concluded that good inventory

information helps with targeting, and is necessary to distribute software

effectively (see software distribution below). . Novell has improved their

inventory story with ZENworks 2.0 using a database for the majority of the

inventory data, but the inventory features of SMS 2.0 are still superior. Here’s

why:

The ZENworks 2.0 inventory is not based on any levels of industry standard

like CIM and WBEM. It’s a manual scanning process that utilizes different

scan programs for each 32-bit platform (ntscan32.exe and winscan.exe).

Therefore, it is more susceptible to hardware masking, conflicts, and

failures, and is similar to the way the inventory agent worked in the last

version of SMS 1.2. Because SMS 2.0 is based on CIM, it also provides a

much richer set of hardware inventory that is highly extensible to include

anything that is defined by the Distributed Management Task Force (DMTF)

as a CIM schema extension. Being based on non-standard processes,

ZENworks does not provide that level of extendibility and capability.

Even with this new inventory detail in ZENworks 2.0, Novell does not use it

as criteria in software distribution (see software targeting below).

This inventory cannot be used for change management to notify

administrators if memory, hardware, or the like has changed.

From an enterprise standpoint, ZENworks 2.0 will not work for companies

with more than 10,000 desktops. Combining multiple databases for

enterprise asset management is complex, if not impossible, and the

Inventory Database in ZENworks 2.0 is limited to the inventory of 10,000

workstations. SMS 2.0 provides a hierarchical model that allows for granular

management and reporting for localities, and a robust central repository that

can manage upwards of 300,000 workstations.

If you have locations within your WAN that have more than 100

workstations, you must have a local ZENworks database server to handle

the inventory processing. Then your challenge is how to incorporate all of

these separate databases into a single, manageable asset management

resource. The performance over a WAN is also very limited in ZENworks.

According to Novell’s online documentation, even if you have a single server

configuration with no WAN, the database write operation time that it takes

for the Inventory Storer to place the temporary inventory files into the

database can be one minute per workstation. Imagine that level of

performance and traffic over a costly WAN line, especially if you include


24

DMI scan data, which can generate inventory files of 100 KB in size. There

is no compression of this data as SMS 2.0 performs, nor is there any way to

throttle bandwidth of these costly lines during certain times of the day so the

traffic does not effect the processes of your business. With SMS 2.0, there

is a history process at the client, so only the changes in inventory are

reported; this dramatically reduces the impact to a LAN and WAN.

For a disconnected user or a user who is temporarily connected over dial-up

lines, ZENworks 2.0 does not optimize the client to server communications

for the slow link. The scan program is actually invoked from the server as it

was in SMS 1.2, which means the inventory can only be taken when the

client is connected and is run across the connection from the server. In SMS

2.0, even with a disconnected client, the inventory agent runs locally and

can keep a running history of inventory changes to truly reflect how

workstations behave in an enterprise. And, because SMS 2.0 has the

intelligence at the client level to pass only changes in inventory, these small

deltas (changes) are much more efficient over a dial-up connection. Another

dilemma Novell faces is scalability. For example, Novell recommends that

users generally limit partitions in Netware to 1,000 to 1,500 objects.

According to Novell documents (both the readme.txt files for ZENworks and

in the training documentation), just using ZENworks doubles the number of

objects in a container because each workstation will appear as an object, in

addition to existing user and group objects. Now, with Novell’s NDS

replication processes, if you have partitions that are on separate servers,

they will replicate when changes are introduced, and you’ll further stretch

the bounds of existing NDS limitations. Systems Management Server has

proven scalability, with over 100,000 Systems Management Server clients in

production with version 1.2, and scalability testing shows version 2.0

performing with over 300,000 clients in a site.


25

The following table summarizes the features of workstation inventory:

Hardware Inventory Features ZENworks

2.0

Systems

Management Server

2.0

Hardware inventory (some) (full)

Inventory history

Access to all inventory information through

common reporting tools

Inventory based on standards

Inventory used for software distribution (some)

Support for organizations with greater than

10,000 workstations

Optimized for WAN environments

Optimized for disconnected and dial-up

clients

Software Inventory

Software Inventory from Novell

ZENworks 2.0 has added some levels of software inventory, as ZENworks 1.1

did not perform software inventory at all. Software inventory collection is

managed similarly to the hardware inventory collection through the Software

Scan Policy in the Workstation Policy packages.

The functions of the scan programs for software scanning include the following:

Check the existence of the software at the workstations and servers.

Collect information about the application file.

Report information about the scanned software, such as name of the

software and file size.

Check for the software specified in the Inventory Policy associated with the

workstation object in NDS.

Customize the software scanning using the Software List Editor.

Collect Configuration File Information and report the details and contents of

the system files.

The inventory scan programs collect the software information at the managed

workstations based on the applications listed in the Software List Editor and

selected in the Software Scan policy. By default, the Software List Editor


26

contains a description of up to 8,000 software applications. The Software List

Editor maintains the list of applications with their details in a text file

(LDAPPL.INI). This file can contain as many as 10,000 application entries.

Software Inventory from Microsoft

To deliver software inventory, Systems Management Server 2.0 searches for

version resource information on every executable file (by default) on the client

computer. This can be extended to discover any file type on a workstation.

Then, the resource information is organized by manufacturer for ease of

reporting.

Systems Management Server Software Inventory

Software Inventory Conclusions

Microsoft applauds Novell for realizing the importance of software inventory in

an enterprise management infrastructure. However, SMS 2.0 is a better solution

for enterprise-wide software inventory for the following tasks:

Finding unknown applications. If the application is not specified in the

Software List Editor, then the ZENworks scan program will not know it is


27

there. This is very similar to how software inventory was performed in the

previous version of SMS. With SMS 2.0, an administrator can gather

software inventory without knowing what applications to look for, and still

have the ability to track versions

As with hardware inventory, this executable is run from the server. Using

ZENworks, this becomes a problem for all users connected over a slow link

because the entire inventory process must be performed while online. Not

only is this a convenience and productivity issue for users, but also it

increases the chance of failures of connection or data transfer. Systems

Management Server 2.0 runs inventory as a background process, whether

the client is online or offline, and only deltas in the inventory are sent to the

server.

The ZENworks software inventory still cannot be used for software

distribution as SMS 2.0 is. See the Software Distribution section for more

details.

Software Inventory Features ZENworks 2.0 Systems Management Server 2.0

Software inventory

Grouping by manufacturer

Find all .exe files

Inventory files with any extension

Run inventory offline

Access to all inventory info through common reporting tools

Inventory used for software distribution


28

Software Distribution

Software Distribution from Novell

Software Distribution in Netware is divided into a series of components. These

parts are divided further into administrator-side and client-side pieces. The

administrative pieces are a snap-in for NWAdmin to manage Application

Launcher applications, and an application-repackaging tool named snAppShot.

The client-side elements are the Application Launcher window, and an

Application Explorer.

Complex applications use the following process:

Take a clean desktop.

Take an initial picture with the snAppShot utility.

Install software.

Take another picture with snAppShot utility—snAppShot will then compile

differences and save the delta.

Open NWAdmin.

Decide which users get the application based on NDS location.

Assign the application to that group.

Push it to the desktop, application launcher, system tray, or start menu,

force an installation.

User either clicks the icon on the desktop or the application is forced to

install.

Simple applications use the following process:

Make a batch file to install a program, or have the program run from the

network and push the executable file to the client.

Open NWAdmin.

Decide which users get the application.

Assign the application to that group.

Push it to the desktop, application launcher, system tray, or start menu, or

force an installation.

User either clicks the icon on the desktop or the application is forced to

install.


29

Let’s look at the components of this process: Application Launcher, Application

Explorer, and snAppShot.

Application Launcher Snap-In:

Application Launcher snap-in is a Windows DLL that "snaps in" to the NetWare

Administrator utility. The Application Launcher snap-in makes it possible to

create Application objects in NDS trees. Like other objects in an NDS tree,

Application objects contain their own set of properties. These properties give

you a high level of control over the Application object after it has been

distributed to workstations.

For example, you can set up an Application object that both installs software

and then runs the software. Or you could distribute an Application object that

forces the software to run when the user logs in. You can create Application

icons that just install software and then disappear from the desktop. You can

even set up Application objects that are available for a certain period of time or

only on specific days. If your network is a mixture of Windows platforms and

workstation configurations, you can filter applications to run only on the

workstations that meet your criteria.

With the Application Launcher window, each application is assigned to one

executable file. For example, if you want to distribute Microsoft Project through

the Application Launcher Window, you create the snAppShot package and

assign it to project.exe on the server or desktop where it will be installed. The

user runs the executable file through the start menu, system tray, desktop, or

Application Explorer applet, the system checks to see if it’s been installed, and if

it hasn’t been installed, it installs it. From then on, when a user runs Project

through Application Launcher, which performs the check again, confirms it has

been installed correctly and opens the application. If it has been damaged, the

self-repair facility will prompt the user to repair the application by reinstalling it.

Specifically with Windows NT Workstation, the latest version of Application

Launcher can be run as a service so that applications can be installed in the

administrative context without having the local user be a local administrator.

Here’s what the process looks like according to the online help with ZENworks:

Install and Register the Service with a Single Windows NT Server or

Workstation

1.Obtain sufficient rights on the Windows NT Server or Workstation.

2.From a Windows NT Server or Workstation command line, run the

following to install and register the service:

nalntsrv install

By default, the nalntsrv.exe and nwapp32.dll files are copied to the

system32 directory. These two files must reside in the same directory. If


30

older versions of these files already exist, the installation overwrites

them. Once installed, the service registers Application Launcher with the

Windows NT Service Control Manager. The service becomes active

next time the machine is started.

Note: Adding the Start option immediately activates the service after

registration without restarting the workstation. For example, enter

nalntsrv install start

Install and Register the Service Using Workstation Manager 1.0

1.Use an ACU script entry to install and register the service. For

example:

\\<servername>\<volume>\<path>\nalntsrv install

Important: Do not use the start option when installing the service from

Novell's Workstation Manager 1.0.

After doing all of this, you can finally use Application Launcher to install

applications on the workstation under administrative context.

Application Launcher

Application Launcher is one of the user's workstation components that displays

the icons of the Application objects that you set up using the Application object's

Associations page. Application Launcher lets users create personal folders (with

the administrator’s permission), refresh applications, change views, and get

information about folders and applications. Because the application is centrally

managed, users cannot disturb the drive paths of the application.

Application Launcher offers powerful capabilities that let administrators and

users organize into folders the applications that are delivered to them via

Application Launcher. These folders appear in the Application Launcher,

Application Explorer browser view, and on the Start menu.

There are four types of folders that you can use in Application Launcher

Application Folder Object. An Application Folder object is an independent

object to which you associate Application objects. By linking many

Application objects to one Application Folder object, you can manage the

folder path names of many Application objects from one object.

Custom Folder. Custom folders are set up on the Application object's

Folders property page and thus belong exclusively to the Application object.

A custom folder cannot be shared with another Application object. You can

name Custom folders any way you like and set up folders within folders.

Custom folders override any System folders that may exist as the result of

Application object to Container associations.

Personal Folder. Personal folders let users create and name their own


31

folders and place applications delivered by Application Launcher in them.

System Folder. System folders appear in Application Launcher or Explorer

when you associate an Application object with a User, Group,

Organizational Unit, Organization, or Country object and you have not

created any Custom folders for that Application object or associated the

Application object with a linked folder.

If a user is a member of the .applications.city.company Group, and that Group

has applications associated with it, the user sees a folder

called .applications.city.company containing all its associated applications.

Application Launcher runs on Windows 3.x, Windows 95, Windows 98, and

Windows NT.

Application Explorer

Application Explorer provides advanced integration with Windows 95, Windows

98, and Windows NT workstations. In addition to using a special Application

Explorer window, users can also have access to application icons from the

Windows Explorer, Start menu, system tray, or desktop.

As a network administrator, you may wonder whether Application Launcher or

Application Explorer is best to use in your situation.

The Application Launcher is a stand-alone window that appears when you

run the NAL.EXE file. You can store this file on a network server (for

example, SYS:\PUBLIC) and run it from the user's login script.

The Application Explorer is a Windows-based namespace extension that

loads itself when you run the NALEXPLD.EXE file. You can store this file on

a network server (for example, SYS:\PUBLIC) and run it from the user's

login script. Novell recommends using Application Launcher (NAL.EXE) for

workstations running Windows 3.x. For Windows 95, Windows 98, and

Windows NT workstations, Novell recommends using Application Explorer.

Do not run Application Explorer on Windows 3.x workstations.

Platform Differences

Application Launcher runs on all platforms. Application Explorer runs on

Windows 95, Windows 98, and Windows NT, but does not run on Windows 3.x.

Workstation Shell

You can customize the workstation's shell in different ways, depending on which

executable you use.


32

Shell Application

Explorer

Application

Launcher

Can I Replace the Shell? No Yes

Can I Enhance the Shell? Yes No

Can I Show All Local

Applications?

No Yes

Can I Show Personal Folders? Yes Yes

You can also customize placement of application icons on the workstation:

Icon Placement Application Explorer Application Launcher

Application "Window" Yes Yes

Force Run Yes Yes

Start Menu Yes No

Desktop Yes No

System Tray Yes No

Icon Ordering No Yes

SnAppShot

ZENworks snAppShot facility is similar to other snapshot tools available in the

industry. Notable competitors are the Systems Management Server Installer tool

(free with Systems Management Server) and the Seagate WinInstall tool. When

you install a complex application on a workstation, changes are sometimes

made to the workstation, including the Windows Registry, .ini files, file system

files, config.sys and autoexec.bat files, and any other configurations that support

the application. The snAppShot component is like a camera that takes two

"snapshots:" one snapshot of the workstation's pre-installation configuration

state (before you install an application) and another snapshot of the


33

workstation's post-installation state (after you install an application). SnAppShot

then compares the two snapshots and records any differences in an Application

object template file. Two formats are available for the Application object

template: The .aot format (binary) or .axt format (text version). Use the .aot

format for faster Application object creation; use the .axt format if you want to

edit settings in a text editor. snAppShot keeps track of all the files that an

application Setup program installs to the workstation. These files are copied and

stored in a series of .fil files. You use the information gathered by snAppShot

when creating and setting up Application objects in Application Launcher snap-

in. Because the .aot or .axt file contains all application installation changes, you

can set up Application objects knowing that they have the same configuration as

if you had installed an application locally to a workstation.

The substantial improvements to the snAppShot utility came with the release of

version 2.0. These allowed it to copy and delete files, as well as capture deltas.

This turned Application Launcher into more of a general-purpose distribution

facility. Novell claims this allows Application Launcher to distribute operating

system upgrades (specifically Windows 95 on a Windows 3.x machine).

However, this is not an operation that can typically be done with snapshot

technology.

SnAppShot can also do application rollback in case of a failure. The help

documentation reads like this:

When you "roll out" or distribute a complex application using Application

Launcher, changes are made to the targeted workstation. These

changes might include text files (such as config.sys and autoexec.bat),

Windows Registry entries, and .ini files. In addition, application files can

be copied or deleted at the target workstation.

If Application Launcher encounters an error during the distribution

process, it rolls back or reverses all the changes made before the error

and resets the workstation to the state it was in before the distribution

began.

The method Application Launcher uses to roll back changes is simple.

First, it creates temporary files and directories to store files and other

rollback information on the workstation. If the distribution is successful,

those files and directories are deleted. If the distribution encounters an

error, Application Launcher uses the rollback information to restore the

workstation to its original state, and then the rollback information is

deleted. Note: Currently, Application Launcher cannot roll back changes

at a later time, only at the time a distribution error is detected.

Application Launcher distribution happens in the following order:

1. Application file copies or deletions

2. Text file modifications


34

3. Registry modifications

4. .Ini file modifications

5. Shortcuts and icons

When Application Launcher successfully completes each phase of the

distribution, it keeps a record for each distribution phase. If an error is

encountered, Application Launcher then knows what to do to reverse

the changes.

For example, suppose that the application files and text file modification

phases of the distribution are performed successfully. However,

Application Launcher encounters an error during the Windows Registry

modification phase. This triggers the Registry module to roll back all of

its own modifications and also send a message to Application Launcher

that an error occurred during the distribution process. Application

Launcher then uses the previous memory record information to roll back

the text file modifications and the application file changes. Regardless of

success or failure, all rollback information is deleted after processing.

While snAppShot is very powerful, it cannot (this is straight from the ZENworks

help files):

Capture the "logic" of an installation involving choices based on

existing hardware, software, or other settings. For example, if the

application's setup program installs a particular video driver or

modem setting file to a workstation, these settings may not be valid

when transferred to another workstation

Guarantee the impact the Application object will have on all

workstations. Novell recommends that you run snAppShot on a

"clean and representative" test workstation before you make the

Application object widely available. In fact, if there are many

differences between workstations at all, your results with snAppShot

could vary dramatically

Image an entire workstation for disaster recovery purposes. When

snAppShot discovers a workstation, it only saves some information

about the files such as the date, time, and size of the files. It does

not save a copy of all the files on the workstation

The snapshot is taken on a reference machine, so that it can be deployed on

other machines causing the same impact. If an administrator is deploying

Microsoft Office 97 in the enterprise and Office 97 makes many file and registry

changes, an administrator needs to be sure that these changes are going to be

deployed in the same way on every machine, or Office might not be properly

installed on some machines. Every difference between the reference machine

and a target machine adds risk to the snapshot method. SnAppShot supports

environment variables, which allow it to deal with differences such as user


35

names and application directories, but its capabilities will almost certainly break

down when deploying complex applications or changes.

The Application Launcher and snAppShot are not the only components in

software distribution. You also need to do the following:

Target which users and desktops are to receive your application.

Distribute the source code from your central administration point to a point

that is available to the desktops.

Install these bits onto the desktop.

The snAppShot and Application Launcher features discussed above deliver the

installing piece of this puzzle, but let’s look at how ZENworks does targeting and

distribution:

Targeting:

Targeting is done exclusively through the NWAdmin tool, using the objects in

the NDS tree as targets. You can assign an application to a user, a user group,

a machine, a machine group, an organizational unit, or a complete organization.

Once you have the application targeted, you can place restrictions on it so that it

does not install on every machine object or user object within that NDS group.

For example, you can assign an application to a certain NDS group, but limit it

so it does not install on a machine unless it has a minimum amount of free hard-

drive space or system memory. These conditions are checked at installation

time, not against the inventory database. You can select “exists” or “does not

exist” for these conditions. For example, you may not want an application

installed on a machine where another software program exists. Here are all of

the areas you can use as conditions for software installation:

Applications – this checks to see if a certain application object has been

installed by ZENworks. This does not check the software inventory

database, but checks for the application object in NDS.

Disk Space – this checks for a specified amount of free disk space on a

designated drive.

Environmental Variables – this will check for the existence of system

environment variables as designated by the operating system.

Files – this will check for existence of files, files of a certain version, and

files of a certain date.

Memory – this will check for a specified amount of system memory

Operating System – this will check for a specified operating system or a

system later than a certain version.

Processor – this will check for a processor greater than a certain version,

such as Pentium, Pentium Pro, Pentium II, and so on.


36

Registry – this allows checking for the presence of certain specified registry

entries before installing.

Distribution:

Distribution is the term normally used for the overall process. However, the

distribution phase is really just the method of getting the source bits from a CD

or origin server to your destination. Here’s Novell’s description of the process:

Consider the ACME Company, a multi-site organization with four

application servers located in Los Angeles, San Francisco, Portland,

and Seattle:

apps.la.acme

apps.sf.acme

apps.sea.acme

apps.port.acme

The ACME network administrator creates an Application object for

Microsoft PowerPoint in the Los Angeles container called

pwrpnt.apps.la.acme and associates it with John Doe (john.doe). As

long as John stays at the Los Angeles site, he will be able to access

PowerPoint quickly and without spanning the WAN.

Now John travels to Portland, authenticates to the ACME Tree there,

and runs Application Launcher. While he's able to access the

PowerPoint application by virtue of his association, John endures

several hundred miles of WAN links, painfully slow application

performance, and adds long distance connection charges to his

company's phone bill.

To solve this problem, the first thing the administrator does is create

duplicate Application objects at the San Francisco, Portland, and Seattle

sites:

pwrpnt.apps.sf.acme

pwrpnt.apps.sea.acme

pwrpnt.apps.port.acme

Note: There are several ways of duplicating an Application object. You

can export an Application object to an .aot or .axt file and use it as a

reference, or create an Application object based directly on another

Application object in the Tree. Remember that as you duplicate an

Application object, you also need to keep the related application files in

sync. You can do this in one of two ways: 1) copy the application files to


37

the appropriate application servers, or 2) use Novell Replication

Services (NRS) to synchronize the application files on several servers.

Having created duplicate Application objects, John's administrator then

opens the Application Site List property page for the Los Angeles

PowerPoint Application object and links it to the other three. Now when

John launches Application Launcher at any of the other sites, he will

access applications locally.

How an Application Site List Works

The Application Site List feature assumes that John's administrator has

organized the ACME NDS Tree geographically. That is, container object

names reflect the name of a city or town (for example, app.sf.acme).

There's an important reason why the Tree should be organized

geographically:

Suppose that John's administrator links the Los Angeles PowerPoint

Application object, to which John has been associated, to the other

three duplicate Applications objects in San Francisco, Portland, and

Seattle. When John authenticates to NDS, Application Launcher

determines the fastest responding server that contains a replica of the

tree. For example, if John logs in at Seattle, then Application Launcher

discovers that he is in sea.acme. Working backwards through the

application's Distinguished Name (DN), Application Launcher begins a

search in the sea.acme container for any application that matches the

one specified in the site list. Once prwpnt.app.sea.acme, the closest

application, has been found, it is launched.

ZENworks also provides some fault tolerance and load balancing for application

installation. This is done by taking the initial application object you set up for

your clients, and then associating it with other application objects you’ve

created. These other objects would be for installing the same application, but

would have the code located on different servers. Again, the impact from an

administrative standpoint is as noted above. Create more application objects,

buy NRS to replicate or replicate manually, and have an even more extensive

set of management tasks that must be used.

ZENworks Software Reporting

You can generate reports containing event information for any application

distributed with the Application Launcher. The report can be produced in either a

comma-delimited file format or as SNMP traps. Reporting is turned off by

default.

Prerequisites for SNMP-based reports:

The ZENworks inventory database must be running.

An SNMP Trap Target Policy must be enabled in the container where the


38

application resides.

Application Report Templates

ZENworks ships with twelve Application Launcher report templates that can be

used with the ZENworks reporting tool:

Application Launch Success by User, Workstation, or Application.

Application Launch Failure by User, Workstation, or Application.

Application Distribution Success by User, Workstation, or Application.

Application Distribution Failure by User, Workstation, or Application.

Software Distribution from Microsoft

Software distribution with Systems Management Server is similar to Novell in

that there are administrator-side functions and user-side functions. From the

administrator perspective:

You create a collection of users, groups, machines, or IP addresses to

target with your software.

You assemble the package of bits to be distributed and the logic to install

the software.

You advertise this package to members of the collection.

Collections:

Collections are one of the key features that allow version 2.0 of Systems

Management Server to deliver the flexibility of targeting that is needed for

software distribution.

In the current version of Systems Management Server, sites are intended to

more closely reflect the physical layout of your organization. Systems

Management Server collections provide a way to reflect the logical aspects of

your organization. Collections are arbitrary groupings of machines, users, user

groups, and network information. These groupings are used to target software

distribution.

You define and populate collections by setting membership rules for each

collection. Membership rules are the criteria by which Systems Management

Server evaluates whether a resource is a member of a particular collection. A

membership rule can be a query, or it can explicitly specify a resource.

When you set the membership rules for a collection, you can use the collection

as a target for software distribution and other management tasks. A resource

can belong to as many collections as you deem appropriate. You can define the


39

rules for collections at any time; you do not need to wait until resources are

discovered to create collections.

Collections are dynamic. Resources are periodically evaluated against the

membership rules. When computers are discovered, they are included in any

collection whose rules they satisfy. When hardware and software configurations

on individual computers change, those computers are removed from or added to

collections as appropriate. That means that your software distributions go to all

the computers that meet your collection criteria—even those computers that

were added to the network after you created the collection. In a similar manner,

if a computer no longer meets the criteria for a collection (it is moved to a

different group or no longer has the minimum free disk space specified in the

collection criteria, for example) it will no longer receive software targeted to that

collection. In fact, if software has been installed to a particular collection and a

resource leaves that collection (for example, the user moves from Finance to

Marketing), the software can be automatically uninstalled from that system

based on the fact that collection criteria are no longer met.

Collections can contain other collections (called sub-collections) as well as

resources. Collections are automatically propagated to child sites (either primary

or secondary sites).

Systems Management Server enables you to distribute software to any

collections you specify across one or more sites in your Systems Management

Server site hierarchy. You can distribute a single command to be run on

computers, a complete software application to be installed on individual

computers, or a shortcut to a software package that is installed on and run from

a network share.

Although collections are a key part of the solution of targeting whom should

receive your distributed software, they are not the total solution. In addition,

administrators need distribution and installation techniques that allow software to

be placed throughout the enterprise for maximum efficiency and installed on the

desktop with minimal error. Systems Management Server uses a series of

distribution points to store software packages on that are awaiting delivery.

Distribution points are the locations that clients access to obtain the files in the

packages. The computer or share designated as a distribution point must have

sufficient disk space for all the files that will be stored on it and must be

assigned the role of distribution point. Systems Management Server client

software can use any of the distribution points at a site that the client can

access. You can configure rules for clients to use when connecting to site

systems. For example, you can provide a specific list of distribution points to

contact or allow random selection from available distribution points. If the client

is already connected to a distribution point when it is ready to run an advertised

program, it will use that distribution point. Systems Management Server also

utilizes some capacities for advanced software distribution across a corporation.

These include the following:


40

Scheduling distribution

WAN-aware software distribution

Systems Management Server 2.0 provides key tools to allow administrators to

schedule distributions outside working hours. For instance, a specific time of day

can be indicated, or the installation can be set to happen when the user is not

actually logged on. It is also possible to schedule distribution based on network

bandwidth, therefore ensuring that package delivery does not affect other

network tasks.

Systems Management Server contains many facilities geared toward supporting

software distribution in a WAN environment, such as senders, bandwidth

profiling, retries, compression, and batching. In addition, new facilities have

been added with version 2.0.

The new Courier Sender allows software to be sent by CD-ROM or other media,

rather than across the network. This is useful in those situations where the

network bandwidth is too slow or too expensive to use for the delivery of a

package. Courier Sender acts the same as a WAN Sender with the

administrator indicating what type of media the software is placed on. When the

media arrives at the target destination (by courier) the local administrator simply

attaches it to the system (for example, puts the CD-ROM in the drive) and the

process is completed automatically. Systems Management Server version 2.0

also supports a fan-out mechanism for software distribution that makes use of

servers as routers of software. This means that a package that is going to

multiple sites needs to cross a slow link only once before it is copied and routed

to its various destinations.

Software Installation Process:

In order to perform software installation using Systems Management Server you

need to create the following:

Scripted installation procedures

Packages

Programs

Advertisements

To install software without input from the user, you will need to use a scripted

installation procedure. Many commercial software packages, including operating

systems such as Windows 2000, Windows NT Workstation, Windows 95, and

Windows 98 support scripted installation. If you want to distribute a software

application that does not support scripted installation, use the Systems

Management Server Installer to create your own installation script.


41

Systems Management Server packages specify information about the software,

the location of source files, the distribution points that will be used to distribute

the software, and similar information. A package defines the files and

instructions for distributing, installing, and running software. When you create a

package, you can create one or more programs for the package.

You can create packages for commercial software, in-house software, and data

files. In each package, you define the following:

General information about the package, such as the name, version, and

vendor of the software you plan to distribute.

If the package includes files, the package source directory that contains

those files.

The distribution points for the package.

Whether a compressed copy of the files referred to in the package is

created and stored on the site server at remote sites.

Whether the files in the package need to be periodically updated, and if so,

how often.

Programs specify the command that will run on the client to perform the tasks

that are described in a specific package (for example, install software, copy data

files, or run a batch file). You can create several programs for one package (for

example, one program can perform an express installation, while another runs a

customized script you have created with Systems Management Server

Installer).

The programs contained in a package are not run until you advertise those

programs to a target collection.

Advertisements make a program available to a collection and, optionally, its

collections. Advertisements specify which collection will receive each program

and the date and time when the software will be available to run on clients. You

can assign an advertisement (make it mandatory) from the moment it is

advertised or set it to be assigned after a specified date or time. You can also

set an expiration date after which the advertisement will no longer be available.

In an advertisement you specify:

The package and program to run on the client.

The target collection.

The schedule of when the program is available to clients.

When or whether the program is assigned.

Each client that meets the criteria for the collection you specify will receive the

advertisement. Because collection memberships are evaluated dynamically,


42

new computers and new users automatically receive advertisements for

programs if they meet the criteria for a collection to which the software has been

advertised. Also, users that no longer meet the criteria may have programs

removed from their system.

Systems Management Server ensures that everything required to respond to an

advertisement is available on the distribution points. If the package referred to

by an advertisement is not already on a distribution point at a child site, Systems

Management Server sends a compressed package to that distribution point.

When you are ready to make a program in a package available to clients, you

advertise the program to a target collection. Systems Management Server uses

collections to determine which clients receive an advertisement for a program.

Some applications need to be installed in a user context in order to set up the

appropriate icons; others need administrator rights to access system

configurations. Often a user without local administrative privilege will need to

install software that requires higher privileges. Systems Management Server 2.0

can deal with these situations because it is able to verify whether a currently

logged-on user has the appropriate privileges, and if not, to use its own domain

administrator privileges on that machine to install the software.

This is a key capability of Systems Management Server that has been further

expanded in version 2.0. Previously, applications were installed either by the

user or by a service account (with administrator privileges). Now, if Systems

Management Server finds that a user without appropriate security rights is

logged on, the program will still get installed and the user context will still be

maintained. You can install software on Windows-based clients using accounts

that have lower privileges than the Systems Management Server service

account.

Systems Management Server Installer:

Many software applications need manual intervention during installation, making

them poorly suited for electronic software distribution. Systems Management

Server Installer eliminates the need for manual intervention by providing an

installation scripting facility along with snapshot installation tools.

The Systems Management Server Installer provides an administrator with an

Installation Expert that repackages one or more software applications into a

single package for Systems Management Server to distribute and install

automatically. The Installation Expert automatically creates the instructions and

event generation scripts that Systems Management Server uses to deploy the

software, install the applications, and monitor the installation process. The

Installation Expert is a high-level series of dialog boxes that administrators fill

out. Most of the dialogs are check boxes and short text boxes. By defining the

information, Systems Management Server Installer translates this information


43

into a script. When compiled, Systems Management Server Installer

automatically creates an .exe file and a .pdf file so Systems Management

Server can distribute the application. For administrators, this is a huge

advantage because they can develop .pdf files quickly and easily without

requiring any code or programming skills.

Installation repackaging is available so that the administrator can combine one

or more existing application installations into a single self-extracting package

that is suitable for automated distribution by Systems Management Server. As

Systems Management Server deploys this package, it automatically detects and

uses local computer configuration settings. Systems Management Server also

ensures that only required files are deployed on each machine.

For some more sophisticated tasks, script authors may need to edit the

generated script. For instance, administrators might want to define conditions

(for example, check to see if a registry entry is there before doing an install) or

access to specific system information (for example, check to see which

language a client is using to determine which application to install). This is easy

to do because the script is designed specifically for installation and is easy to

understand. Each script command has a pop-up dialog to make editing the

script easier.

Administrators often need to distribute small changes to applications, files or

operating systems. Though the actual changes might be very small, the file that

gets distributed may be several megabytes. Software patching can greatly

reduce the size of distributed files because only the new bits of data need to be

incorporated into the installation. The software patching capability also supports

multiple previous generations of files so PCs with any previous versions can be

targeted for distribution. Software patching saves time and uses less bandwidth

on local and wide area networks.

An administrator can test an installation script before deployment by using the

dry-run test option. This allows an installation script and the user interface to be

tested before they are sent to the networked client PCs. With this feature,

administrators can be confident that the script they are distributing will work

properly.

Both uninstall and rollback capabilities are supported in case an installation does

not perform as expected. During uninstall, the application is simply removed.

During rollback, all the changes that were made to the target machine are

returned to their previous states. Files that were removed are restored as well

as any registry key settings, system services, icons, shortcuts, and so on. If

installation can’t be completed or if an application needs to be removed for any

reason, the computer can be restored to exactly the same state it was in prior to

installing the distributed software.


44

Microsoft Windows Installer

With a utility provided in the SMS Resource Kit, or with packages provided by

such third-party vendors as Seagate, Wise, and InstallShield, you can take

advantage of the latest in installation technologies utilizing the Windows Installer

Service.

For additional details on using Systems Management Server to distribute

Windows Installer based applications, please see the white paper on Deploying

Windows Installer Setup Packages with Systems Management Server 2.0 at

http://www.microsoft.com/smsmgmt/deployment/deploymsi.asp.

Installer Package Contents

The Windows Installer service views all applications as three logical building

blocks: components, features, and products. The following illustration shows the

relationships between Windows Installer service elements.

Each Windows Installer product is described in the form of a single Windows

Installer package file. The package file is a database format that describes the

relationships between features, components, and resources for a given product.

The installation package contains tables and relationships such as are found in

a typical relational database.

Products

The top-level element of an Installer package is a product. Each MSI file

contains only one product. The product contained in the MSI file is assigned a

Globally Unique Identifier (GUID) that is used to uniquely identify that product to

the Installer. For example, the Installer package for Microsoft Office 2000 is

contained in a single MSI file and is assigned a GUID. The Office 2000 product

consists of multiple Installer features such as Microsoft Word, Microsoft Excel,

and Microsoft PowerPoint.

Features

Features are what users may typically turn on or off during a custom installation.

The Installer supports a hierarchy of features. For example, Word is a feature of


45

Microsoft Office, and Mail Merge is a feature of Word. A feature is a collection of

one or more Installer components. Features can share components.

Components

A component is the smallest installation unit for the Windows Installer service. It

can be a collection of resources such as files, registry keys, shortcuts, or .ini file

entries. Components are commonly hidden from the user. Whenever a user

selects a feature for installation, the Windows Installer service determines which

components are required. A component does not necessarily have to contain

any files. It might contain only registry entries. When a component contains one

or more files, all files are installed into the same folder.

Benefits of the Windows Installer Service

The Windows Installer service helps you deliver a reliable and manageable

"Certified for Windows" installation package for your solutions. It performs

standard tasks related to installing and uninstalling, such as copying files,

modifying registry settings, creating shortcuts on the desktop, and displaying

dialog boxes to query the user for installation preferences when appropriate.

Rather than shipping each application with its own installation program file, its

own user interface, and other components, a software vendor provides an

installation package in the form of a single file with the file name extension .msi.

The Microsoft Installer (MSI) file contains data on the components of the

application and the state that those components must be in to have the

application installed on a computer. The data is processed by the Installer to

install and repair an application.

The Windows Installer service addresses the needs of corporate developers by

offering the following benefits:

Manages shared resources.

Enforces the same set of installation rules consistently.

Provides ease of customization.

Helps administrators decide what pieces of an application will be needed

later.

Diagnoses and repairs configuration problems at application run time.

Client View of Software Distribution:

Typically, users at a Systems Management Server client will not be aware that

their computer is part of a Systems Management Server system. Systems

Management Server 2.0 has been designed to be as unobtrusive to a user at a


46

client computer as possible. Depending on how you configure each client, the

user at the client may be made aware of none, one, or all of the following:

When advertised programs are made available.

When advertised programs are running or are counting down to run.

When a remote control operation is requested or in progress.

When an advertised program is made available, a taskbar icon appears in the

client’s taskbar status tray. When remote control is requested, an icon appears

on the client’s desktop, or a dialog box appears requesting permission from the

user to begin a remote control session.

A user at a client is required to perform Systems Management Server-related

tasks when the administrator:

Advertises a Systems Management Server package containing software for

installation that requires user input.

Needs the user to provide specific inventory information.

Wants to perform remote troubleshooting operations at the client and the

client is configured so that the user needs to provide verification.

An advertised programs icon with the label New Advertised Program appears in

a user’s system tray if a program is available:

New Advertised Program Icon in System Tray

When a new advertised program is made available at clients, users can use the

Advertised Programs Monitor to reschedule the program or run it immediately. If

they choose to run it immediately, a wizard walks the user through the

installation steps. This distribution method is closely aligned to the approach

used with Windows 2000.

To run the advertised program, the user at the client can do one of the following:

Double-click the New Advertised Programs Available icon.

Right-click the icon and choose the Run Advertised Program Wizard from

the popup menu.

Access the Advertised Programs icon from Control Panel.

In addition, the user at the client can use the Advertised Programs Monitor

(available in the same locations) to perform the following tasks:

Monitor program run status


47

Change configuration options for advertised programs

View advertised program properties

Advertised Programs Monitor

The Advertised program Monitor displays a list of all scheduled programs and all

programs that have already run at the client.

Post Installation Status Tracking:

When the software distribution process begins, Systems Management Server

has a series of status processes that provide a summary report of the state of

packages and distribution points in your site. The two types of status processes

that apply to software distribution are Package Status and Advertisement

Status. Package Status provides three levels of status information detail:

Summary status for all packages in all sites.

Details for a specific package in all sites.

Details for a specific package in a single site.

This information allows administrators to track information such as the total

number of distribution points that a package resides on, where copying to

distribution points has failed, and versions and dates of the software residing on

the distribution points.

The Advertisement Status provides a summary report of the total number of

clients that have received an advertisement, whether they succeeded or failed,

and which were targeted to receive the advertisement. Administrators then have

complete data on which clients needed to have advertisements delivered again

or where further troubleshooting needed to take place.

Software Distribution Conclusions

As each of the processes above is analyzed, it becomes evident that ZENworks

is focusing almost exclusively on software installation, and not on targeting

computers or on distribution. This becomes detrimental to a corporation that is

trying to find out their existing infrastructure detail before they begin software


48

installations and to any corporation that has to distribute software across a

WAN.


49

Installation Conclusions:

Novell provides some conflicting information regarding Application Launcher as

compared to Application Explorer. In its online documents, Novell speaks to the

power of Application Launcher to serve a desktop for a user, who can customize

it in myriad ways. They the help files emphatically note that Application

Launcher is designed for Windows 3.1 systems, and that Application Explorer

should be used on 32-bit platforms.

In addition, user context is a problem for Novell’s software distribution

mechanism. You can set up administrative context with Application Explorer, but

it’s not easy to do and this process cannot “switch” context to handle user-

specific attributes like HKCU registrations and then switch back to administrator

context. You need to either create two application packages to achieve this or

use Novell’s Pre-Install mechanism that pushes some parts, and then takes care

of the rest upon user logon. It is important for an enterprise that is running

Windows NT Workstation to be aware of this—every application they distribute

might take two packages. That is, the user-specific items are installed via the

user context, and the other pieces switch to administrator context. With Systems

Management Server 2.0, you get a context switching that is built in for Windows

NT Workstation and Server machines to allow you the best of both worlds.

It is important to remember that self-repair is available only if you run an

application through the Application Explorer Window and use the snAppShot

utility to install. Also, you should remember that this is a full reinstallation, not

just a reapplication of the necessary pieces, and that because of the reliance on

the snAppShot utility, this process may not work well where configurations differ

significantly. In addition, this process might not run well if some other application

that is sharing a resource with the problem application has not been delivered

using Application Explorer. Finally, because the Application Explorer object can

only be associated with one executable file, which executable file would be

assigned for suite products like Microsoft Office? The user could install the

application through the Application Launcher, but it would be difficult to have the

applications self repair or meter if the applications are running through the

Application Launcher window.

The snAppShot utility is very similar to the Systems Management Server

Installer that Microsoft has been using for some time. Points to remember about

snapshot technologies include:

There is a great deal of inconsistency in “snapshot” software deployment if

you cannot guarantee a high degree of consistency among machines for

recipients.

This inconsistency is even further magnified because ZENworks cannot

install software that is based on the target’s software inventory. With

Systems Management Server 2.0, even with “snapshot” technology you can

achieve a higher degree of success because you can choose your recipients


50

based upon their software inventory.

You cannot use a “snapshot” technology to upgrade an operating system, or

even to deploy service packs, with a high degree of success.

The better tool for application installation is the Windows Installer Service

that was released as part of Office 2000 and then Windows 2000. This is a

service that tracks application installation processes, not changes, and then

guarantees complete application rollback, checkpoint restart, and so on.

Snapshot technologies cannot deploy Windows Installer Service

applications like Office 2000. This is why most major software installation

vendors are already offering a way to create Windows Installer packages to

distribute software and are moving away from “snapshot” technologies.

Targeting Conclusions:

ZENworks 2.0 has made improvements over version 1.1 by adding a checking

mechanism for certain hardware characteristics before installing an application.

These are, however, still reasonably rudimentary. There is no option to use

advanced features like IP address or subnet for targeting. Here are some

common scenarios that you can create with Systems Management Server 2.0

but that you cannot create with ZENworks :

Make sure that machines with certain video drivers and network adapters

get different installs of a Service Pack.

Upgrade software on individual clients on a certain subnet.

Only target machines with a certain BIOS date.

Deploy multimedia software only to machines with CD-ROM drives.

Distribution Conclusions:

There is no distribution management in ZENworks management. The

administrator has to manually update the software packages at multiple

locations or purchase Novell Replication Services (NRS) at

http://www.novell.com/nrs/, which is listed on Novell’s Web site at $995 per

server. If the administrator purchases Novell Replication Services, the NRS

controls replication times, optimizes bandwidth, and guarantees delivery in case

of a broken connection, just like the senders in Systems Management Server

2.0 currently do, without an extra purchase.

Purchasing this Novell Replication Services, adds another management

component into an infrastructure that is supposed to reduce management costs.

This means that separate code must be installed on each server you want to

have NRS on. Also, separate management tasks are required to control and


51

configure. Finally, you will see that you must redesign your NDS architecture, as

in the enterprise, and you will have to organize your NDS tree quasi-

geographically, which makes it difficult to do such things as administer your

Human Resources, Administrative, or Executive staffs that are not in the same

geographical location.

Even with NRS, there are still limitations when compared to Systems

Management Server 2.0:

Only single-tiered software distribution—no fan-out distribution as with

Systems Management Server 2.0.

No delivery feature like Courier Sender that allows you to eliminate WAN

traffic completely.

Very limited reporting capabilities based on a text file or SNMP.

Without NRS, you’ll have the excessive overhead of copying software packages

between servers for your enterprise, as well as the following:

No WAN awareness (though Novell has added some simple NDS-based

fault tolerance and load balancing algorithms).

No bandwidth profiling or controlling.

No rollback or restart from distribution break point.

These are all things that any mature software distribution mechanisms needs to

do to be taken seriously in the enterprise. Here’s a chart summarizing some of

the differences between ZENworks 2.0 and Systems Management Server 2.0

for software distribution:

Software Distribution

Features

ZENworks

2.0

Systems Management

Server 2.0

Integrated with inventory

Targeting to users or

machines

Targeting to hardware,

software or IP information

Targets re-evaluated

dynamically

Rules-based program

removal

Scheduling

Package status reports

Elevated privilege support

Bandwidth profiling


52

Multiple WAN senders

Repackaging technology

included

Software patching

Rollback

Integrated with client UI

Compatible with

Windows 2000


53

Remote Diagnostics Tools

Remote Diagnostics from Novell

The remote diagnostics component of ZENworks 2.0 is the combination of two

help desk tools: a remote control facility and a simple trouble-ticketing process.

The security for Remote Control is integrated with NDS. Remote control settings

available in ZENworks are as follows:

Enable remote control.

Prompt user for permission to begin remote control on the client.

Give user audible signal when the client is remote controlled.

Give user visible signal when the client is remote controlled.

Default protocol to use for remote control.

With ZENworks 2.0, Novell added some more of the Intel suite of remote tools

including:

Remote Control

Remote View

Remote Chat

Remote File Transfer

Remote File Execute

The trouble-ticket tool allows an administrator to predefine the Help desk

information into a common format. The features of this tool include:

Providing users with the appropriate contact information for the Help desk.

Providing a user some system information to assist the Help desk operator

when the user calls or e-mails.

Integrating into GroupWise or any MAPI messaging system so the user can

e-mail the problem instead of calling.

The administrator can quantify which subjects the users can use for

submitting their problems.

Remote Diagnostics from Microsoft

Systems Management Server has included a remote control and diagnostics

tool since version 1.0. . Systems Management Server has extended remote

control to an array of remote diagnostics tools for both workstations and servers.

The remote diagnostics tools included in Systems Management Server are:


54

Remote desktop control.

Remote hardware diagnostics.

Remote carrying out of a command.

Remote transfer of files to a client.

Remote reboot of a client.

Test client network connectivity (Remote Ping Test).

Remotely establish an onscreen dialog (chat).

Network traffic monitoring (Network Monitor).

Server health monitoring (HealthMon).

Network discovery and tracing.

With Remote Desktop Control, an administrator or help desk member can take

control of a user’s screen, mouse, and keyboard to provide needed assistance.

Administrators can also take control of servers to provide remote server

management without having to travel to remote locations or have administrators

at each branch office. The security used in Systems Management Server is

integrated with Windows 2000 security. With it, you can determine which users

have access to these tools and the extent to which desktops within a site can be

administered.

Remote Desktop Control has also enhanced performance by including advanced

compression settings. Remote Tools uses low-compression and high-

compression methods to compress network data transmissions and minimize

the demands on network bandwidth during Remote Tools sessions. Clients use

one of these methods during Remote Tools sessions. You can select either

method for all clients to follow, or you can allow SMS to select the optimal

compression method on a client-by-client basis.

As for users, they can be given as much or little notice of control as your

corporate policies allow, including visual or audible indicators and an item in the

system tray or desktop to indicate that the session is controlled. You can also

decide to allow users to control to what extent their desktop can be remotely

controlled above and beyond the standards you set for the site. At the site level,

you can allow all items across a site to be permitted, but then eliminate some of

those permissions at the user’s workstation. You can also prevent the user from

making any changes to your site defaults.

The other remote tools serve functions other than taking control of a screen.

Remote Hardware Diagnostics allows an administrator to better diagnose

hardware problems by obtaining computer information such as free, used, and

virtual memory; IRQ assignments; loaded device drivers; and environmental

variables. Remote Execute helps by allowing you to perform tasks such as


55

running a virus checker or defragmenting the local hard drive on a remote client.

Remote File Transfer allows you to move or copy files directly to a client’s local

storage or from a client to your computer for troubleshooting. The Remote

Reboot function allows you to restart the client in case a network setting is

adjusted or system settings have been changed that require a reboot. The

Remote Ping Test sends packets to a targeted computer by using default

protocols. This process then continues to send packets to the target computer

and analyzes the number of packets returned and the elapsed time to determine

the reliability and speed of the communications channel. Finally, the Remote

Chat tool establishes an on-screen dialog with an individual user on the network

to discuss troubleshooting.

Network Monitor is included in Systems Management Server as a promiscuous-

mode sniffer to analyze and track network packets and their effect on network

traffic. Version Server 2.0 has enhanced Network Monitor to include:

Network Monitor Experts – automated tools designed to help you interpret

the information subtleties of captured network data.

Monitors – tools that continuously examine network traffic in real time by

watching for specific conditions of frames.

There are two new tools with Systems Management Server 2.0 that assist in the

overall administration of an infrastructure. These are Network Trace and

HealthMon, a Server health-monitoring tool. Network Trace allows an

administrator to create a graphical view of all resources on a network, including

routers, printers, workstations, and servers. Network Trace traces the

communication routes between the site server and all site systems to display the

network devices your site server can communicate with, their site-system roles,

IP addresses, and other information.


56

Network Trace

The HealthMon management console is a component of Systems Management

Server that provides a central, graphical, real-time status view of Windows NT

4.0, Windows 2000, and BackOffice servers. Based on color-coded severity

levels, you can view operational conditions, including both normal and

exceptional status. As events are received, HealthMon organizes and displays

them according to predefined monitored object groups. The monitoring

component of HealthMon bundles a set of predefined monitoring policies that

identify the metrics and criteria for normal, abnormal (Warning and Critical), and

Unknown conditions. These policies control how HealthMon identifies and

presents normal and abnormal operating conditions. As a result, you do not

need to determine what to monitor or what might constitute an exception.

As events are received, HealthMon organizes and displays them according to

predefined monitored object groups (MMC nodes). These object groups

comprise system-level resources (processor, memory, paging file, physical disk,

network interface, server work queues, security, and fault server) and

BackOffice servers (SNA Server, SQL Server, Exchange Server, and IIS

Server). The use of resource-monitored and server-monitored object groups can

help you more easily interpret the impact of each event condition. In addition,

you can view the individual status of all monitored systems and the occurrence

of all events.


57

Remote Diagnostics Conclusions

The following are Microsoft-only features that Novell does not have:

Multiple site security reconciliation. This prevents a rogue administrator

console from mimicking a remote control administrator and illegally taking

control of a client.

Intelligent detection of older or inferior versions of remote control software.

The Systems Management Server 2.0 agent detects the older agent on the

client, refuses to install it, and notifies the administrator of a conflict, instead

of compromising remote control functionality on the client.

Ability to manage installing and uninstalling of remote control on all clients

throughout the enterprise from the Systems Management Server

Administrator console. ZENworks is installed on each client as a function of

the Novell intraNetWare agent on a client-by-client basis.

Similarly, all clients in an enterprise can be managed by administrator-

dictated settings. No client-by-client settings changes are necessary.

Secure registry settings. If the user makes registry changes that conflict with

the site-wide settings, an internal security munger will overwrite these

changes with the administrator-dictated settings.

Enhanced reboot on Windows 95 and Windows 98 clients with 16 color

resolution—the Novell agent results in a blue screen on Windows 95 and

Windows 98 16-color at 640x480 and 800x600 resolutions.

On Windows NT Workstation or Server, the remote tools will also log all

requests for remote control access to the client’s Windows NT security log.

ZENworks has no tools that correspond to tools such as Health Monitor,

Network Monitor, and Network Trace. Novell may declare that ManageWise is

the solution for each of these pieces, but customers are being told that they

need to purchase an array of different products to get this functionality from

Novell. Systems Management Server 2.0, on the other hand, is a unified product

that performs many functions.


58

Remote Diagnostics Features ZENworks 2.0 Systems

Management Server

2.0

Remote control

Remote hardware diagnostics

Remote running of files

Remote file transfer

Remote reboot

Test network connectivity

Remotely establish onscreen dialog

Network monitoring and analysis

Network trace

Server health monitoring


59

Software Metering

Software Metering from Novell

The software-metering tool in ZENworks has been available through Novell

consulting for a while, and was released as part of ZENworks 2.0. The software

metering facility is built on top of Application Launcher and the Novell Licensing

Services API, and therefore on NDS. It only works with applications that have

been distributed through Application Launcher and that you have set up

licensing policies for. The process involves defining an application through

Application Launcher and specifying available licenses through Novell’s

Licensing Services. When this is complete, assign that application to the

appropriate licensing service for monitoring. When a user invokes an application

through the Application Launcher Window, Application Launcher checks against

NDS to see if that application is metered and if licenses are available.

Software Metering from Microsoft

Systems Management Server software metering allows an administrator to track

and trend application usage and restrict access to applications based on

licenses, user and group information, workstation, or time of day. The metering

client on the desktop tracks the executable files that are run both from the local

drive and remote drives; it then periodically submits this information to a

software metering server where the data is stored for tracking and identifying

trends. If a corporation is using online metering, the metering agent will check

before running the application for user and group permissions, workstation, time

of day, and available licenses. If denied access to an application, the user

receives an administrator-customized message indicating the reason for denial.

The user may have the option to request a call back so that when licenses are

available, the user will be notified and will be able to run the application. To

more thoroughly maintain licenses, Systems Management Server offers a

“check out” process for mobile users. This feature includes timing for how long

the license is checked out and what to do when the check out has expired.

Software Metering Conclusions

To examine the criteria usually required for a software-metering product, see the

review of these products in Network Computing at

http://www.nwc.com/906/906r12.html. Their conclusion is that “software

metering is a discipline divided between trending software usage and managing

who gets to use that software and when they get to use it. Also included in this

category is the enforcement of licenses.” In the study from Network Computing,

Systems Management Server was rated as the top metering product on the

market.


60

Source: Network Computing, April 1st 1998

The ZENworks solution is very limited compared to Systems Management

Server and other software metering products. In particular:

It will not meter applications installed separately from Application Explorer.

It will not stop the user from installing and running unlicensed applications.

It does not provide advanced metering capabilities (such as callback

facilities, soft metering, metering by time).

In fact, this metering solution really only offers value when a desktop

environment is totally locked down, or is using the Application Launcher Window

as the shell. Most metering solutions are tied to the Windows executing thread,

and they check to see if an application is allowed to start when it registers with

Windows. The Novell solution does not do that.

Software Metering Features ZENworks 2.0 Systems Management


61

Server 2.0

Basic software metering

Callback support

Metering by workstation name

Metering by system time

Metering applications run from standard desktop

Metering applications installed by a user outside of normal offerings

License checkout

Tracking licensed application usage

Tracking all application usage

As you can see from this evaluation, a strategic management product such as

Microsoft Systems Management Server 2.0 can provide an enterprise with the

tools it needs to overcome the rising costs of ownership more effectively than

ZENworks 2.0 from Novell can. The Systems Management Server 2.0 features

are richer, better integrated, and much more enterprise ready than anything that

ZENworks alone can offer. And, until Novell can sufficiently integrate the

ZENworks product with ManageWise, Novell Replication Services, and the other

products needed to meet the rich features that Systems Management Server

2.0 offers, Novell’s management offering is a series of products—not a solution.

The following chart summarizes the features discussed in this paper:

Features Novell Microsoft

Policy-based desktop

management

Uses Microsoft System Policies

for Windows NT Workstation,

Windows 95, and Windows 98.

Can use extensible policies but

with tradeoffs from above policies.

Uses Microsoft System Policies for

Windows NT Workstation, Windows

95, Windows 98, Office 97, Internet

Explorer, and new policy features

included in service pack 4.

Hardware inventory Limited.

Non-standards based.

Stored in directory and database.

Limited access for reporting.

Not available for software

distribution.

Full.

Standards based.

Stored in an enterprise database.

Easily accessible for reporting.

Basis for software distribution.

Software inventory Based on prescribed software.

Cannot find software you don’t tell

system to look for.

Full.

Sorted by manufacturer.


62

Conclusions

Not leveraged for software

distribution.

Run from server causes problems

for remote users.

Easily accessible for reporting.

Basis for software distribution.

Integrated into Year 2000 analysis.

Software distribution Targeted only by NDS.

No enterprise distribution.

Installation process where full

benefit only achieved from using

“snapshot” technologies.

Targeting by user, group, IP,

hardware inventory, and software

inventory.

Full support for enterprise distribution

with fan-out distribution, bandwidth

sensitive senders, Courier Sender

and status reporting.

Installation processes to support both

scripted and “snapshot” technologies

to improve support in heterogeneous

environments.

Remote diagnostics Remote desktop control.

Remote desktop view.

Remote file transfer.

Remote file execute.

Remote desktop control.

Remote file execute.

Remote file transfer.

Remote hardware diagnostics.

Remote connectivity checking.

Remote text-based chat window.

HealthMon.

Network Monitor.

Network Trace.

Software metering Metering only of applications

deployed through Application

Explorer and run in Application

Explorer Window.

Metering of applications regardless of

desktop presentation or location

Metering based on workstation or

time.

Metering support for license checkout

Callback support.

Custom messages.

These features not only provide you with the ability to focus on tasks to drive

business forward, but they allow you to save money as well. The NCRI study


63

mentioned earlier estimated an annual savings of over $1200 per desktop using

Systems Management Server:

With the growing pressures on IT to continue to manage the existing

infrastructure with less staff, a tool like Systems Management server can serve

as a catalyst to allow IT staff to not merely manage their existing environment,

but also to manage to keep driving IT as a profit center, sending your

corporation’s business forward in an ever more competitive world.


64

Average annual savings (per

desktop)

Range (per desktop)

Software Distribution $876 $218 - $1,590

Help Desk / Troubleshooting $ 330 $30 - $1,257

Inventory $17 $0 - $58

Maintenance costs ($ 23) ($2 - $114)

Annual Net Benefit $1,200 $354 - $1,813

Date post:	09-Aug-2015
Category:	Technology
Upload:	datacenters
View:	173 times
Download:	0 times