Upgrading from ZfD 2 to ZfD 3.2

Before you upgrade from ZfD 2 to ZfD 3.2, you should be aware of the Novell® software products that are required by ZfD 3.2 and the features that are different from version 2 and before. The following sections contain more information:


Novell Software Required for Use With ZfD 3.2

Before you can upgrade from ZfD 2 to ZfD 3.2, you should be aware of some Novell software that you will be required to use with ZfD 3.2. These include:


Novell ConsoleOne

Although ZfD 2 and earlier versions of the product required the NetWare® Administrator console to administer policies, packages, and Application objects, ZfD 3.2 requires Novell ConsoleOne® version 1.3.2 or newer. ConsoleOne is the Java*-based management console that is the current standard for all Novell administrative products. ConsoleOne 1.3.2 is available on the Companion CD that ships with ZfD 3.2.


NIS Installation

ZfD 3.2 installation is accomplished with the Novell Installation Service (NIS), which allows each software component or component group to be separately installed. NIS is automatically launched from the ZfD 3.2 Program CD.


Novell Clients

ZfD 3.2 requires the use of the Novell ClientTM. The following client versions are required:

Workstation Platform Novell Client Version Required
  • Windows* NT*/2000

Novell Client for Windows NT/2000 version 4.81 or later
  • Windows 95/98

Novell Client for Windows 95/98 version 3.31 or later

You can obtain the Novell Client you need from the ZENworks for Desktops 3.2 Companion CD. For more information, see Obtaining and Installing the Novell Client in Getting Started.


Differences in ZfD 2 and ZfD 3.2

Before you upgrade from ZfD 2 to ZfD 3.2, you should be aware of the features that are different from version 2 and earlier. These features were first incorporated in ZfD 3. The following sections contain more information:


The Automatic Workstation Import/Removal Component in ZfD 3.2

Before a workstation could be imported in a ZfD 2 environment, it first had to be registered, a cookie for it placed in NDS, then the system administrator had to manually run a tool to actually import it. The import process would create a workstation object in NDS and the workstation could log on as a workstation entity. Much of this manual work required in ZfD 2 is now accomplished automatically in ZfD 3.2 in a one-step process when the workstation is logged in to the network (this feature was first introduced with ZfD 3).

The Automatic Workstation Import service creates the Workstation object in NDS. The object can then be viewed from ConsoleOne the first time the workstation is registered. Subsequent workstation registration updates the Workstation object's properties, freeing the import service from the Workstation object unless the object is renamed, moved, or deleted.

Automatic Workstation Removal is just as simplified. You set a policy and unused Workstation objects are automatically removed from the tree.

For more information, see Automatic Workstation Import in Administration.


Differences in Workstation/Policy Management

As with ZfD 3, policies for ZfD 3.2 are organized into fewer policy packages than in ZfD 2. This design lets you manage new platforms more easily because they are under a package's umbrella. For example, all of the platforms under a User Package can benefit from the general user policies.

Most of the ZfD 2 policies now exist in either the User Package or in the Workstation Package.

The different policy packages for ZfD 3.2 include:


Container Package

The Container Package holds only the Search policy. The Search policy is used to minimize tree walking. For more information, see Container Package.


Server Package

The Server Package has four policies:

For more information, see Server Package.


Service Location Package

The Service Location Package has three policies:

For more information, see Service Location Package.


User Package

The User Package has nine policies found on various platform pages:

For more information, see User Package.


Workstation Package

The Workstation Package has ten policies found on various platform pages:

For more information, see Workstation Package.


Differences in the Application Management Component

As with ZfD 3, ZfD 3.2 includes Application Management features to make the management and use of software applications easier than in ZfD 2. The different features include:

For more information about any of these features, see Application Management in Administration.


Caching Applications and Running in Disconnected Mode

Application caching enables users to install, run, and verify (repair) applications while they are disconnected from NDS.

