NDS and Z.E.N.works: Creating Transparent, Easily Managed Networks
Articles and Tips:
01 Oct 1998
Editor's Note: Does your company need Novell Directory Services (NDS)? Or is your company using NDS to its full potential? Over the next year, the Novell Certified Professional section will be focusing on NDS, explaining how you can use NDS today to better manage your company's network. The Novell Certified Professional section will feature NDS-enabled products (such as Novell's Z.E.N.works), how-to articles, and tips and tricks.
Do you dream of a network that is so easy to use it is invisible to the user and practically manages itself? In May, Novell began shipping Zero Effort Networks (Z.E.N.works), bringing these dreams closer to reality. Z.E.N.works is a desktop management tool that works with Novell Directory Services (NDS) to make the network transparent to users and easier to manage.
NDS PROVIDES THE FRAMEWORK
Although a completely transparent, self-managing network may seem impossible, Novell has made strides toward this goal with NDS. NDS provides a framework that integrates all network components, including users, computers, printers, modems, fax devices, applications, and operating systems. Because NDS integrates these components, you can access and manage all network devices from any workstation on the network. And no matter which workstation a user uses to access the network, NDS provides a consistent view of all available resources.
Z.E.N.works simplifies access and management of network resources even more by extending NDS to include information that is normally stored on Windows NT, Windows 95, or Windows 3.x workstations. For example, Z.E.N.works uses NDS to store information such as applications, printers, and the appearance of the desktop. With NDS and Z.E.N.works, users see a familiar environment, whether they log in from their own workstation, a workstation down the hall, or a workstation halfway around the world.
Z.E.N.works and NDS save you time because they eliminate the need to manually configure each workstation on the network. If you need to troubleshoot a workstation, NDS and Z.E.N.works allow you to view user and workstation information and to remotely control the workstation--all without leaving your desk.
ZERO EFFORT NETWORKS
If you are like most network administrators, you spend countless hours walking to workstations to install new applications, to troubleshoot problems, and to perform routine maintenance. Manually performing these tasks not only increases management costs but has a significant impact on users' productivity. Users sometimes have to wait days or even weeks to get applications installed or their workstation problems fixed.
Z.E.N.works solves these problems by providing you with tools that reduce the amount of workstation support required on a network. Users can then concentrate on their productivity, without becoming computer experts.
Z.E.N.works includes the following components: application management and distribution, desktop management, and desktop maintenance.
Application Management and Distribution
Z.E.N.works includes the Application Launcher, the application management and distribution software formerly called the Novell Application Launcher (NAL). The Application Launcher works with NDS, allowing you to centrally manage, upgrade, and even distribute applications across your company's network.
Using the Application Launcher, you can dynamically update users' desktops when new applications become available, you can modify registry or INI settings, and you can even provide application load balancing and fault tolerance. You can also use the Application Launcher to handle installation-related questions or problems that may occur months later. You can perform all of these tasks, without leaving your workstation.
Fool-Proof Access to Applications
The Application Launcher insulates users from the complexities of the network. When you install the Application Launcher on users' workstations, the Application Launcher icon appears on the desktops. If users double-click this icon, the Application Launcher window appears, displaying the icons for the applications with which a user is associated. (To give users the necessary rights to run applications, you associate users with these applications.) The definitions for these applications are stored in NDS.
When a user launches an application, the Application Launcher performs all of the tasks necessary to run the application: For example, the Application Launcher connects to required resources (such as network drives and printers), "pushes" down any components needed on the workstation, and updates registry settings. Because the applications are delivered through NDS and are associated with particular User objects, a user sees the same set of applications, regardless of the workstation from which the user logs in to the network.
Application Objects
Using the NetWare Administrator (NWADMIN) utility, you can create Application objects to define applications in the NDS tree. Each Application object contains the information needed to run an application (such as the directory path to the executable file and registry settings).
The Application object also specifies which users can run the application. You can associate Application objects with User objects, Group objects, or container objects. Applications defined in NDS are dynamically delivered to users' desktops, and any changes made to an existing Application object are automatically refreshed on the users' desktop.
You can create Application objects for many purposes--all of which eliminate the need to visit each workstation to install applications. For example, you can create Application objects to do the following:
Provide access to network-based applications (dynamically delivering icons to the desktop)
Install or upgrade workstation-based applications
Install or upgrade Novell client software
Upgrade desktop operating systems
If you are creating an Application object to install a complex application, you can use the snAppShot utility to simplify the installation process. The snAppShot utility keeps track of the files that the setup program installs on the workstation, copies these files, and stores them for use when installing the application. The snAppShot utility also uses special files to record information about the changes an application's setup program makes to the workstation's configuration. The snAppShot utility stores this information as either an Application Object Template (.AOT) or an Application Object Text Template (.AXT).
An .AOT file is written in binary format and cannot be modified. An .AXT file is written in text format and can be viewed or modified with a text editor. The .AXT file takes longer to import into an Application object and is prone to inaccuracies if you do not follow certain .AXT file format standards.
After the snAppShot utility records this information, you can use the .AOT or .AXT file to create and configure an Application object. Then when a user launches the application from his or her workstation, Z.E.N.works installs the application with the configuration that is recorded in the .AOT or .AXT file.
Intelligent Application Launching
Because some companies have so many users who need to access the same applications, these companies have multiple servers to handle the workload. Without Z.E.N.works, providing application load-balancing across these servers requires two steps: You must first organize the users into separate groups. You must then create separate scripts for each group or place an icon on each workstation to point to the correct application server.
This solution is time consuming and labor intensive. Wouldn't it be nice if you could create an icon that pointed to all of the application servers and automatically selected which server would run the application? The Application Launcher provides this automatic load-balancing.
To set up automatic load-balancing for an application, you launch the NWADMIN utility and access the Application Details page for the appropriate Application object. You then open the Fault Tolerance page, enable the load-balancing check box, and add the directory path to the application servers you want to load balance. The Application Launcher will automatically handle load-balancing for this application.
The Application Launcher also provides fault tolerance for applications. For example, if your company had multiple servers, you could select an application to which you wanted to provide fault tolerant access and then install this application with the same configuration on any or all servers. You would then launch the NWADMIN utility and access the Application Details page for the appropriate Application object. You would open the Fault Tolerance page, enable the Fault Tolerance check box, and add the directory path to the servers on which you installed the application.
The Application Launcher would then automatically handle the fault tolerance for this application. When users selected the application, the Application Launcher would contact the primary server. If this server were not available, the Application Launcher would contact the next server in the list and continue this process until a server responded.
You can also configure the Application Launcher to determine the nearest application. For example, suppose a user in the Atlanta office accessed Corel WordPerfect through the Application Launcher. If this user traveled to the San Francisco office, he or she could click the WordPerfect application icon in the Application Launcher window. NDS would then transparently direct the workstation to access the application on the San Francisco server instead of accessing the application across the WAN link on the Atlanta server. In this way, the Application Launcher reduces WAN traffic and costs.
Handling the Windows Registry
The Application Launcher fully supports the Windows registry. If you manually create an Application object, you can define any registry changes you want to include with the application. And as mentioned earlier, if you use an .AOT or .AXT file to create an Application object, the snAppShot utility automatically records any registry changes made when the application is installed.
Supporting Roaming Users
The Application Launcher supports Windows profiles, which enable users to roam. But is supporting these profiles enough? No--because parts of the registry, such as HKEY_LOCAL_MACHINE, are not included in the profile.
To understand why supporting HKEY_LOCAL_MACHINE is important, suppose a user accessed a network application through the Application Launcher. Also suppose this application required several components to be loaded on the workstation. The first time the user selected the application, the Application Launcher would install the necessary components on the workstation and launch the application. The next time the user accessed the application from this workstation, the application would immediately launch--it would not need to be reinstalled.
However, suppose the user logged in to the network from a different workstation. The user would see his or her familiar desktop and the information stored in the Windows profile. If the user launched the same application from the Application Launcher, it would install the needed components on the new workstation before launching the application.
When downloading applications to workstations, the Application Launcher stores application information in special keys in the HKEY_LOCAL_MACHINE part of the registry. Because this part of the registry does not move with the profile from workstation to workstation, the Application Launcher always knows when to download components to the workstation. The Application Launcher simply checks the keys in the HKEY_LOCAL_MACHINE part of the registry to determine if the components have been downloaded to the workstation.
No Traffic Jams, Please
Because the Application Launcher provides so many time-saving features, it is easy to forget that installing a new application on hundreds of workstations at the same time causes congestion on networks and servers. Fortunately, the Application Launcher allows you to spread out the load over a period of time. For example, you could specify that the Application Launcher install an application over a week.
You can also configure Z.E.N.works to automatically upgrade an application on all workstations over a period of time--without user intervention. When you configured the Application object, you would check the "Run Once" box and make the icon show up in the startup folder.
DESKTOP MANAGEMENT
Z.E.N.works also includes the tools you need to manage users' desktops--again, without leaving your workstation. To provide this central management, Z.E.N.works uses NDS to store the dependencies that are normally stored on the workstation. These dependencies include the following:
Desktop Preferences. Desktop preferences are Windows NT and Windows 95 Control Panel options that control the appearance of the desktop. These options include Accessibility, Display, Keyboard, Mouse, and Sound.
Printer Configurations. Z.E.N.works allows you to associate printers and print drivers with workstations. With Windows NT, you can also associate printers and print drivers with NDS users. You can add or remove printers, select a default printer, and assign a print driver to each printer. You can also specify the settings for printers such as the number of copies to print.
Novell Client Parameters. Z.E.N.works allows you to configure Novell Client parameters and to download these parameters to multiple workstations. For Windows 95, you can configure parameters such as Preferred Server, Preferred Tree, Protocols, and Services. For Windows NT, you can configure parameters such as Preferred Server, Preferred Tree, Workstation Manager, and NetWare/IP.
Remote Access Server (RAS) Configurations. Z.E.N.works allows you to configure phone book entries for dial-up networking. Through NDS, you can select a dial-up number, or create, edit, or delete a dial-up entry.
Because these dependencies are stored in NDS, you can make the changes once in the NWADMIN utility and then allow NDS to deploy the configuration to the workstations you have specified. When a user logs in to the network, NDS and Z.E.N.works automatically configure the user's workstation based on the parameters you have selected.
Policy Packages
Z.E.N.works stores workstation dependencies as individual policies in NDS. To simplify the management of these policies, Novell has grouped these policies into Policy Package objects, which you can associate with User, Group, or container objects.
Z.E.N.works includes three types of Policy Package objects: container, user, and workstation. Because Z.E.N.works supports Windows NT, Windows 95, and Windows 3.1x, you can create Policy Package objects for a particular operating system. As a result, you can create seven Policy Package objects:
Container Package object
Windows 3.1x User Package object
Windows 3.1x Workstation Package object
Windows 95 User Package object
Windows 95 Workstation Package object
Windows NT User Package object
Windows NT Workstation Package object
Each Policy Package object contains multiple policies that are customized for a specific operating system. (See "Policy Package Objects.")
Z.E.N.works policies are disabled by default. To enable these policies, you must use the NWADMIN utility to create a Policy Package object. You can then enable a specific policy by clicking the policy's check box. In order for the enabled policies to take effect, you must associate the Policy Package object with a User, Group, or container object.
Effective Policies
Just as NDS has effective rights, Z.E.N.works has effective policies. Effective policies are the sum of all enabled policies in all Policy Package objects that are associated either directly or indirectly with a particular object.
Z.E.N.works leverages the hierarchical structure of NDS, allowing policies to flow down the NDS tree. For example, suppose you enabled the Restrict Login policy in a Workstation Policy Package object and you associated this object with a container object. All of the users in the container object would inherit the Restrict Login policy.
By default, NDS searches up the tree for effective policies. The default search order is leaf object, Group object, and then container objects--until NDS reaches the [Root] of the tree.
You can use the Container Search Policy to modify this search order. By enabling this policy and associating it with a container object, you can change the search order or limit the search to one, two, or all three locations.
For example, you could set the search order to begin with leaf objects and then to search only the parent container object. You could exclude Group objects and any container objects above the parent container object from the search. By limiting the search levels in NDS, you can eliminate unnecessary network traffic.
Windows 95/NT Policy Support
Z.E.N.works supports the user and computer system policies that are included with Windows 95 and Windows NT. (See "Policy Package Objects.") Using these system policies, you can set attributes for the workstation to control the way the desktop looks. These attributes remain the same, regardless of which user logs in from the workstation.
Z.E.N.works has improved these system policies by storing them in NDS and enabling you to create and manage them through the NWADMIN utility instead of Microsoft's POLEDIT utility. NDS and Z.E.N.works provide two benefits:
First, you have a central point of administration for system policies. You create a system policy only once using the NWADMIN utility, and you don't have to copy the system policy to the SYS:PUBLIC directory of each server. When you need to change a system policy, you only have to make the change once.
Second, NDS and Z.E.N.works provide fault tolerance for system policies because NDS is distributed and replicated.
Workstation Inventory Policy
Z.E.N.works also includes a Workstation Inventory policy. You can use this policy to gather workstation inventory information and store this information in NDS Workstation objects.
Z.E.N.works stores the following workstation inventory information in NDS:
Hard disk space
RAM
Operating system version
Interrupts, I/O ports, and DMA channels in use
Services and devices running on the workstation
When a change is made to the workstation, Z.E.N.works senses this change and automatically updates the workstation information in NDS. As a result, you always have the most current information about a workstation at your fingertips.
Roaming Profiles for Windows NT
Z.E.N.works also enables you to store roaming profiles for Windows NT workstations in NDS. As a result, a user has the same profile, regardless of the workstation from which the user logs in to the network. The user's desktop always looks the same, and the user has access to the same applications.
You enable roaming profiles through the NT Desktop Preferences in the NT User Policy Package. By selecting the Roaming Profiles tab, you can enable roaming profiles and define where on the network the profiles should be stored.
DESKTOP MAINTENANCE
Although Z.E.N.works significantly reduces the amount of time you spend visiting workstations, users will still experience problems that require diagnosis and troubleshooting. Unfortunately, there is typically no clear way for a user to notify the IS help desk of a problem. At some companies, users may not know who to call, or they may have to leave a message or wait on-hold until a support technician is available. As a result, companies spend millions of dollars each year on desktop management and loss of user productivity.
To provide a solution for these challenges, Z.E.N.works includes the following desktop maintenance technologies:
A help desk component that is tightly integrated with NDS, allowing users to communicate problems efficiently to the IS help desk
Remote control software for Windows NT and Windows 95 workstations that requires NDS security privileges
Snap-in modules for the NWADMIN utility, allowing you to customize how users participate in diagnosing a workstation problem and which support technicians can remotely control workstations
Help Desk Policies
To help users communicate problems to the IS help desk, you can use the NWADMIN utility to create a help desk policy, which contains the contact information users need when a problem occurs. For example, this policy contains names, e-mail addresses, and telephone numbers.
When a problem occurs, users can use the Z.E.N.works Help Request application (which you can quickly and easily distribute through the Application Launcher) to find the contact information and report the problem through an e-mail message or a telephone call.
The Help Request application then uses information about the user's workstation (which is gathered by the Workstation Inventory policy and stored in NDS) to facilitate the resolution of the problem. A user doesn't need to know detailed information about his or her workstation since this information is stored in NDS.
Remote Control Policies
After a problem is identified, a support technician can use the Z.E.N.works remote control software to connect to the workstation and repair it. The support technician must have the appropriate NDS access rights to remotely control the workstation. To grant these access rights, you create remote control policies that govern who can establish a remote control session and on which workstations.
When you create a Remote Control Policy, you can configure the following:
Enable remote control
Prompt the user to grant permission to have his or her workstation controlled remotely
Give the user an audible signal when his or her workstation is being controlled remotely
Give the user a visible signal when his or her workstation is being controlled remotely
Define the default protocol for the remote control agent
Because the Remote Control policy is contained in both Workstation Policy Package objects and User Policy Package objects, you can manage remote control on either the workstation or the user level.
CONCLUSION
Z.E.N.works makes the dream of a transparent, nearly self-managing network a reality. Z.E.N.works solves most of the application, workstation management, and workstation maintenance challenges you face today, thereby lowering the cost of managing complex networks. (For information about the next version of Z.E.N.works, see "Novell News.")
Sandy Stevens is a freelance writer based in Salt Lake City.
NetWare Connection,October 1998, pp. 24-33
Policy Package Objects
|
Policy Package Object
|
Policies
|
|
Container |
Search Policy |
|
Windows 3.1x User Package Object |
Help Desk Policy Remote Control Policy Workstation Import Policy |
|
Windows 3.1x Workstation Object |
3.1x Computer System Policy Remote Control Policy |
|
Windows 95 User Package Object |
95 Desktop Preferences 95 User System Policies Help Desk Policy Remote Control Policy Workstation Import Policy |
|
Windows 95 Workstation Package Object |
95 Computer Printer 95 Computer System Policies RAS Configuration Novell Client Configuration Remote Control Policy Restrict Login Policy Workstation Inventory |
|
Windows NT User Package Object |
Dynamic Local User Policy Help Desk Policy NT Desktop Preferences NT User Printer NT User System Policies Remote Control Policy Workstation Import Policy |
|
Windows NT Workstation Package Object |
Novell Client Configuration NT Computer Printer NT Computer System Remote Control Policy Restrict Login Workstation Inventory |
NetWare Connection,October 1998, pp. 28
* Originally published in Novell Connection Magazine
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.