This chapter provides a quick overview of the ZENworks for Desktops system and a high-level view of the changes that occur within your tree. Try to follow and understand this system and how it impacts your current Novell Directory Services installations. Other chapters delve into the details of installation and feature execution.
Novell ZENworks for Desktops requires some changes to your tree structure in addition to installation and extensions to the new ConsoleOne administration tool. Additionally, you need to place new agents on the workstation. This section details the changes that need to occur to implement ZENworks for Desktops into your tree.
When you install ZENworks for Desktops into your tree, it not only copies the executable files necessary to run the software, but it also extends the schema in your tree. The schema extension in your tree introduces several new objects and attributes to your system. Following is a high-level list of the changes to your schema. For a more detailed view of the schema changes, refer to Appendix A.
• Container package object—This object collects for your administration all of the policies that can be associated with a container. You create one of these objects when you want to affect a container policy. One such policy is search, which affects the order of searching for all policies in and below the container.
• Server package object—This object collects all of the policies that are available for servers. The policies for servers in the ZENworks for Desktops product include policies for automatic workstation import. Other server policies that are compatible with this object are included in the ZENworks for Servers product.
• Server group object—This object enables the creation of a group of servers. This is useful when you want to apply a Server Policy Package to a group of servers.
• Service location package object—This package collects the policies in the system that are related to locating services in the network.
• User package object—This object holds all of the policies that are associated with users. This includes such policies as the Dynamic Local User, Remote Control, and Novell iPrint policies.
• Workstation package object—This package contains all of the registered policies for a workstation. These policies can be such items as workstation imaging and inventory policies.
• Workstation image object—This object represents an image taken from a workstation. This image can then be applied to any workstation in the network from some commands in Novell's eDirectory or through a boot process with a floppy.
• Workstation group object—This object enables you to collect a set of workstations into a group. This is useful when you want to apply policies to a set of workstations that are not all in the same container.
• Application object—This object is associated with an application that you want to distribute or make available to any desktop in the network.
• Application folder object—This object enables you to create a menuing/foldering system for the presentation of your applications on the user's Start menu or windowed desktop.
• Database object—This object represents the database in the network where you are storing such information as logs of ZENworks activity and events, as well as hardware and software inventory information.
• Inventory service object—This object represents the inventory service that is configured and running on the network, collecting your hardware and software configurations of your workstations.
• Several policy objects—This is a set of Policy objects that represents policies contained in the User, Server, or Workstation policy packages. These can be such policies as the Help Desk policy, Remote Control policy, or Restrict Login policy, just to name a few. Currently ZENworks for Desktops creates and uses over 36 policies.
Introducing most of these objects to the tree has minimal impact. The only objects that you need to consider because of their size are the Application and the Workstation objects:
The Application object can grow depending on the amount of Registry settings that a particular application contains. You need to be careful where you place these objects because they can be large, especially for some applications such as Microsoft Office.
The Workstation object only introduces approximately 4KB of information. However, the culmination of all Workstation objects in your environment needs to be managed carefully. Be sure to use good design techniques when placing your partitions to make your tree most efficient.
ZENworks Management agents are a collection of services and executables that are required to be on the workstation. These agents communicate with eDirectory either through the Novell Client (optionally installed) or through the Middle Tier Web server. These agents include Workstation Management Agent, Application Management Agent, Inventory Agent, and Remote Control Agent. A supplied executable or downloadable MSI (Microsoft System Installer) version is available for delivery to your workstations. This delivery can be through a push, remote install, or through a Web browser.
Additionally, ZENworks also provides a small agent, called Application View Agent, that only provides delivery of applications to the workstations through a browser. This agent is considerably smaller and can easily be delivered via e-mail or via a browser to help you kick-start your rollout of ZENworks.
To help in the administration of the features and policies of ZENworks for Desktops, the various policies are conveniently grouped into policy packages. These policy packages are logical groupings of policies.
Policy packages can be associated with the various appropriate objects. For example, User Policy Packages can be associated with a single user, a group of users, or a container. Workstation Policy Packages can be associated with a single workstation, a group of workstations, or a container. A single policy package can also be associated with several users, groups, and containers.
Because the system looks for policies by searching up the tree from the User or Workstation object (depending on the application), it is desirable to keep this search from proceeding too far up the tree. Therefore, ZENworks for Desktops includes a search policy found in the Container Policy Package. This policy limits the number of levels and the search order that all ZENworks for Desktops systems use to discover and apply policies.
Various services are used by the ZENworks for Desktop system, and these services are located by the Services Location Policy Package. This package is typically associated with a container and identifies where SNMP traps and the database is located. The applications in the system then use the database specified in the location policy.
In order to assist you in constructing policies, ZENworks for Desktop includes a wizard that is activated with the creation of a policy package object. The Policy Package Wizard is launched when you go to a container and request that a new policy package object be created. Previous versions of ZENworks had a wizard that could be executed from the Tools menu of NWAdmin32; this is no longer supported in ConsoleOne.
The Policy Package Wizard is activated when you create a policy package from the Create menu choice or from the Policy Package Wizard icon on the ConsoleOne toolbar. The first screen, shown in Figure 3.1, presents you with the list of all available policy packages and the list of policies that are contained in each policy.
Once you select a policy package, the right side of the wizard fills in with the various policies that are available. You need to press Next in order to proceed in the creation of the policy package you have selected. You are then asked to enter the name of the policy package and the container where the package should reside. This screen is shown in Figure 3.2.
After selecting the name and container, you are presented with a page that lets you go back to create another package or select the option to define additional properties for the package you are about to create. When you select the additional properties option and press Next, the wizard creates the object and then opens the object properties, just as if you had browsed to the object and selected properties. Now you can modify and activate specific policies in the package.
Once you have user objects in your tree and have the ZENworks management agents installed on your users' workstations, you can begin to manage your users in the tree.
The following sections describe at a high level some of the things that you can manage with the User Policy Package.
You can quickly create a User Policy Package by using the following described steps. You'll learn about the details of each policy in later chapters.
-
Launch ConsoleOne.
-
Browse in ConsoleOne to the container where you want to create the policy package. Remember that you can set the package to reside in any container and still associate it with any other container in the tree; but be careful not to replicate large partitions all over your tree just to get to the policy packages.
-
Select the Container object and then click the right mouse button and select the policy package object. This opens the Policy Package Create Wizard to walk you through the creation.
-
Select User Package and follow the wizard to identify the container and the name of the object. Pick Define Additional Properties in the last wizard page so you can activate some policies. If you didn't do this, browse in ConsoleOne to the container that has your User Policy Package and select that object. You can double-click or right-click and choose properties from the menu.
-
You are presented with the property page for the user package you have defined. The screen should look like the one in Figure 3.3.
-
Under the general category, you can activate both the Remote Control and the Novell iPrint policies. Clicking the small triangle next to the Policies tab and then selecting the desired workstation type from the drop-down menu can access the workstation specific policies. Once you select the workstation type, the policies tab for that specific workstation is displayed.
-
Mark the Remote Control policy check box.
-
Go into Remote Control policy properties by either double-clicking to get to the properties or by selecting the details button.
-
Once in the properties of the Remote Control policy, you can select various configuration options on the pages displayed to enable the user to see and run the Remote Control application. The Remote Control policy is described in detail in later chapters.
-
Press OK to complete the changes. If you have not associated this policy package with a container, group, or user object, a notification is displayed (see Figure 3.5).
-
Click Yes to associate this User Policy Package with a container in the tree. This once again brings up the property pages of the User Policy Package and displays the Associations page (see Figure 3.6). You need to then press the Add button and browse to the container, group, or user you want to receive this policy package. Remember, every user below the identified container, within the specified group or the associated user, receives this policy package and all policies activated in this package.
-
Press OK to complete the change.
You have now created a simple User Policy Package and turned on the Remote Control policy for all of the users associated with this policy package. Now when the remote control agent reads this policy, it will enforce the configurations specified.
Before you can start really managing the workstation, you must create Workstation objects and associate them with physical workstations. This step is not necessary if you do not want to manage the physical device, but instead want only to manage the desktop. For example, if you only want to deliver applications to the workstation and apply Microsoft policies to the desktop when a user is logged into the workstation, it's best to associate a user policy to the particular user. However, if you want to manage the physical inventory in addition to managing the workstation accounts, you must first have the Workstation object.
The following sections describe the automatic workstation methods of importing a workstation into the tree.
To get the system up and running, you must first have an Import Policy active in your tree and the agents running on the server and workstations. You must do the following to get a functioning Import Policy in your tree:
-
Activate workstation agents.
-
Activate server agent (only for automated workstation import).
-
Create a policy package (User package for manual, Server package for automated).
-
Turn on the Import Policy in the policy package.
-
Associate the policy package.
-
Set the Registry keys or DNS host file on the workstation through an application package to notify the workstation which eDirectory tree or Middle Tier to use as its primary tree.
-
Enable login cycles to register the workstation to the tree and have the server agent automatically create the Workstation object and associate it to the device.
-
Associate other policies to the Workstation objects to affect management.
If you want to have automated workstation import in your network, you should have installed the automatic workstation agents onto the server as part of the installation process.
These agents on the workstation get into contact with the agents on the server through DNS services. You must either have a DNS server in your network with the DNS name of the automatic workstation import server registered (you gave the name at installation time) or each workstation must have the DNS name and address in the host file. The hostname must be zenwsimport, because the agents will be doing a hostname lookup with that name to find the IP address of the server with the service. This can also be done through a Registry key on the workstation (HKEY_LOCAL_MACHINESoftwareNovellENworkszenwsreg with the string value of ImportServer=DNS or IP address of the import server).
The agents must be running on the server. You accomplish this by executing the ZENWSIMP.NCF file for NetWare or by having the install process install the automatic workstation import service on the NT/2000 servers.
Note
A NoSuchMethodError event can occur when workstations attempt to register the agent if you do not have the latest JNCP.NLM and NJCL.JAR files loaded on the server before running the automatic workstation import agent. You can also look in the WSREG32.LOG file in the root drive of the workstation for additional clues. The correct versions can be found on the ZENworks for Desktops 4 CD under the companionCD/NJCL directory or from www.novell.com.
To begin the automatic workstation process, you must have a workstation import policy activated and associated with the server that is running the import agents. This is done by creating a Server Policy Package, activating the import policy, and then associating the Server Policy Package with the server via a container, server group, or direct association. Follow these steps:
-
Start ConsoleOne.
-
Select a container to hold the Server Policy Package object.
-
Create the Server Policy Package in the container.
-
Go through the Policy Package Wizard and select a Server Policy Package for the type of package and name the object. Follow the wizard and associate the policy package with the container that has the Server object with the import agent running. Remember that these policies are effective in sub-containers as well, so you can associate the policy package high enough in the tree to affect as many servers as desired.
Now that you have created the Server Policy Package and associated it with a container that holds the server, you need to activate the Workstation Import Policy in the package. To activate the Workstation Import Policy, do the following:
-
Start ConsoleOne.
-
Browse to the container that has the Server Policy Package you want to administer.
-
Select the Server Policy Package and bring up the properties on the object.
-
Select the Workstation Import Policy from the list of policies available. When you select and activate the import policy, the check box will be checked.
-
Perform details of the Workstation Import Policy if desired.
-
Select OK and close out the dialog boxes.
Once you have created a Workstation Import policy, the workstations that have not been registered with the tree will attempt to contact the workstation import agent on the server when rebooted. If a connection is made, the agent receives information from the workstation (to help in the naming), and then creates the Workstation object in the tree and returns that object name back to the workstation. The workstation then stores that information in a secure portion of the Registry and it is associated with that object in the tree.
In the preceding Step 5, you had the option of modifying the details of the Import Policy. Let's discuss briefly some of these options. If you decide to take the default Import policy, when you create workstations, they will be located in the same container as the Server object and will be named by the concatenation of the computer name and the MAC address of the network card. You can change the Import Policy to identify under which container you want the Workstation object to reside (can be absolute or relative to server or policy container) and to name the Workstation object.
The ZENworks for Desktops system always starts with the relevant User, Server, or Workstation object, depending on the feature being executed. Once the User, Server (for agents), or Workstation object is located, the system will walk the tree until it locates the first policy package it can find. Generally once a package is found the configuration set in that policy is applied to the system, and the ZENworks for Desktops feature is activated.
Some features, such as the Microsoft Windows desktop policies, are an accumulation of several ZAW/ZAK policies to which the user can be associated. These policies require that the search proceed until the root of the tree.
Walking to the root of the tree for policy packages can be time-consuming, especially when the tree spans across a WAN link. Therefore, ZENworks for Desktops introduced the search policy that is contained in the Container Policy Package. This search policy limits the levels of containers that all processes search to find their policies.
If the import policy has been created and associated with the Server object and the workstation import agents are running on the server, when a user logs into the system, it activates a workstation registration process. Based on the policy, it might take several logins before the registration occurs.
The registration process includes an agent running on the workstation attempting to resolve the DNS name of zenwsimport. It uses that address to contact the automated workstation import process running on the server. Alternatively, the agent will use the Registry key (HKEY_LOCAL_MACHINESoftwareNovellENworkszenwsreg) with the string value of ImportServer=DNS or the IP address of the import server. The server process receives information about the workstation and the user and then, based on the naming description administered in the import policy associated with the server, it creates a Workstation object for the workstation. Once the object is created, it returns the distinguished name of the Workstation object back to the registration process on the workstation. The workstation then stores the workstation DN information in a secure portion of the Registry and it becomes associated with the given Workstation object.
You can un-register a workstation by running zwsreg -unreg from the workstation (it was installed when the agents were placed on the workstation) that you want to disassociate with an object. The initial rules of Workstation object creation go into effect and a new object is created at the proper time and given to the workstation.
A majority of the remote management features are available to users and administrators via rights in the eDirectory tree on the objects that represent the target device. For example, in order to remote control a target workstation, you can configure ZENworks such that one must have rights in the target Workstation object in order to perform the remote control function.
You must grant individual rights in the tree in order to enable users to perform remote management functions on workstations and user desktops. The following objects in the tree can be granted remote management rights: User, Group, Organizational Role, Organization, Organization Unit, Country, Locality, [Root], and [Public]. Two methods exist that you can use to set up these rights. The following subsections discuss these methods.
A Remote Operators Page is associated with each Workstation object. Figure 3.7 displays this page.
From within this page, you can add users or groups to the list of operators. With each addition, you can check which of the remote management utilities this addition has rights to perform. The choices available are Remote Control, Remote View, File Transfer, Remote Execute, Remote Wakeup, and Diagnostics. Check the box to grant the user or group the rights to perform these functions on this particular workstation.
You can also discover who in the tree has rights to perform some remote management on a specific workstation. You can do this by selecting a workstation in ConsoleOne and running Remote Management Rights from the Tools menu, or by pressing the Display button on the remote operators page of the Workstation object. When this program is activated, it displays a report detailing who has rights to which portions of rights management. A sample output report is shown in Figure 3.8.
With ZENworks for Desktops 4, you can also set a remote control policy that allows you to remote control without a workstation object and without the need to have rights on the object to perform remote control. This option is called Password-based Remote Management and it allows you to remote control a workstation by selecting Tools, Remote Management, Windows from the ConsoleOne tools menu. When prompted, you must enter the IP address of the workstation along with a user password.
In order to keep track of the logging events generated by the workstation agents, other ZENworks server agents, SNMP events, and hardware and software inventories for your workstations, you need to install at least one database into your tree. This database holds all of the events, inventory, and reporting information. You can then generate reports against that database to display information about your workstations in the tree.
You can have a server collect inventory information and then forward it to a local database on that server, or another in the area. You can also have that information rolled up into another enterprise-level database. This allows you the capability to have a local site database that just contains local information and then have that information also included in an enterprise-level database that might contain information from many site databases.
When you installed the database on the server at installation time, a ZfD Database object was created in the same container where the server is located. This Database object represents the database that resides on that server. The object enables you to administer the server where the database is located and the passwords that are used by the agents to gain entry into the database. This object is also used in the Service Location Policy Package that tells the workstation and server agents what database to use for storing their event and logging information.
To get the databases up and functioning for events and logging, you need to do the following:
-
Install the Sybase database onto a server. This places a blank database on the server and puts in the MGMTDBS.NCF file on NetWare to get it started.
-
Create a Service Location Policy Package and activate the database policy. You need to create the package and turn on the database policy that also needs to have a reference to the Database object in the database page.
-
Associate the Service Location Policy Package with a container. This enables agents of users or desktops in that container to locate the database.
-
Application objects that you want to track have a page where you can specify which events you want logged in the database. See additional information in Chapter 5, “Creating Application Packages Using snAppShot.”
Additional administration needs to be accomplished in order to get workstation inventory data into the database. See Chapter 13, “Using ZENworks Workstation Inventory,” for additional information.
Once you have set up an inventory database and identified what you want to store in the database (such as inventory, application launching or failures, and so on), you can run reports against that database.
ZENworks for Desktops 4 uses a JDBC interface to connect and query from the database. You can get to the reports by selecting the Tools, Inventory Reports from the ConsoleOne menu. You are asked to configure the database first, so the system knows which database to communicate with. When you configure the database by selecting Tools, Configure DB, you are prompted for the IP address of the server containing the database. Under the advance options, you can tell the system whether the database is a Sybase or an Oracle server.
In ZENworks for Desktops 4, you can launch semi-custom reports that present you with a screen that lists the available reports and the items in the report that you can customize. When you select a report, you are allowed to select a set of values that must match for the data to be included in the report. This enables you to create reports that are much more informative without the reams of data that were printed out in prior versions. Figure 3.9 displays a sample screen from the Novell Application Launcher report selection.
Once you have selected a report, the system connects with the configured database and then queries the information with a JDBC connection. The results are then placed in a canned styled report and presented in the viewer that pops up to display the information. From the viewer you can save or print the report.
Reports for ZENworks for Desktops are built upon a runtime Crystal Reports engine. Using your own Crystal Reports designer, you can create any number of custom reports for your particular business needs.
ZENworks for Desktops 4 ships with some agents that plug into the Tiered Electronic Distribution system that is included with the ZENworks for Servers product.
These agents allow you to distribute Application objects and the installation files associated with them throughout the servers in your network. They also keep the files and objects up-to-date with the identified “golden” versions.
For more information about how to use the integrated ZENworks for Desktops 4 agents to distribute application objects as TED distributions, check out Novell ZENworks for Servers 3 Administrator's Handbook (ISBN 0-7897-2986-5).