ZfD 3.2 Application Management creates a hidden cache directory (NALCACHE) on the root of each user's workstation. This cache directory contains the NDS information required to run an application when the workstation is disconnected from NDS. If the application has already been installed to the workstation and the user disconnects from NDS, the application will continue to run just as if the user were still connected.

The cache directory can also contain the application source files and other information required to install the application or verify (repair) problems that may occur with the application while in disconnected mode. For example, if a user does not install the application before disconnecting from NDS, he or she can still install it, provided the application has been cached to the workstation's cache directory.

To ensure that users will always have mission-critical applications when disconnected, you can configure Application objects to be cached automatically when you associate the Application objects with users. In addition, you can configure Novell Application LauncherTM/Explorer to display the Application Management dialog box. This dialog box, which is turned off by default, enables users to select which applications they want to cache to their workstations' local drives.

To save disk space, application files are compressed before being stored in the cache direct.


Uninstalling Applications

Any application that was distributed through ZfD 2, ZfD 3, or ZfD 3.2 Application Management can be uninstalled. All files, INI entries, and registry entries associated with the application are deleted. Shared DLL references are observed.


Managing Microsoft Windows Installer (.MSI) Applications

In addition to being able to manage applications that use snAppShot (.AOT) installation packages, Application Management can now manage applications that use Microsoft* Windows Installer (.MSI) packages. When creating an Application object, you simply choose what type of installation package (.AOT or .MSI) will be used. All ZfD 3.2 functionality, including application distribution, application uninstall, caching, imaging, and disconnected mode, is supported for .MSI applications.


Distributing Applications During the Imaging of a Workstation

Workstation Imaging lets you create base images to apply to workstations. Using Application Management, you can take any Application object and create an add-on image. Once you associate the add-on image with one or more base images, any time the base image is applied to a workstation, the add-on image will be used to automatically distribute the application to the workstation during the imaging process.


Reporting on Application Management Events

Application Management reporting has been improved to provide information about a variety of events, including the success or failure of the following events:

In addition to still being able to report events through SNMP traps or a log file, you can now save events to any ODBC-compatible database.


The Workstation Imaging Component

ZfD 3.2 includes a workstation imaging component that lets you take images of workstation hard disks and then use the network to put them on other workstations. You can perform imaging tasks manually (by physically visiting workstations) or automatically through NDS or the new ZENworks Preboot Services 3.2.

For more information about Workstation Imaging and ZENworks Preboot Services, see Workstation Imaging in Administration.


Differences in the Remote Management Component

ZfD 3.2 includes several Remote Management features, including:

For more information about these Remote Control features, see Managing a Remote Control Session in Understanding Remote Management Components in Administration.


Remote Wake Up

You can remotely power up a powered-down node in your network if the network card on the node is Wake On LAN enabled. This feature lets the administrator manage nodes during off-hours to minimize the downtime that end users may otherwise experience for system maintenance and upgrades. It also facilitates power savings while keeping systems available for maintenance.


Screen Blanking

This option lets the administrator blank the managed workstation screen, making it possible to perform remote management operations unobserved by the end user.


User Control Locking

This feature lets the administrator lock the keyboard and mouse at the managed workstation, making it impossible for the end user to use these controls.


Wallpaper Suppression

When a Remote Control or Remote View session is initiated, this feature lets the administrator suppress the wallpaper displayed on the desktop of the managed workstation.


Time-Out Configuration

This feature lets the administrator set waiting time for connecting with the managed workstation prior to starting a Remote Control or a Remote View session.


Differences in the Workstation Inventory Component

The ZfD 3.2 Workstation Inventory component offers the following features:

For more information, see What's in ZfD Inventory Management.


Sybase/Oracle Database Support

In ZfD 3.2, the database is an RDMS that can be maintained either in Sybase* Adaptive Server Anywhere* version 7.0, which ships with ZfD 3.2, or the Oracle* 8i, 8.0.4, or 8.i.x databases, which are native on many servers.


Inventory Data Roll-Up Support

