Novell is now a part of Micro Focus

A Competitive Upgrade: LANDesk Management Suite to ZENworks for Desktops 4

Articles and Tips: article

Erica Royer
Information Specialist, Net Solutions Group
Novell, Inc.
eroyer@novell.com

Martin Buckley
Evil ZEN Scientist
Novell, Inc.
mbuckley@novell.com

Thanks to Jeff Loomis (Technical Specialist, Consulting) for his contributions to this AppNote.

01 Jan 2003


This AppNote outlines an upgrade strategy to help existing LANDesk Management Suite customers move to ZENworks for Desktops 4.


Topics

desktop management, product upgrades, competitive upgrades

Products

ZENworks for Desktops 4, LANDesk Management Suite

Audience

network administrators, consultants, designers

Level

intermediate

Prerequisite Skills

familiarity with desktop management concepts

Operating System

NetWare 5.x and 6.x, Windows NT/2000/XP, Linux, AIX

Tools

LDMS2ZFD tool (Novell Cool Solutions)

Sample Code

no

Introduction

ZENworks for Desktops 4 is Novell's latest desktop management solution. It delivers user-centric, cost-effective desktop management for corporate Windows workstations. ZENworks for Desktops 4 provides comprehensive lifecycle management capabilities for the workstation-OS imaging, application management, inventory, remote control, and desktop lockdown-delivered no matter where the workstation is. Now you can manage your users and their environment whether they are connected or disconnected, outside or behind your firewall, using a workstation or a laptop.

In contrast, LANDesk Management Suite from LANDesk Software provides a limited set of management for workstations-primarily delivering inventory and remote control for your tethered workstations. LANDesk relies on the addition of partner products to even come close to matching the capabilities of the ZENworks family.

Many customers are looking to replace their LANDesk Management Suite deployments with a solution that is more flexible and fits the needs of their agile business and their increasingly demanding and mobile workforce. ZENworks for Desktops 4 is that solution.

This AppNote outlines an upgrade strategy to help existing LANDesk Management Suite (LDMS) customers move to ZENworks for Desktops (ZfD) 4. It divides the process into six phases and provides general guidelines and detailed steps for each phase.

Creating Your ZENworks for Desktops 4 Upgrade Strategy

Your company's strategy for upgrading from LANDesk Management Suite to ZENworks for Desktops 4 will depend on two things:

  • The level of service your users are accustomed to under the LANDesk Management Suite system

  • Your company's priorities and business goals for ZENworks for Desktops

At no point in your upgrade strategy is it necessary to lose any of your enterprise management functionalities, whether those functionalities come from LDMS or ZfD 4. This AppNote shows you how to make a seamless transition without experiencing any dips in the level of service you already provide to your users.

Pacing the Upgrade

It is not possible to manage a workstation with both LDMS and ZfD. Once the ZENworks for Desktops Management Agent is installed on a workstation, the LDMS Client must be removed. For this reason, Novell recommends that you first prepare your ZfD infrastructure to provide the same functionalities as LDMS, and then slowly upgrade all of your workstations, uninstalling LDMS as you go. However, it is not recommended that you try to support portions of your environment with LDMS beyond the initial upgrade. Once you have made the complete switch to ZfD 4, LDMS should not exist within your network environment; such a configuration is not supported by either Novell or LANDesk Software.

The initial upgrade will also include ZENworks for Desktops features that take your management capabilities beyond what you had with LDMS. This will depend on your company's priorities for enterprise management. According to these priorities, your upgrade strategy may follow one of two paths:

  • Rapid Upgrade.  The rapid upgrade involves designing and building your entire ZfD infrastructure on the back end, testing it, and then migrating your workstations from LDMS to ZfD. This path is valuable in that it allows your users to take advantage of the advanced ZfD features immediately.

  • Phased Upgrade.  If you choose a phased upgrade, your first task is to design and build your ZfD infrastructure in a way that supports your users as they were supported under LDMS. Then you test it and migrate your workstations from LDMS to ZfD. Over the next several months, you implement phased "upgrades" as you slowly take advantage of ZfD's advanced features. This path is valuable in that it allows a learning curve for users and administrators as they make the transition from LDMS functionality to ZfD functionality. It also works well if your company doesn't have the resources (network or human) to support an all-at-once upgrade at this time.

This AppNote provides a sample upgrade strategy that can be used as a model in creating your company's strategy, whether it be rapid or phased. The overall strategy is divided into phases and steps, which can be carried out either all at once or over time. We also provide guidelines for which phases and steps must be completed before others.

Here are the phases of the upgrade that will be covered:

  • Phase One: Gather your company's business and technical requirements

  • Phase Two: Compare your company requirements to the ZfD features and requirements

  • Phase Three: Design your ZENworks for Desktops 4 infrastructure

  • Phase Four: Prepare your network for ZENworks

  • Phase Five: Install ZENworks for Desktops 4

  • Phase Six: Remove the LDMS software

Phase One: Gather Business and Technical Requirements