ZfD 3.2 supports roll-up of inventory information across servers, so you can choose the inventory deployment configuration that best suits your requirements, whether your network environment is large or small.

In large networks, ZfD 3.2 inventory data is rolled up or accumulated, and sent to a centralized database. Beginning at the leaf server level, changes in inventory data are first sent to intermediate servers (if deployed) and finally to the highest level server, which also holds the Inventory database. The roll-up of scan data in ZfD 3.2 can handle problems such as the WAN link being down.


Inventory Tools

ZfD 3.2 has a Backup tool to help you back up the Inventory database, a Synchronization tool to help you maintain the database in a consistent state with NDS, a Map Server tool to provide a unified view of all the servers and database servers deployed on your network, and a DataExport Tool to store the inventory data from the Inventory database in a comma separated value (.CSV) file format (a format that is usable by most third-party reporting programs).


Preparing Your System for the Upgrade to ZfD 3.2

To prepare for the upgrade to ZfD 3.2, you must first prepare your systems with the following items:


Making a Backup of the Existing ZfD 2 Installation

Before you install ZfD 3.2, you should make sure that you have made at least two backups of the existing ZfD 2 installation. For backing up a NetWare server, use Novell Storage Management ServicesTM (SMSTM) or another backup utility to make sure that the server has an archived backup for you to restore later should there be problems with the migration.

For more information about SMS, see the Backup and Restore documentation at the NetWare 5.1 documentation Web site.


Upgrading to ConsoleOne

Before you upgrade, you must install ConsoleOne version 1.3 or later. ZfD 3.2 components and policies snap in to this java-based network administration tool. Version 1.3 of ConsoleOne is included on the Companion CD that ships with ZfD 3.2. If you try to install ZfD 3.2 on a network server that has an older installation of ConsoleOne, you will receive the following message:

IMPORTANT: ZENworks for Desktops 3 requires ConsoleOne version 1.3 or later to display all of its snap-ins. The version of CONSOLEONE.EXE currently installed on server NAME is dated 03/01/2000 1.2c, which is older than the required version. Do you want to proceed with the ZfD 3.2 snap-in installation?

[Yes] Install ZfD 3.2 snap-ins into the older version of ConsoleOne. I will install the required (or newer) version of ConsoleOne when this install is complete.[No] Do not install ZfD 3.2 snap-ins. I will use the older version of ConsoleOne.

If you click Yes, you will need to install the latest ConsoleOne version to SYS:\PUBLIC\MGMT\CONSOLEONE\1.2 on a network server. It is important to note that ConsoleOne 1.3 is also installed to the 1.2 directory.

For more information, see Obtaining and Installing ConsoleOne in Getting Started, or see the ConsoleOne documentation Web site.

IMPORTANT:  If you use ConsoleOne to change the properties of existing ZfD objects, then save your changes, and subsequently open the ZfD objects using NetWare Administrator (NWADMN32.EXE), some of the attributes of the ZfD object will be lost. The best practice is: if you start to administer any ZfD object with ConsoleOne, do not revert to NetWare Administrator to manage that object.


Editing the AUTOEXEC.NCF File

Upgrading from ZfD 2 will make certain commands in the AUTOEXEC.NCF configuration file obsolete. Before you upgrade to ZfD 3.2, you should edit this file and remove or comment the following lines:

SEARCH ADD SYS:\PUBLIC\ZENWORKS\JAVALOAD JAVA.NLM

SYS:\SYSTEM\JVORBCFG.NCFLOAD ORBCMD.NLMLOAD OSAGENT.NLM

SYS:\PUBLIC\ZENWORKS\JAVA\ALARMMGR.NCF

SYS:\SYSTEM\MGMTDBS.NCF

SYS:\SYSTEM\GATHERER.NCF

SYS:\PUBLIC\ZENWORKS\JAVA\MASTER.NCF

SYS:\PUBLIC\ZENWORKS\JAVA\STORER.NCF

IMPORTANT:  The preceding lines appear in the AUTOEXEC.NCF file after a test installation of the ZfD 2 International release. Your AUTOEXEC.NCF file may or may not contain any of the lines shown, depending on the version of ZfD 2 and the components installed.


Restarting the Server

When the latest version of ConsoleOne is installed and the AUTOEXEC.NCF file is edited, type the following command at the server console where you will be installing ZfD 3.2:

restart server

Restarting the server after the configuration file is properly altered for migration will keep it from loading old ZfD 2 NLM files and configuration files.


Unloading Java

You must unload Java before you begin the ZfD 3.2 installation program. Use the following command at the server console:

unload java

If Java is running when you run the installation program, the program will display the following message:

Java is running on server Name Install may not run properly if Java is running. 

Please unload Java on this server then press OK to continue.

You can still safely unload Java when this message is displayed.


Installing ZfD 3.2

After you install ConsoleOne, edit the configuration file, and restart the server, you can install ZfD 3.2. We recommend that you use a Custom Install if you are migrating from an older version of ZfD, making sure you choose the option to extend the schema for each of the components you choose to install. For more details about the Custom Install for each ZfD 3.2 component, see Getting Started or the appropriate sections of this Deployment documentation.

The ZfD 2 Workstation Inventory component requires more attention to upgrade to ZfD 3.2 than other components. The following sections include information that will help with that migration:


Installing ZfD 3.2 Workstation Inventory

If you have previously been using a ZfD 2 Inventory database, it will be necessary to migrate its data to a ZfD 3.2 database. You will have the option of installing Sybase version 7 to the server during the ZfD 3.2 install. If you choose to install this database, the installation program will display the following message:

838:Sybase 6 files at \\Server\Volume\zenworks\database will be deleted. Sybase 7 files will be copied.

This message indicates that support files for Sybase 6 will be replaced by support files for Sybase 7. Your ZfD 2 database is not deleted. You will have to migrate the ZfD 2 data to ZfD 3.2 using a special Database Migration tool. To learn more about this utility, see Migrating the Inventory Information from the ZENworks 2 Database in Understanding Workstation Inventory in Administration.


After the Inventory Installation

If you commented some of the lines in the AUTOEXEC.NCF configuration file rather than remove them, you will notice that the ZfD 3.2 installation program removes the following lines from the file:

SYS:\SYSTEM\GATHERER.NCFSYS:\PUBLIC\ZENWORKS\JAVA\MASTER.NCFSYS:\PUBLIC\ZENWORKS\JAVA\STORER.NCF

The installation program adds the following lines to the configuration file:

SEARCH ADD SYS:\JAVA\NJCLV2\BINZFDSTART.NCF

After you install ZfD 3.2 and restart the server, you may see the following message at the System console prompt:

Java: Class com.novell.zenworks.desktop.inventory.servercommon.

ZENWorksInventoryServiceManager exited with status -1.

This message is normal and is the result of running the STARTINV.NCF batch command from within ZFDSTART.NCF.

If you have installed a ZfD 3.2 Standalone Server Inventory component on a server, you can create a Service Location Package to correct this condition.

To create a Service Location Package:

  1. In ConsoleOne, click the OU where the ZfD 3.2 Inventory Database object is located (this object would normally be found at the same level as the server).

  2. Right-click New > Policy Package.

    3.

  3. Select the Service Location Package > click Next.

    4.

  4. Name the package > select the container to associate to > click Next.

    5.

  5. Check Define Additional Properties > click Finish.

    6.

  6. In the Policies/General tab, enable the ZENworks Database policy and open its properties.

    7.

  7. In the Database Location tab, browse for the ZENworks Database DN. The ZENworks Database DN would normally be found at the same level of the database server. Look for the ZfD3.2 InventoryDatabase object. Click OK > OK.

    8.

  8. From the Associations/Associations tab, select the objects to which you want to associate this Service Location Package > click OK.

    9.

When you have a Service Location Package, go to the System console and reload the STARTINV.NCF batch command. You should see the following message:

Successfully obtained site information from database. Starting Selector Service. Obtaining dbdir from service object: DATA\Zenworks\Scandir\DbDir. Trying to connect to the database.Connected to Database.

In this message, DATA\ZENWORKS\SCANDIR\DBDIR indicates the location of your database directory (\DBDIR).


Restarting the Server

After you have installed the ZfD 3.2 components that you want, type the following command at the server console where you have installed ZfD 3.2:

restart server

Restarting the server after the ZfD 3.2 installation will initialize new processes needed for further migration.


Upgrading the Novell Client

Many customers want to install the Novell Client before they install or upgrade to other new Novell products. This section covers two scenarios with the Client:


Upgrading to the ZfD 3.2 Client without Upgrading to ZfD 3.2

If you want to, you can upgrade the Novell Client without upgrading to ZfD 3.2; the new client will continue to be compatible with ZfD 2 functionality. You should remember, however, that the client installation can also include various ZfD components to be installed on the workstation, not merely the NetWare connectivity portion of the client.

IMPORTANT:  If you choose only to upgrade the ZfD 2 client to the ZfD 3.2 client without further migration, you should continue to administer ZfD 2 using NetWare Administrator rather than ConsoleOne.

If you installed Remote Management to your workstations when you installed the Novell Client that shipped with ZfD 2, the same option will be checked by default in the ZfD 3.2 Client Custom Install. If you uncheck this option during a Client upgrade, the ZfD 2 Remote Management functionality will not be upgraded to the ZfD 3.2 level. If the item is checked, the ZfD 3.2 functionality will be installed.

ZfD 2 will continue to function normally with the ZfD 3.2 clients; ZfD 2 workstations will not need to be re-registered unless a ZfD 3.2 Search policy is installed in the tree.


Upgrading to the ZfD 3.2 Client Before Migrating ZfD 2 Policy Packages and Data

If you install the ZfD 3.2 client after you run the ZfD 3.2 installation program (including extending the schema and installing the Auto Workstation Import component) and restarting the server, the workstations can be further enabled for Automatic Workstation Import. For more information about installing the Novell Client and Client Support Pack used with ZfD 3.2, see Obtaining and Installing the Novell Client in Getting Started.


Setting Up Automatic Workstation Import

Even though you install the Automatic Workstation Import/Removal component during the ZfD 3.2 installation program, it must be further configured before it will function and workstations can be imported. For details about how to set up Automatic Workstation Import and Automatic Workstation Removal, see Automatic Workstation Import and Removal.


Migrating ZfD 2 Policy Packages to ZfD 3.2

If you have a large number of workstations already associated with ZfD 2 policies, you can continue to use these same policies in ZfD 3.2. The majority of ZfD 2 policies are unchanged for ZfD 3.2, but the Policy packages have changed (see Differences in Workstation/Policy Management), so the Policy packages must be migrated.

You can migrate the legacy policies by using the ZfD 3.2 Migrate Legacy Policy Packages tool.

To use the tool:

  1. From ConsoleOne, click the container where the ZfD 2 legacy policies reside.

    2.

  2. Click Tools > ZENworks Utilities > Migrate Legacy Policy Packages.

    3.

  3. From the Migrate Policy Packages dialog box, confirm the context of the container you have selected > click OK.

    HINT:  You can preview what the migration utility will do to your legacy policy package without affecting your legacy policies by checking the Preview Only check box.

    4.

For more information about the Policy Package Migration tool, see Migrating ZENworks 2 Policies.

After you migrate a Policy package, it will be necessary to migrate the inventory policies. Migrating ZfD 2 inventory policies imports ZfD 2 policy settings for associated workstations to ZfD 3.2.