Gathering your company's business and technical requirements should always come first in any enterprise-wide software deployment. The following steps can be done simultaneously.

1. Gather business requirements.

As indicated above, when you upgrade from LDMS to ZfD 4, your enterprise management capabilities will increase dramatically. Because of this, you will be able to address many more of your company's business requirements for enterprise management. It is important that you understand and document these requirements before you begin your design. Here are some things to consider:

  • What problems is your company dealing with at this time regarding workstation and user management?

  • In the Help Desk log for the past three months, what area or problem received the most number of calls?

  • What would be your company's ideal means for troubleshooting broken workstations and applications (imaging, remote control, application self-healing, and so on)?

  • How much control should users have over their workstations?

  • What security requirements does your company have for locking down workstations?

  • Will your company support its mobile users and their laptops?

  • What is your company's preferred policy for hardware and software inventory (what to inventory, how often, report at local, regional, or enterprise level, and so on)?

  • How fast do you want to make new employees' applications and resources available to them?

  • What is your company's workstation lifecycle policy?

  • Does your company want to move towards a Web-services architecture?

Gathering this information may require talking with several stakeholders within your company. The resulting business requirements should reflect your company's ideal goals for enterprise workstation and user management. It should not be dependent upon LDMS or ZfD 4 features.

We do not recommend hunting through ZENworks features to get ideas for workstation and user management policies. ZENworks has many features that your company may not need at this time. Searching for ZENworks capabilities before you understand your company's needs will result in a solution that does not address your company's actual business goals or requirements.

2. Gather technical requirements, capabilities, and limitations.

Your ZfD 4 architecture has the potential to be significantly different from your former LDMS architecture. For example, LDMS is highly centralized, while ZfD 4 is flexible in that it can be centralized or distributed according to your network requirements. You do not want to automatically assume that your ZfD 4 architecture will match your LDMS architecture. Upgrading to ZfD 4 is an opportunity to rectify performance problems that you may have been having with LDMS. It is also an opportunity to take advantage of ZfD 4's scalability, and to plan for future growth within your company's infrastructure.

Gathering technical requirements includes gathering any limitations your network may have at the time of the initial ZfD 4 upgrade. For example, ZENworks for Desktops 4 does not support workstations running Windows 95. If your company has Windows 95 machines that it is not ready to phase out, you may need to include ZENworks for Desktops 3.2 in your design (ZfD 4 is backwards compatible with ZfD 3.2). You will use information about your network limitations to design your ZfD 4 upgrade in a way that balances your network resources with your company's business needs and Novell's recommendations.

Here are some things to consider:

  • Current WAN/LAN design

  • Current eDirectory/Active Directory design

  • Number of workstations per physical site

  • Disk space and server resources

  • Server and workstation operating systems

  • Whether or not to use Novell Client 32

  • Targeted users (inside or outside the firewall? mobile or LAN-based?)

  • Application delivery methods (NAL, NAL Explorer, or Web?)

  • Administrative resources per physical site

Phase Two: Compare Your Requirements to ZfD Features

Comparing your company's requirements to ZENworks for Desktops 4 features and requirements should always follow the information gathering you did in Phase One.

This phase is a matter of prioritization and compromise. It may not be possible at this time to implement all of your company's enterprise management requirements. For example, you may need to make some changes to your network before it can support the ZfD 4 features that will meet your requirements, or you may need to acquire other software to meet requirements that ZENworks for Desktops 4 does not meet.

To ensure that you meet your company's priorities, it is important that you carry out the following steps in order.

1. Prioritize your business requirements.

As you do this, remember that one of the goals for this upgrade is to maintain the same level of service that you have been providing to your users with LDMS. Any requirements that are already being met with LDMS should be at the top of your priority list for ZfD 4.

After you have prioritized each company requirement, decide when you want implement it:

  • Immediately

  • 3 - 6 months

  • 6 - 9 months

  • 1 year or more

2. Identify ZfD 4 features that meet your business requirements.

Information on product features can be found on the product Web site at http://www.novell.com/products/zenworks.

3. Compare ZfD 4 technical requirements with your network capabilities and limitations.

To do this, consider hardware and software requirements for:

  • ZfD 4 servers

  • Middle Tier servers

  • Installation/management workstation

  • Managed workstations

You are not required to have NetWare in your environment to run ZENworks for Desktops 4, but you do need eDirectory. Novell eDirectory is the most scalable directory service in the industry. It supports industry-standard protocols and runs on NetWare, Windows NT/2000/XP, Solaris, Linux, and AIX. ZfD 4 ships with eDirectory as well as DirXML drivers that allow you to synchronize Active Directory and NT Domains with eDirectory.

The following tables contain more detailed ZfD 4 hardware and software requirements, respectively.


Server/Workstation
OS
Processor
Free Disk Space
RAM

ZfD 4 Server

NetWare 5.1

Pentium III

128 MB

256 MB; 1 GB for 200 concurrent users

NetWare 6

Pentium III

220 MB

256 MB; 1 GB for 200 concurrent users

Windows 2000