To migrate ZfD 2 inventory policies:

  1. In ConsoleOne, click the Inventory Service object to which the workstations are attached.

    You must select an Inventory Service object that supports the role of an inventory server.

    2.

  2. Click Tools > Inventory Policy Migration.

    3.

  3. Specify the following options:

    Server Address IP/DNS: If your ZfD 2 inventory server is a NetWare 4.x server, specify the Server Address.

    NDS Search Context: Specify the context for searching the Workstation Inventory object. By default, this tool will search the Workstation object in the current root context.

    4.

  4. Click Find.

    If any ZfD 2 inventory policies are found, these policies are listed in the Reports window.

    5.

  5. Click Migrate.

    All the listed inventory policies will be migrated. From the Report window, you can see the list of the inventory policies that were migrated.

    To ensure that the migration is successful, open the inventory policy in ZfD 3.2.

    In ConsoleOne, double-click the Inventory Service object for which you have migrated the policies > click the Workstation Inventory Policy tab. You will see the same inventory settings as specified in ZfD 2.

    6.

Migrating ZfD 2 Inventory Data to a ZfD 3.2 Database

The ZfD 3.2 Database Migration tool migrates the existing inventory information from a ZfD 2 database to a ZfD 3.2 database.

IMPORTANT:  ZfD 2 application reports are not migrated to ZfD 3.2. The data and formatting required for ZfD 3.2 application reports has changed completely.

To configure the inventory data migration:

  1. Open the DBMIGRATE.NCF file in the NetWare server's SYS:\SYSTEM directory or the DBMIGRATE.BAT file in the Windows NT/2000 PUBLIC\ZENWORKS\WMINV\BIN directory. The following text shows the contents of the file:

    #****************************************************************************#             Running the DBMigrate Utility# To run the DBMigrate Utility do the following:#    1.    Check if the environment variable JDBC_DRIVER points to the#          path where JDBCDRV.ZIP and CLASSES111.ZIP is present.#    2.    Check if the environment variable WORKING_PATH points to #     		     the path where ZENINVSERVER.JAR, STATUSLOG.JAR and
    #          DESKTOPCOMMONUTILITY.JAR are present.#    3.    Enter the IP address of ZENworks 5 Inventory #          database server after the switch '-dbloc'.#          For example,#            .... $CLASSPATH -dbloc 164.99.156.134 .....#    4.    Enter the IP address of ZENworks 2 Inventory database#          server after the switch '-zen2dbloc'.#          For example,#            .... $CLASSPATH -dbloc 164.99.156.134 -zen2dbloc 164.99.156.135 ....
    #****************************************************************************# FOR ORACLE# If the Zenworks for Desktops 3 inventory database is running on Oracle, then uncomment the line below and comment the Sybase line.# Also give the correct Oracle database SID for -sid switch.#java -ns com.novell.zenworks.desktop.inventory.migration.database.Loader -#classpath $classpath;$tmppath -nds -dbloc 164.99.149.246 -zen2dbloc #164.99.145.53 -oracle -sid orcl -Logfilename sys:\etc\dbmigrate.log# FOR SYBASE# If the Zenworks for Desktops 3 inventory database is running on Sybase, then #uncomment the line below and comment out the Oracle line above.#java -ns com.novell.zenworks.desktop.inventory.migration.database.Loader 
    #-classpath $classpath;$tmppath -nds -dbloc 164.99.149.196 -zen2dbloc #164.99.145.53  -Logfilename sys:\etc\dbmigrate.log
    2.

  2. Follow the instructions in the file header and edit the file to add the correct IP addresses of the ZfD 2 server you are migrating from and of the ZfD 3.2 server you are migrating to.

    Be sure to use the command line that matches with the type of database you are running for ZfD 3.2.

    3.

  3. Run the appropriate file (whether DBMIGRATE.BAT or DBMIGRATE.NCF) from the server console.

    4.

After you migrate the database, you can use the inventory policies to choose when you want to rescan the workstations. For more details on how to migrate the ZfD 2 inventory data to ZfD 3.2, see Migrating the Inventory Information from the ZENworks 2 Database in Understanding Workstation Inventory in Administration. This documentation also provides several scenarios that may help you in the migration process.