Pentium III

220 MB

256 MB; 1 GB for 200 concurrent users

ZfD 4 Middle Tier Server

NetWare 5.1

Pentium III

160 MB

256 MB; 1 GB for 200 concurrent users

NetWare 6

Pentium III

160 MB

256 MB; 1 GB for 200 concurrent users

Windows 2000

Pentium III

160 MB

256 MB; 1 GB for 200 concurrent users

ZfD 4 Inventory Server*

NetWare 5.1

Pentium III

128 MB

256 MB; 1 GB for 200 concurrent users

NetWare 6

Pentium II; III

128 MB

256 MB; 1 GB for 200 concurrent users

Windows NT

Pentium III

128 MB

256 MB; 1 GB for 200 concurrent users

Windows 2000

Pentium III

128 MB

256 MB; 1 GB for 200 concurrent users

ZfD 4 Managed Workstations**

Windows 98 SE/NT/2000 Pro/XP Pro

Pentium-compatible (32-bit only), 200 Mhz

20 MB

64 MB

* For a breakdown of ZfD 4 Inventory Server hardware requirements, refer to "Workstation Inventory Subinstallation Hardware Requirements" in the ZfD 4 documentation online at http://www.novell.com/documentation/lg/zdpr/zdprinst/ data/ae8cqdh.html#agoqhgd.

** If you have Windows 95 workstations in your environment that you want to continue supporting, ZENworks for Desktops 3.2 still supports Windows 95 and can be used in conjunction with ZfD 4. ZfD 3.2 documentation is available online at http://www.novell.com/documentation).


Server/Workstation
Software Requirements

ZfD 4 Server

NetWare 5.1 / SP4 / eDirectory 8.6.2

NetWare 6 / SP1

Windows 2000 Server / SP2 / Novell Client 4.83 / eDirectory 8.6.2

ZfD 4 Middle Tier Server

NetWare 5.1 / SP4 / eDirectory 8.6.2 / NICI 2.4.0 / Apache 1.3.22 / Novell Certificate Server 2.20

NetWare 6 / SP1 / NICI 2.4.0

Windows 2000 Server / SP2 / IIS / NICI 2.4.0

ZfD 4 Inventory Server

NetWare 5.1 / SP4 / eDirectory 8.6.2

NetWare 6 / SP1

Windows NT Server / SP6a / Novell Client 4.83 / eDirectory 8.6.2

Windows 2000 Server / SP2 / Novell Client 4.83 / eDirectory 8.6.2

ZfD 4 Installation

Workstation

For ZfD Server Software: Windows NT/2000/XP workstation or server / Novell Client 4.81 or later / Internet Explorer

For ZfD Middle Tier Software: Windows NT/2000/XP workstation or server / Novell Client 4.81 or later / NICI Client 2.4.0 (if issuing certificates from ConsoleOne)

ZfD 4 Managed

Workstations

Windows 98SE / Internet Explorer 5.5 or higher w/128-bit encryption or higher

Windows NT/ SP6a / Internet Explorer 5.5 or higher w/128-bit encryption or higher

Windows 2000 Professional/ SP2 / Internet Explorer 5.5 or higher w/128-bit encryption or higher

Windows XP Professional / currently shipping / Internet Explorer 5.5 or higher w/128-bit encryption or higher

For more information, refer to "Preparing for Installation" in the ZfD 4 documentation at http://www.novell.com/documentation/lg/zdpr/zdprinst/ data/ae7cezq.html.

4. Make a plan for your company's enterprise management.

This plan should include the immediate implementation of ZfD 4 as well as future phases that aren't possible or as important right now. With each phase, make a list of requirements that must be met prior to implementing that phase. This may consist of anything from installing new servers to deploying the latest version of Internet Explorer to all your workstations.

Phase Three: Design Your ZfD 4 Infrastructure

The steps in Phase Three are given here in a non-specific order. You may carry them out according to your own needs and timelines. However, Novell highly recommends that you complete Phase Three before continuing with Phases Four through Six. This includes designing your completed ZfD 4 infrastructure, whether you plan to implement all of it at this time or not.

General Guidelines

When designing your eDirectory tree for ZfD 4, it is important to keep one guiding principal in mind:

Design according to physical location and WAN boundaries.

Physical location is key to designing any healthy eDirectory tree, but it is particularly important for ZfD 4. Once you implement ZfD 4, your users and workstations will be accessing many of their services from the network. Placing those services (policies, applications, images, and so on) on servers that are physically close to the workstations and users that are accessing them minimizes WAN traffic and keeps network performance up.

This must be carefully balanced with the need to maximize your disk space and administrative resources. In many of the steps below, Novell recommends one server per site (for example, one AWI server per site or one Workstation Inventory server per site). Note that this does not mean one server per service, per site. Several services can run on one server depending on disk space, RAM, and server load.

For scalability and administrative purposes, it is important to maintain uniformity across your directory tree. For example, if you decide to locate your WORKSTATION container inside your USER container at one site, you should follow the same pattern at all of your other sites. This saves your administrators from having to memorize where to find everything at each particular site. Uniformity is particularly important if you ever plan to include ZENworks for Servers (ZfS) in your enterprise management solution. The automated distribution services in ZfS will need to be able to find the same objects and services in the same places at each site.

Much of your administration of ZfD 4 features will depend on inheritance within the directory. You can associate ZfD features to containers, groups, and objects. When a user logs in to a workstation, the management agent at that workstation begins searching the tree for applications and policies associated to that workstation and/or user object. Its default search path proceeds in this order:

Object --> Group --> Container

The management agent continues searching up the tree until it encounters a Search Policy that tells it to not to search beyond a particular container (Search Policies are discussed later in this AppNote). If it doesn't encounter a Search Policy, it searches all the way to the [Root] of the tree. Objects in the tree inherit all applications and policies that are associated with their parent groups and containers above them-up to the Search Policy.

This is important to remember as you design your ZfD 4 infrastructure. You will want to place your users and workstations in containers and groups that are specific to physical location as well as function. For example, if you have a sales team at each of your physical locations, you may create a User container at each location, and then create a Sales group within each User container. With this structure, you would be able to associate sales application objects to the Sales group at each location. The sales team members would inherit those applications, but none of your other users within the User container would.

Several of the steps below indicate that you should design a strategy around a particular ZfD feature. Here's what we mean by design:

  • Decide how extensively you will be using this feature.

  • Designate which users and workstations in which physical locations will be accessing this feature.

  • Design the eDirectory tree to make optimal use of this feature (for example, creating containers for users, workstations, and applications at each site).

  • Decide how you will distribute this feature to your users and workstations (whether you will associate it to objects, groups or containers).

  • Choose which servers will house this feature (this is generally one server per physical location).

To facilitate your design process, we recommend setting up a ZfD 4 lab that closely mirrors your production environment. This will allow you to learn about the features hands-on while you design. Then when you actually get into testing and deploying ZfD 4, you'll have more than just a paper understanding of how everything works.

1. Document your design.

Before you begin, create graphical representations of your WAN and directory tree. You will use this throughout to help you visualize where your users and workstations are located (physically and in the tree) and from what servers they will need to be accessing their services.

As you design, it is important that you keep track of which servers will get which ZfD services as well as the specifics for how you will manage your workstations. This information will help you as you create your deployment strategy.

You should continue documenting throughout the design process.

2. Decide whether to use Middle Tier servers and, if so, where to place them.

Unlike earlier versions of ZfD, ZENworks for Desktops 4 is not dependent Novell's Client 32. If you choose, you can run ZfD 4 on your workstations via a small management agent. Here are your options.

Option 1.  Use Novell Client 32 to connect your workstations directly to the ZfD 4 server (see Figure 1).

Figure 1: Client 32 connects workstations to the ZfD 4 server inside the firewall.

This option makes sense for companies that are already using Client 32 to connect their workstations to the network inside the firewall. Client 32 is already installed on the workstations and the support staff is familiar with it. It also allows for high performance and scalability within the firewall.

Option 2.  Use the ZfD 4 Management Agent to connect your workstations to the ZfD 4 server through a Middle Tier server (see Figure 4). This option is required for workstations operating in an all-Windows environment or accessing the network through a firewall.

Figure 4: ZfD 4 Management Agent connects workstations to the ZfD 4 servers through the firewall via a Middle Tier server.

This option is also the solution to managing your remote workstations. With the ZfD 4 Management Agent and Middle Tier, you can push out applications and polices to users and workstations as well as remote control and inventory workstations across the Internet. Your users don't even have to log in to the network.

The Middle Tier server can support up to 200 simultaneous users (that's users that are actively accessing the network, not users that are just logged in). Usually, that amounts to 1,000 users per server. However, you should make your own calculations based on disk space, RAM, server load, and login times.

Option 3.  Use Novell Client 32 for workstations inside the firewall and the ZfD 4 Management Agent for workstations outside the firewall. If your company has a significant number of users operating on both sides of the firewall, this option allows all of them to benefit from ZENworks for Desktops 4. To maximize this option, it is important that you carefully look at your network and place the Middle Tier servers close to the users that will be accessing them.

If you have users that regularly operate on both sides of the firewall, you may choose to install both Client 32 and the Management Agent on their workstations. When a user logs in to a workstation with both the client and the agent, the following happens:

  • Client 32 searches for the ZfD 4 server.

  • If it finds the ZfD 4 server, the client logs in with the user's credentials.

  • If the client doesn't find the ZfD 4 server, the ZfD 4 Management Agent searches for the Middle Tier server.

  • When it finds the Middle Tier, it logs in to the Middle Tier, which then acts as a smart client and logs in to the ZfD 4 server with the user's credentials.

  • The Middle Tier continues to act as a smart client between the workstation and the ZfD 4 server.

Workstations that have both the client and the agent installed, will still be able to access applications from outside the firewall, but not policies. If users that are regularly outside the firewall already have the client installed on their workstations, remove it and install the agent.

3. Design your Automatic Workstation Import (AWI) and Automatic Workstation Removal (AWR) strategy.

ZENworks for Desktops 4 does not require manual workstation import, so you will need an AWI strategy if you are planning to manage workstations. The AWR feature is useful, but may not be required for your company.

Guidelines.  AWI creates WAN traffic only when workstations are being imported. Once they are imported into the directory, workstations no longer communicate with the AWI server nor create WAN traffic around import services. Novell still recommends having one AWI server per physical location. However, if reducing administrative overhead is more important to you than this risk of network traffic, you may want to centralize your AWI service.

AWR will not create as much WAN traffic as AWI, especially if you schedule it to run at night or during off-hours. Centralizing AWR results in less administration, fewer policies, and lower overall memory requirements.

Decentralizing AWR results in less WAN traffic (though not usually a significant amount), and it allows local sites to determine how often to remove workstations. If you choose to decentralize both AWI and AWR, run them on the same local servers.

Novell recommends a minimum of one workstation container per physical site. This reduces WAN traffic by keeping the workstation objects close to the actual workstations. An alternative method would be to import workstations into the local user containers.

If you choose to add your workstations to groups once they are imported, make sure the groups don't span WAN boundaries.

Where possible, Novell recommends using DNS to locate your AWI and AWR services (instead of maintaining HOST files on workstations).

Ideally, use DNS sub-zones to locate the local AWI server. For example:

  • zenwsimport.lax.digitalairlines.com

  • zenwsimport.dfw.digitalairlines.com

  • zenwsimport.ord.digitalairlines.com

These would provide sub-zones for the LAX, DFW, and ORD offices with an appropriate DNS entry for the local server.

Other options for locating the AWI server include explicitly giving a zenwsimport entry in the HOSTS file, nomination via registry entry or via command line. Further information is detailed in the ZENworks for Desktops 4 documentation.

4. Design your Workstation Inventory strategy.

If your company is currently using LDMS Inventory, it may be possible to design your ZfD 4 Workstation Inventory based on your LDMS design. However, in order to maximize the benefits of your upgrade, it is important to consider the differences between ZfD 4 and LDMS.

Consider the following features of ZfD 4 Workstation Inventory when making this decision:

  • Scalable and distributed (more so than LDMS)

  • WAN friendly

  • Inventory for remote workstations

  • Complete directory integration

  • Inventory policy that can be associated with containers, groups, or workstations

  • Choice of inventory database-Sybase ASA (ships with ZfD 4), Oracle 8 and above, or MS SQL 2000

  • Rollup across trees and firewalls

ZfD 4 Workstation Inventory affects the physical and technical layout of your entire network. In order to achieve your company's business goals for Workstation Inventory, it must be completely designed before it is implemented. Your design should depend on the following:

  • Company reporting policies

  • Current WAN/LAN design, including physical connections between sites and the number of workstations to be inventoried per site

  • Current eDirectory design

  • Disk space and server resources

  • Administrative resources

Guidelines.  Here are some guidelines to follow in designing a workstation inventory strategy:

  • Design based on your WAN (preferably one inventory server per physical site). Place inventory policies physically close to the objects that will be accessing them.

  • Use a hierarchical inventory for better network performance. Use a flat inventory for easier administration.

  • Place databases only where reporting is required.

  • Be careful about scheduling roll-up too frequently. This can slow network performance. Spread the initial scanning load if necessary.

5. Design your Remote Management strategy.

ZENworks for Desktops 4 allows you to remotely manage and troubleshoot workstations whether they are registered in the directory or not. For workstations that are not registered in eDirectory, the only requirement is that the workstation have the Remote Management Agent installed (part of the ZfD 4 Management Agent). Registered workstations also need the Workstation Manager component of the ZfD 4 Management Agent.

Remote Management often brings up security issues within an enterprise. For this reason, it may be wise to include your security group in the planning for this strategy. With the security group, you will need to answer some of the following questions:

  • Who will be allowed to remotely manage a workstation?

  • What level of remote management will be allowed (remote view, remote control, and so on)?

  • Are there some workstations that should never allow remote management access?

  • Will the user be required to grant access to the workstation?

You place limitations on remote access to workstations via a Remote Management Policy within the User and Workstation Policy Packages. However, policies do not affect workstations that are not registered in eDirectory. When an administrator gains access to a remote workstation, he or she has single sign-on access to everything on that workstation.

6. Design your Application Management strategy.

On its own, ZfD 4 has very good application management in small to medium environments. If your company has a large environment, Novell highly recommends integrating with ZENworks for Servers 3. If you want to push out an application with ZENworks for Desktops, you have to create an individual Application object for each ZfD 4 application management server within your environment. With ZENworks for Servers, you can create the application object once, in one central location, and then automatically distribute the object to all of your ZfD 4 application management servers.

For more information about ZENworks for Servers 3, refer to http://www.novell.com/products/zenworks/servers/zfs32final.pdf.

Guidelines.  If your company has several hundred (or thousand) applications, you may want to phase your migration of Application objects from LDMS to ZfD 4. For the initial migration, choose applications that are mission critical or are used most frequently.

Novell does not recommend accessing applications across the WAN. Applications should be placed in containers on servers that are physically close to the users or workstations that will be using them.

Novell Application Launcher (NAL) does not use Search Policies. You can prevent NAL from searching to the [Root] for Application object configurations by setting Application Inheritance. Settings for this Application Inheritance range from -1 to 9999. Here are some examples:


0

NAL won't look for container-associated Application objects

1

NAL looks at the immediate container for container-associated Application objects (default)

2

NAL looks at the container up two levels for container-associated Application objects

3

NAL looks at the container up three levels for container-associated Application objects, etc.

-1

NAL looks up to the [Root] for any container-associated Application objects. This setting is not recommended in a WAN environment for performance reasons.

With NAL, you can push Application objects out to workstations and/or users. Answering the following questions will help you decide how to associate each application:

  • Do users stay at the same workstation all the time?

  • Do all workstations need the application, regardless of what user is logged in (such as for virus updates)?

  • Do any users need to be able to access their Application objects from various workstations?

  • Do you have workstations that are designated only for specific tasks?

  • Are any of your workstations "utility" workstations (accessed by many users for the same basic functions)?

  • Does your company have any security requirements that may affect these associations?

  • Which association is easiest to administer (for you)?

If you are creating applications that will be used on several different operating systems, choose the least common denominator (for example, when creating an application for Windows 98 and Windows 2000, create the Application object on a Windows 98 workstation).

7. Design your Policy Management strategy.

Many times when we think of policies, we think of workstation and user management. We use policies to lock down workstations and prevent users from tampering with the configurations. However, these are not the only polices in ZENworks for Desktops 4, which runs most of its services with policies. For example, the way you configure Workstation Inventory is with the Inventory Roll-Up Policy.

ZfD 4 divides its policies into policy packages. Each package is a group of policies that have similar functions. Below we've listed ZfD 4 policy packages. Below each package, we've listed the policies that are important to the basic functioning of ZfD 4:

  • Container Package

    • Search Policy

  • Server Package

    • Imaging Server Policy

    • Workstation Import Policy

    • Workstation Removal Policy

    • Inventory Roll-Up Policy

    • ZENworks Database Policy

  • Service Location Package

  • User Package

    • Remote Control Policy

  • Workstation Package

    • Remote Control Policy

    • Workstation Inventory Policy

    • Workstation Imaging Policy

    • ZENworks for Desktops Management Agent Policy

The Workstation and User packages have many more policies specifically used for workstation and user management. These policies will be new compared to your LDMS environment, because LDMS has no policy management capabilities. It relies on the standard Microsoft policy management tools (with their inherent limitations) to provide desktop and user control. ZENworks for Desktops 4 can manage user and workstation management via specific ZfD policies, can integrate and extend Microsoft extensible policies (POLEDIT), or can consume Microsoft Group Policy management.

For full details and information, refer to "Understanding Workstation Management" in the ZfD 4 documentation, available online at http://www.novell.com/documentation/lg/zdpr/zdpradmn/data/af7cexv.html.

Guidelines.  Search policies, which are part of the Container Package, are one of the most important factors affecting network performance after implementing ZfD in your environment. Search policies prevent your ZfD 4 Management Agents from walking the entire directory tree when looking for policies and configurations. Set your search policies at the container level.

We recommend that you experiment with workstation and user policies in the lab and get familiar with them before you implement them in production. Because this feature is most likely new to your administrators, it may be wise to wait to implement policies until you have been using ZfD in your environment for a few months.

8. Design your Workstation Imaging strategy.

The following are three possible imaging strategies that can be used separately or together:

  • Use ZfD 4 imaging to build new workstations in a lab. As your company acquires new workstations, you send them through an imaging lab where each workstation is given a company supported image. The workstations are then sent into production. The imaging lab is supported by one dedicated ZfD 4 imaging server. This strategy also works well as a means of imaging machines that are being reprovisioned within your company.

  • Use ZfD 4 imaging for workstation updates or repairs. ZfD 4 comes with Preboot Services, which can boot the workstations from the network and send out the images via multicast. When it is time to update the operating system throughout your company, you use local file and print servers to send down images. Or, if is taking too long to troubleshoot a problem on a previously imaged workstation, you can associate an image to that Workstation object in eDirectory. Then you have your user save all his or her files on a network server and reboot to a newly imaged (and fixed) machine.

  • Use ZfD 4 imaging to multicast application objects as image add-ons. Instead of creating several different images for your various departments, create one lowest-common-denominator image (just the OS and the client or management agent), and distribute applications as add-on images via multicast. Add-on images are application objects that overlay a base image. Once they have been installed on the workstation, they are independent of the directory.

If you choose to integrate ZENworks for Servers with your ZfD solution, ZfS can significantly enhance the automation involved in the latter two strategies.

Guidelines.  Here are some guidelines to follow in preparing an imaging strategy:

  • Never image across the WAN.

  • ZfD 4 images are not hardware-independent. You'll need to create one base image per operating system per hardware make and model.

  • Create each add-on image on a clean machine with only the base image. If you create an add-on with another application present on top of the base image, you may unintentionally create a dependency on that application. For example, if you are creating an add-on image for Adobe Acrobat and Microsoft Word is installed with the base image, once you send the Adobe Acrobat add-on image out to workstations, it may not work unless Microsoft Word is present on the workstations.

Phase Four: Prepare Your Network for ZfD 4

Phase Four must be completed before Phases Five and Six. Together, Phases Four, Five, and Six form our technical upgrade path. You will need to customize this path to fit your environment and your company's immediate requirements. It's also important to remember that every environment is different. Do not use this upgrade path in your production environment until you have tested it in a lab that closely mirrors production.

1. Update your network to meet ZfD 4 requirements (if necessary).

You have previously identified specific requirements that would have to be met for each phase of your enterprise management plan. At this point, you'll need to implement the updates necessary for the initial phase of the ZfD 4 implementation. This includes any support packs that need to be applied.

If you need to install eDirectory, here are the basic steps:

  • Install eDirectory on a Windows NT, Windows 2000, or NetWare 6.0 server (eDirectory ships with ZfD 4).

  • Install ConsoleOne 1.3.3 (also ships with ZfD 4).

    Note: To keep from having multiple versions of ConsoleOne floating around, install one master copy onto a ZfD server on your network and then distribute or download to workstations as needed. One other option in a Novell Client32-less environment is to install ConsoleOne and snap-ins to a Windows Terminal Server and run from there.

  • Install and configure DirXML Active Directory or NT 4 Domain drivers to connect and synchronize with eDirectory (ZfD 4 ships with AD and Domain DirXML drivers).

  • Synchronize users and passwords between eDirectory and Active Directory.

For more information about eDirectory and DirXML, go to http://www.novell.com/documentation-index/index.jsp?category=eDirectory.

2. Verify that all ZENworks for Desktops 4 requirements have been met.

3. Back up your soon-to-be ZfD 4 servers.

4. If you are using DNS for AWI and/or Middle Tier, update DNS.

Make sure that ZENWSIMPORT resolves to the appropriate ZfD 4 AWI server IP address.

If you will be using Middle Tier servers, create DNS name(s) for them and specify IP addresses.

If you will be using ZENworks for Servers, go ahead and update the DNS names for ZfS, as well.

5. Create eDirectory object containers based on your ZfD 4 design.

Create object containers for the following:

  • Workstation objects

  • User objects

  • Application objects

6. Perform an eDirectory health check.

For more information, refer to the AppNote entitled "Health Check Procedures for NDS eDirectory on Supported Platforms" in the May 2001 issue (available online at http://support.novell.com/techcenter/articles/ana20010503.html).

7. Extend the eDirectory schema for ZfD 4.

If your directory root is a NetWare server, you will need to unload Java before extending the schema.

For schema extension instructions, refer to the "Installing" section in the ZfD 4 documentation at http://www.novell.com/documentation/lg/zdpr/zdprinst/ data/ae7c3hw.html.

Before you continue, verify that schema has been extended properly.

8. Install/upgrade ConsoleOne (v1.3.3) with ZfD 4 snap-ins.

Install/upgrade ConsoleOne on the following machines:

  • ZfD 4 server(s)

  • ZfD installation workstation

Note: Before upgrading, copy any previous verion of ConsoleOne you have been running into a holding container. You may need to have this earlier version available just in case.

9. Create and configure container search policies.

Make sure the search policies point to a specific container.

10. Unload Java on the soon-to-be ZfD 4 and Middle Tier servers.

This step is necessary for NetWare servers only. Make sure that no other services are using Java before you unload it.

Phase Five: Install ZfD 4

The steps in Phase Five are presented in a logical order. For example, it makes sense to install and configure Automatic Workstation Import early in the installation because so many of the other features depend on having workstations to manage. However, these steps do not have to follow this order, especially if your immediate goal is to implement ZfD 4 to support users as they were supported under LDMS and then add more features in later phases. The only step that has a dependency is Step 7: Migrate workstations to ZfD 4 Management Agent. This step should not be completed until you have tested your ZfD 4 infrastructure (Step 6) and are ready to manage users with ZfD 4 and not LDMS.

1. Install ZfD features to appropriate ZfD 4 server(s) as designed during Phase Three.

For each ZfD 4 server, install the appropriate services. These services can be installed one at a time or simultaneously. For each ZfD 4 server, do the following (as required for that server):

  • Install and configure Automatic Workstation Import and Removal and configure associated policies.

  • Install Workstation Inventory servers (in the following order):

    • Install root server and database; set up policies

    • Install intermediate server(s) and database(s) (if required); set up policies

    • Install leaf server(s) and database(s) (if required); set up policies

  • Install and create policies for other ZfD features such as Imaging (including Preboot, if required), Application Management, Remote Management, and Workstation Management.

2. Set up the ZfD Middle Tier server (if required).

  • Install Middle Tier services to the server.

  • Verify that the Apache or IIS ports are set to 80 and 443. (Port 443 is secure.)

  • Change the Apache configuration for ThreadsPerChild to 512.

3. Migrate LDMS Application objects to ZfD 4.

You may decide to migrate these applications any way you wish. We chose SnAppshot. Depending on the number of Application objects your company is currently using, this may be a daunting task. This task is made easier if you install Workstation Imaging first. You can then use imaging to clean the workstation after each snAppShot. If possible, choose only the most critical applications to migrate for the initial install.

  • Run snAppShot on a "clean" workstation (one with just the operating system + Novell Client 32 and/or ZfD 4 Management Agent + LDMS Agent).

  • Use the LDMS Agent to install the LDMS .EXE application file to the workstation.

  • Run a snAppShot of the workstation again.

  • Prune the Application object of unneeded registry entries. (For help, refer to "Pruning an App Object of Un-needed Reg Entries" at http://www.novell. com/coolsolutions/zenworks/trenches/tr_unneeded_reg_entries_zw.html.)

    There is a partner solution called Centralis AXE which will automate most of this process. For information, visit http://www.centralis.co.uk.

  • Import the Application objects into the tree.

  • Re-image the workstation before beginning a new snAppShot.

4. Create and configure policy packages.

  • Create and configure Container Packages for any additional site-level container.

  • Create and configure Server Package(s) for all ZfD 4 server(s).

  • Create and configure User Packages.

  • Create and configure Workstation Packages.

5. Configure the Application Launcher settings for each site-level container.

6. Test, test, and test some more.

Before you roll out ZfD 4 to your users, make sure all of the installed features work as well in production as they did in the lab. Import a few workstations-at least one per operating system-into the production tree (possibly your test lab workstations), and verify that the features work as planned.

Here are examples of things to test:

  • A workstation can communicate via the Middle Tier without Client 32.

  • A workstation that has logged in three times (or the number of times you configured) is automatically imported into the workstation container in eDirectory.

  • A workstation is successfully re-imaged from the network using Preboot Services.

  • A workstation sends its inventory information to the correct inventory server, which sends the information on to the database.

  • An administrator can remote control a workstation from ConsoleOne.

7. Migrate workstations to ZfD 4 Management Agent.

This is when you find out if your ZfD infrastructure is configured correctly. At this point, you do not want to migrate all of your production workstations over to ZfD at once. No matter how much you've tested it in the lab, a new application in the network may or may not perform as expected. Therefore, Novell recommends creating a container named ZENUPDATE (or something similar), and placing 20 to 50 workstations in that container. Push down the Management Agent to the ZENUPDATE workstations and test it in this pilot group before rolling out department by department, enterprise-wide.

  • Create a Management Agent installation response file, or use the agent installation Microsoft Installer (MSI) package.

    For instructions, refer to "Installing the ZfD Management Agent on a Workstation" in the ZfD 4 documentation online at http://www.novell.com/documentation/lg/zdpr/zdprinst/data/ae262ps.html.

  • Stop LDMS Client Services (only Inventory Scanner, Remote Control, and Application Management).

  • Install ZfD 4 Management Agent using LDMS Client (CBA).

    Note: At this point, the LDMS Client no longer operates. It still sits on the workstation and takes up hard drive space, but when the ZfD 4 Agent installs onto the workstation, it deactivates the LDMS components.

  • Remove the LDMS client using the a ZENworks for Desktops application object. This should call "WSCFG32 /U" from the LDMS Core Server or Service Center.

Note: This four step process is automated in a single utility soon to be available on Novell CoolSolutions for ZENworks. The LDMS2ZFD tool will allow the LDMS agent to be cleanly uninstalled and the ZfD4 management agent installed in a controlled manner.

Phase Six: Remove the LDMS Software

The sooner you accomplish this phase, the sooner you can reprovision your LDMS service center servers as part of the ZfD 4 infrastructure.

1. Remove and reprovision NetWare and Windows NT service centers.

2. Collapse the LDMS Domain.

Complete information on collapsing the LDMS management domain is included as part of the LANDesk Management Suite documentation. In summary, to fully de-commission your unneeded legacy LDMS implementation you should:

  • Remove the LDMS client from workstations. This step should already be complete by working through Phase 5 of the Migration Plan.

  • Uninstall the LDMS service centers. This is achieved through the LDMS Desktop Manager Console. Highlight the required server, select the Service Center Wizard, and then Remove All LDMS services.

  • Uninstall extra Management Consoles. This can be done via Add/Remove Programs in the Control Panel.

  • Uninstall the LDMS Core Server, again via Add/Remove Programs.

  • Drop and delete the databases used for inventory, metering, and the DataMart.

  • Uninstall and remove Web components from your IIS Web server.

Conclusion

This AppNote has provided information on upgrading your network from LDMS Management System to Novell's ZENworks for Desktops 4.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates