January 21, 2009
The following updates were made to this readme:
The following section has been added:
The information in this Readme file pertains to Novell® ZENworks® 7 Desktop Management, the Novell product for managing desktops on Windows* workstations located inside or outside of your corporate firewall. Information about ZENworks services running on Linux* server platforms is included.
The Novell ZENworks 7 Desktop Management Installation Guide provides detailed installation instructions. It is available on the Novell documentation Web site and as a menu option when running the installation program.
There are some limitations on the scope and environment where you can use ZENworks 7 Desktop Management.
The ZENworks Remote Management Wake-On-LAN feature does not support workstations that have more than one network interface card. This hardware configuration may also be called “multi-homed” workstations or “dual NIC” workstations.
For more information, see TID 10019161 in the Novell Support Knowledgebase.
ZENworks 7 Desktop Management supports only one locale at a time. For example, if Application objects are created using European characters, and if those applications are launched with the Novell Application Launcher on a Japanese workstation, Dr. Watson errors will result.
If you plan to install ZENworks 7 Desktop Management with Support Pack 1 on a SLES 10 server where Novell eDirectory 8.8.1 is installed, you need to make sure that, at a minimum, ports TCP 427 and TCP 524 are opened on the server.
If these ports are not opened, the SLES 10 server cannot be added to the eDirectory tree where you plan to install ZENworks.
Based on limitations of Windows 98 MSI support, a “response” transform (.mst) of the zfdagent.msi created with InstallShield AdminStudio is not supported. This limitation will be removed when Novell ZENworks Desktop Management no longer supports the Windows 98 platform.
ZENworks 7 Desktop Management Services on Linux (that is, the Desktop Management Server and the ZENworks Middle Tier Server software installed on Linux servers) does not support installation on SLES 9 servers. SLES 9 SP1 (or later) is required.
The ZENworks 7 Suite with SP1 R3 does not support encrypted attributes, a feature included in Novell eDirectory 8.8x.
The ZENworks 7 Middle Tier Server is currently not supported on any 64-bit version of the SLES 9 or SLES 10 operating systems.
Installation of the ZENworks 7 Middle Tier Server with SP1 IR2 on a network cluster is not supported.
NOTE:If you mistakenly choose to install the Middle Tier on a Linux cluster, the installation program continues to run the novell-zdm-cluster rpm, using NULL as the Middle Tier component. The Middle Tier server is not actually installed.
For information about Middle Tier Server Installation limitations, see Section 4.5, Middle Tier Server Installation Issues.
This section explains the installation issues for the Desktop Management Server, the Middle Tier Server, and the Desktop Management Agent. It also discusses some installation issues for Desktop Management components such as Application Management and Workstation Imaging.
Issues with installing ZENworks Desktop Management services on a Linux server are grouped together for your convenience.
We recommend that you do not change the default provider order of the network connection services on the machine where you are running the ZENworks 7 Desktop Management with Support Pack 1 installation program. Changing the order from the default creates errors in the installation program.
This section explains the issues that have been discovered with the installation of the Novell ZENworks 7 Desktop Management Services on an OES Linux cluster.
When you attempt to fail over an OES Linux cluster after installing ZENworks Desktop Management, the services do not start. This is because the cluster load and unload scripts are not updated during installation of ZENworks on an OES Linux cluster (OES SP2 or earlier).
Workaround: As a prerequisite to installing ZENworks, you must patch the OES Linux cluster.
If you upgraded to OES Linux SP2 using the support pack, run the oessp2prepatch.sh script.
For information, see the OES Linux documentation.
If you have not yet done so, purchase an activation code from Novell Customer Care for updating OES Linux.
On your OES Linux cluster server, open a terminal window as root.
Enter rug sl.
This should display Novell_Update_server somewhere in the list.
Assuming that Novell_Update_server is the second item listed, enter:
rug act -s 2 1234567890 email@example.com
where 2 identifies that you are selecting the second listed item, 1234567890 is your activation code, and firstname.lastname@example.org is your e-mail address.
Then do one of the following:
For the entire OES Linux update (recommended), enter:
rug pin -entire-channel oes
For only the applicable kernel and NCS patches that are required to resolve this problem, enter:
rug pin patch-11078
rug pin patch-11130
Reboot the cluster.
Install ZENworks to the cluster.
This section explains the issues that have been discovered with the installation of the Novell ZENworks 7 Desktop Management Services on Linux.
When you open ConsoleOne for the first time after installing ZENworks 7 Desktop Management on a Linux server, a license pop-up message displays. You must enter the license code to administer the ZENworks Desktop Management Linux machine.
Although the Installation Complete message states that all installed ZENworks services have been started, the proxydhcp service is not started after the ZENworks 7 Desktop Management Services on Linux installation is completed, nor is it started after a reboot. To start the service, run /etc/init.d/novell-proxydhcp start. If you want the service to be started after a reboot, you can use a runlevel editor and add the daemon to the required runlevel.
If you select Middle Tier component while performing silent installation on a SLES 10 server or OES (Linux) 2.0 server, the installation fails because the ZENworks 7 Middle Tier Server is not supported on a SLES 10 server and OES (Linux) 2.0 server.
Silent Installation is not yet supported on clusters.
If you open YaST after installing only the ZENworks 7 Middle Tier Server on a SLES 9 server, then you select Software Installations and then click, errors are displayed indicating a dependency conflict.
These errors indicate that the dependency is on novell-zenworks-common, which is not copied to the server unless you also install the ZENworks 7 Desktop Management Server to the same machine.
You can disregard this error if the Middle Tier Server is installed by itself on the SLES 9 server.
If you install ZENworks 7 Middle Tier Server on an OES (Linux) server (shipping version) and then you enable thesetting, all users logging in through the Middle Tier will fail to authenticate. Administrators are also unable to log in; consequently, the NSAdmin utility becomes unusable.
To work around this issue, you can do one of the following:
Install a newer version of the Middle Tier Server for Linux (novell-xtier-web)
Edit the /etc/opt/novell/xtier/xsrvd/envvars file:
Open /etc/opt/novell/xtier/xsrvd/envvars in a text editor.
Replace this line:
with this line:
Use the following command to restart novell-xsrvd:
When you attempt to install ZENworks 7 Desktop Management with Support Pack 1 on a SLES 9 SP3 server where eDirectory 8.7.3x has been installed, the installation program detects the eDirectory tree, but does not authenticate to it.
This behavior does not occur when ZENworks 7 Desktop Management with SP1 IR2 is installed on an OES Linux SP2 server where eDirectory 8.7.3x is installed.
To work around the problem, you need to add an eDirectory partition replica to the SLES 9 SP3 server.
The ZENworks 7 Desktop Management with SP1 IR2 Services on Linux installation fails if it is started from the user interface as a non-root user. No error messages are displayed with this failure. Subsequent attempts to start the installation from a terminal prompt as root also fail.
To work around the problem, reboot the computer, log in as root, and try the installation again as root.
For more information, see TID 3233134 in the Novell Support Knowledgebase.
This section contains information about the issues that might occur when you install the Desktop Management Server.
When you install ZENworks 7 Desktop Management Services, the installation creates a new ConsoleOne Update Application object in the eDirectory tree. This object will not work until you have configured it properly.
To configure the object:
In ConsoleOne, right-click theApplication object > click , click the tab, then click .
In the \\server_name\sys\public\zenworks\c1update.exe.field, type
In ConsoleOne, right-click theApplication object > click , click the tab, then click .
In the Path to file field, type %SOURCE_PATH%\zenworks\c1update.exe.
This section contains information about the issues that might occur when you install the Middle Tier Server.
If you install the Novell Client on a Windows 2000/2003 server, then install the Middle Tier Server on the same machine, then uninstall the Novell Client from this server, the Middle Tier Server fails. The client uninstall program removes important files needed by the ZENworks Middle Tier Server.
In this same software combination scenario, if you subsequently upgrade the client to 4.9 SP2 (or later), a different version of nicm.sys will be installed. If you do not use the nicm.sys included in ZENworks 7 Middle Tier Server, the Middle Tier Server fails.
To work around this issue, you have two options:
Save the nicm.sys file included in the ZENworks 7 Middle Tier Server installation prior to the client upgrade and then recopy after the client upgrade (this could also be accomplished by reinstalling the Middle Tier after the client upgrade).
After the client upgrade, download nicm.sys from TID 10093371 in the Novell Support Knowledgebase and copy it to overwrite the updated client version of nicm.sys.
When you install the ZENworks 7 with SP1 IR2 Middle Tier Server to an OES Linux server, the existing Xtier component used by other Novell products (such as NetStorage) is forcibly upgraded to work with ZENworks 7 Desktop Management with SP1 IR2.
The following table lists the Xtier RPMs that are installed by NetStorage and the Xtier RPMs installed by the ZENworks Middle Tier Server. The RPM list was obtained by using the rpm - qa |grep novell- x command.
NetStorage RPMs (installed by NetStorage in OES Linux SP2)
ZENworks RPMs (installed by Desktop Management 7 with SP1 IR2 Middle Tier Server)
novell- xtier- web- 3.1.3- 12.sles9
novell- xtier- web- 3.1.4- 4.sles9
novell- xtier- core- 3.1.3- 12.sles9
novell- xtier- core- 3.1.4- 4.sles9
novell- xtier- base- 3.1.3- 12.sles9
novell- xtier- base- 3.1.4- 4.sles9
IMPORTANT:Do not install the ZENworks 7 with SP1 IR2 Middle Tier Server to a server where NetStorage is already installed. Doing so alters the /var/opt/xtier directories, making them incompatible with NetStorage.
If upgrading the Xtier component might create a problem for your users, you can use the novell-zdm-configure utility to configure the existing version of Xtier to work with the ZENworks 7 with SP1 IR2 Middle Tier Server. For more information, see Novell ZENworks 7 Desktop Management Installation Guide.
If you are already experiencing NetStorage failure because you installed the ZENworks Middle Tier Server, you can reference one of the following TIDs in the Novell Support Knowledgebase for help:
This section contains information about the issues that might occur when you install the Desktop Management Agent. For more information, see TID 10078667 in the Novell Support Knowledgebase.
IMPORTANT:The version of the Desktop Management Agent that shipped with ZENworks for Desktops 4.0 is no longer supported. Prior to upgrading the Desktop Management Agent to ZENworks 7, users should replace this older version of the agent with the version of the agent shipping with the ZENworks 6 Suite (ZENworks for Desktops 4.0.1/SP1b) or later.
The Microsoft Windows Installer engine (msi.dll) and the Windows Installer executable (msiexec.exe) must be present on the workstation in order for the Desktop Management Agent MSI package to be unpacked and executed. Some Windows 98 workstations might not have the MSI engine installed, so the Desktop Management Agent MSI package will not install.
You can obtain the latest version of the Windows Installer from the Microsoft downloads site or you can use the MSI 2.0 file (instmsia.exe) that is available in the \microsoft windows installer\98 folder of the Novell ZENworks 7 Companion 2 CD.
If you distribute the Desktop Management Agent MSI through Application Launcher to a Windows workstation, users should not have ConsoleOne open on those workstations.
If ConsoleOne is open during the distribution, the Desktop Management Agent Installation MSI fails.
We recommend that you do not configure the Desktop Management Agent MSI object to allow for a user-based uninstall because the workstation does not currently prompt for a reboot when the user executes an uninstall by right-clicking the Application object icon.
If you grant Administrator rights to the user, he or she can uninstall the Desktop Management Agent using agentdistributor.exe utility located in the sys:public\mgmt\consoleone\1.2\bin folder of the Desktop Management Server when ZENworks 7 has been applied to that server. Using this utility, you can “push” the latest agent to workstations based on their IP address.. In this case, the workstation does display a prompt for reboot. You can use the
If you or a user install myapps.html on a Windows 98 workstation, some ZENworks Management Agent files are installed on that workstation that cannot be subsequently uninstalled in the feature of the Windows .
This might cause a problem if it becomes necessary to install the Novell Client on the same workstation; the client installation program detects the Desktop Management Agent files and will not proceed until the Agent (or its files) is removed from the workstation. Because the files do not constitute the entire installation of the Agent, there is no listing of the Desktop Management Agent in.
For more information, see TID 10094298 in the Novell Support Knowledgebase.
If you install application plug-ins from the Application Browser view (myapps.html) on a Windows 98 workstation, and if you subsequently install the full ZENworks Desktop Management Agent on that workstation using the agent MSI available from the Application Browser view, the Application Browser view stops working.
The problem occurs because of file name truncation occurring during the MSI installation from the Browser view. We recommend that you install the Agent MSI on Windows 98 using a method other than the Application Browser view.
If you or a user uninstall the ZENworks 7 Desktop Management Agent from a Windows 98 workstation, the uninstall process might fail with the following error message:
Error 1605: This action is only valid for products that are currently installed
The failure is due to the Windows 98 MSI Installer incorrectly setting up the Windows registry for uninstall.
InstallShield Consumer Central has published a Knowledgebase resource that provides some steps for working around the problem. The workaround recommends that you run utility to clear registry entries from the workstation. The utility is available for download at the Microsoft Support site.
If you install the Novell Client 4.9 SP1a, then install Novell NetIdentity 1.2 (from the same Novell Client CD), then install the ZENworks 7 Desktop Management Agent, and then remove the Agent, NetIdentity will not work because the Agent NetIdentity files are removed.
To work around this problem, you need to use the Windows Add/Remove Programs utility to remove NetIdentity, then you need to reinstall it.
If you install NetIdentity on a clean workstation using the Novell Client, NetIdentity is listed in thelist of the Windows .
If you subsequently install the ZENworks Desktop Management Agent (which also installs NetIdentity) on this workstation, you can use Add/Remove Programs in Windows to “remove” NetIdentity from the workstation, but NetIdentity is not truly removed from the machine; it is simply removed from thelist. NetIdentity is not removed until the ZENworks Desktop Management Agent is uninstalled.
If you install the Novell Client 3.x and enable Workstation Manager on a Windows 98 workstation, then install the ZENworks 7 Desktop Management Agent, and then you uninstall Novell Client 3.x, Workstation Manager is uninstalled on the workstation, so no policies are distributed to the workstation.
To correct this problem, you must uninstall the Desktop Management Agent and re-install it on the Windows 98 workstation.
If you install the ZENworks 7 Desktop Management Agent and subsequently distribute or “roll back to” a previously shipped ZENworks for Desktops 4.0.1 patch or interim release, the workstation is no longer recognized as imported and workstation associated applications do not appear in the Novell Application Launcher views.
If you have already installed the ZENworks 7 Desktop Management Agent, we recommend that you do not roll back to a ZENworks for Desktops 4.0.1 patch or interim release of the Desktop Management Agent.
Installing the ZENworks 7 Desktop Management Agent on a workstation will overwrite some third party network login GINAs. The ZENworks 7 Desktop Management Agent supports the following third party GINAs (that is, they will not be overwritten by the Desktop Management Agent installation):
If some other third-party GINA (that is, a GINA not in this list) is already installed on the user workstation, the Desktop Management Agent will not install. You can use the IGNORE_3RDPARTY_GINA MSI property with a setting ofto force the installation of the Agent and overwrite the third party GINA.
IMPORTANT:Some other third party GINAs will not function if they are not the primary (that is, the first) listing in a Microsoft GINA chain. This causes a problem on workstations where the Desktop Management Agent is already installed: the Agent requires the primary listing in the chain and will disable the third party GINA.
The Desktop Management Agent Distributor (agentdistributor.exe) included with ZENworks 7 can cause excessive CPU cycling on the Windows workstation that you use to distribute the agent. The problem occurs when several configuration elements are selected. Desktop Management Agent features, the Middle Tier address, and the ZENworks tree name all contribute to lengthen the command line. If the command line string becomes too long (approximately 240 characters) the ZDPAService used to deploy the agent uses excessive CPU cycles. This can possibly lock up the machine.
One way to reduce the length of the command line is to select all of the features that can be installed with the Desktop Management Agent. This will result in an abbreviated command line (ADDLOCAL=ALL) being passed to the buffer so that the Agent Distributor will run normally.
IMPORTANT:This procedure installs all the features of the Desktop Management Agent. Depending on your business needs, you might not want to install all of these features on user desktops in your organization. We do not recommend that you install Agent features one at a time.
For more information about the Agent Distributor, see “Using the Desktop Management Agent Distributor to Deploy the Agent to Workstations in a Microsoft Domain” in the Novell ZENworks 7 Desktop Management Installation Guide.
If you launch the Agent Distributor utility (either independently or from ConsoleOne) from a Windows server whose locale is set to Spain or Honduras, the English version of the utility is displayed.
To work around this issue, use thesettings in the Windows Control Panel to set the regional format to a Spanish-speaking locale other than Spain or Honduras.
The Microsoft RDP 5.1 client (msrdp.ocx) is included with the ZENworks 7 Launch gadget. When a user launches a terminal server application that you've configured to run in an RDP client session, the Launch gadget generates an error message indicating that the certificate for the file has expired.
If you click Yes in the error message to continue the installation, the Launch gadget installs the msrdp.ocx file to the c:\program files\novell\zenworks directory on the user's workstation and registers the .ocx file.
If you install the msrdp.cab file to a workstation using the ZENworks Management Agent installation program, no error messages are displayed.
This section contains information about the issues that might occur when you use the uninstall program for ZENworks 7 Desktop Management Services on Linux with SP1.
The Uninstall feature for ZENworks 7 Desktop Management Services on Linux with SP1 IR2 lists the components that you can optionally uninstall, including the Middle Tier Server (see Novell ZENworks 7 Desktop Management Installation Guide for more information).
Most RPMs updated by the ZENworks installation program can be uninstalled. For example, if you upgrade the Xtier component, and then you choose to uninstall all ZENworks features, Xtier is removed regardless of whether it is being used by other programs. In all cases, RPM versions greater than or equal to what is required by ZENworks are not updated, and therefore cannot be uninstalled.
This section explains the issues that might occur when users try to authenticate to the Desktop Management Server using either the Novell Client or the Desktop Management Agent for login.
A workstation with the Desktop Management Agent installed and running in Passive mode without the Novell Client presents the following option in a drop-down box when you clickfrom a Windows Security dialog box (Ctrl+Alt+Delete):
<Novell Netidentity Credentials Provider>
This option for changing the eDirectory password from NetIdentity is currently non-functional. To change the password for the Agent running in Passive mode, open the Control Panel, click, and change the password in the appropriate dialog box.
If the Novell Client and the Desktop Management Agent are installed on the same workstation and the user logs in to the local workstation, then opens myapps.html and clicks the link in the Application Launcher Web View, the NetIdentity login does not work. This is designed behavior. If a workstation has the Novell Client and the ZENworks Management Agent both installed, Application Management always uses the Novell Client.
If only the Agent is installed on the workstation, in this same scenario, thelink in the Web view activates the NetIdentity login.
Workstations that use the ZENworks for Desktops 4.x Desktop Management Agent cannot access files (such as applications to be cached) from a Desktop Management Server installed on Windows if the files must be accessed through a Middle Tier Server installed on a Linux machine (SLES 9 SP1 or OES Linux).
The problem occurs for two reasons:
The 4.x Agent does not have a ZENMUP to redirect communication directly to a Windows server.
The Linux Middle Tier Server does not have a full CIFS provider to obtain files from a Windows server.
You can work around this problem by installing a ZENworks 6.5 (or later) Desktop Management Agent, which uses ZENMUP to communicate directly to the Windows server.
If you install ZENworks 7 Desktop Management with Support Pack 1 on a SLES 9x server, make sure that the server has been patched with a version of the openldap2-client dated February 2005 or later.
If users log in to the Middle Tier Server on SLES 9x server where an earlier version of openldap2-client has not been updated, the Middle Tier service maximizes the CPU utilization and freezes the Middle Tier.
Testing indicates that excessive login times result when workstations authenticate through a firewall and copy policy files or application files at login time.
To work around this issue, we recommend that you configure applications and policies to use DNS names for file locations on the back end, rather than IP addresses.
To determine whether you are logged in to a Kerberos Realm, you need to activate the ZENworks Desktop Management Agent login at the workstation by using the Ctrl+Alt+Del key combination. This displays the Windows Login information, including the login to Kerberos (if present).
If you open ZENworks Agent Options (the red “N” icon) in the Windows Control Panel to view the Windows Login information, no Kerberos Realm information displays on the dialog box, even though the login information for the Windows workstation is shown.
This section identifies some areas of the Desktop Management Workstation Import and Removal component that might not work properly or that might require further configuration in ZENworks 7 Desktop Management.
If, during eDirectory installation on a SLES 9 server, the LDAP port was set to listen on a port other than port 389, Automatic Workstation Import will fail when run on that server.
It is now possible to manually configure the novell-zdm-awsi.conf file to allow alternate ports to handle Automatic Workstation Import. Use the following steps to modify the .conf file:
Using a text editor, open /etc/opt/novell/zenworks/zdm/novell-zdm-awsi.conf on the Linux server.
Find the following line in the file:
#LDAP_PORT = 389
Uncomment the line and change the port number from 389 to the port you want to use.
Save the file and close it, then restart the import service.
Automatic Workstation Import fails when attempted on a SLES 10 Desktop Management Server with a firewall enabled. This is the default SLES 10 configuration.
To enable Workstation Import in this circumstance, open TCP port 8039 on the SLES 10 firewall.
This section identifies some areas of the Desktop Management Workstation Management component that might not work properly or that might require further configuration in ZENworks 7 Desktop Management with SP1 IR2.
This section discusses some aspects of Windows Group policy administration that might not work properly or that might require further configuration in ZENworks 7 Desktop Management.
If you apply a workstation group policy created for Windows XP that is configured with security settings and you also apply a user group policy created for Windows XP that is configured with security settings (for example, you want to define a user certificate), the security settings applied with the user group policy overwrite the security settings applied by the workstation group policy.
If you disable the security settings in the user policies, the security settings configured in the workstation policy are set and activated.
If you use an explicit IP address in the file path when you associate a group policy to a user or workstation (that is, in ConsoleOne, you supply an IP address in the path to the policy—for example, \\18.104.22.168\c$\pathname), you cannot log in from an XP workstation with the Desktop Management Agent installed.
You should use the server name in the path rather than an IP address.
If you launch the Microsoft Management Console (MMC) from ConsoleOne to edit a Windows Group Policy—specifically to rename a default user account (Administrator or Guest), you must not be logged in as the user whose default account name you are changing. If you log in using this default account and rename the account, the changes are not saved to the network path you designate in ConsoleOne and might remain on the administration machine.
If network users with Roaming Profiles are seeing multiple c:\documents and settings\username.machine_name.nnn folders on a Windows workstation where they log in, or if users notice slow Windows logoffs or slow workstation shutdowns, it might be due to Windows registry keys being left open.
To work around this problem, download and use the Microsoft User Profile Hive Cleanup Service, a utility that closes open registry keys in the user hive, allows Roaming Profiles to be deleted normally at logoff time, and allows faster workstation logoffs and shutdowns.
We recommend that you use the Novell Application Launcher™ to distribute this MSI application to all affected workstations.
You can also try the NAL Restart Utility (zennalrestart.exe). This utility restarts the Novell Application Launcher Service upon user logout, effectively directing all registry keys previously opened by the service to be closed. To download the utility see TID 2971971 in the Novell Support Knowledgebase.
After ZENworks 7 Desktop Management installation, iPrint printers are not distributed to users running Windows 2000/XP workstations, even after the ZENworks 7 Desktop Management iPrint policy is configured in the User Policy package (which installs the iPrint Client and pushes printer drivers to the users) and their workstations are rebooted.
To work around this problem in NetWare 6, modify the AllowUserPrinters value in the iprint.ini file in the \\server_name\sys\login\ippdocs directory from zero (0)—the default value—to one (1), which will allow the user to add the printer. In NetWare 6.5, the iprint.ini file is found in the \\server_name\sys\apache2\htdocs\ippdocs directory.
NOTE:The iprint.ini file is available only if you have installed Novell Distributed Print Services™ as part of a NetWare installation and if you have extracted the nipp.exe to that directory. If you do not have iprint.ini and nipp.exe, you can download them from Novell Support at http://support.novell.com. Search for TID 2968629.
If you use the iPrint policy to distribute printers through a firewall to a Windows 2000/2003 terminal server user session, the policy does not correctly set the required registry key to bypass the iPrint proxy address manual configuration.
Each terminal server session user who needs to print to printers from outside the firewall needs to use the following steps to set the proxy address:
In the User’s Terminal Server session, click> > > , then click the tab.
Select thecheck box.
In thefield, type the external firewall proxy address of the proxy server, then click .
When the proxy address is set, the printer policy distributes without a problem.
The Novell iPrint policy (User and Workstation packages) does not run in a SUSE LINUX Enterprise Server 9 (SLES 9) or SUSE LINUX Enterprise Server 10 (SLES 10) environment. In order to run the Novell iPrint client, you must have at least one OES Linux in your tree to act as the iPrint server.
This section identifies some areas of the Application Management component that might not work properly or that might require further configuration in ZENworks 7 Desktop Management with SP1 IR2.
Although nal.exe and nalexpld.exe are included in the product and still launch executables, their purpose is to facilitate the continued functioning of existing login scripts.
ZENworks 7 Desktop Management with SP1 IR2 only supports switches that are supported by nalwin32.exe. To see a list of these switches, enter the following command:
You see the same switches if you enter the following command:
It is currently not possible to close the Application Explorer window using the Exit Application Explorer option on the File menu.
To close the Application Explorer, click the Close () button on the upper right-hand corner of the Application Explorer window.
Although you can drag an application icon from the right-hand pane of the Application Window view to the Windows desktop, doing so creates a broken shortcut that will not launch the application.
You can work around this issue by launching the Application Explorer view after you create the shortcut. Launching the Application Explorer causes the shortcut to work properly. Later, when you close the Application Explorer, the shortcut is removed from the desktop.
If a user sets the option of using myapps.html as the Web page background for their Windows XP desktop, Windows XP generates script errors and myapps.html does not display applications.
If you want users to use this feature, you need to edit portions of the myapps.html that this feature can't handle. The easiest method is to extract the data from WriteData() function in the file and use it as the content of a new .html file.
The comments of the Web page will look like this:
<title>Novell Delivered Applications</title>
<body scroll=’no’ style=’margin: 0; overflow:hidden’>
<object id="AxNalView" classid="CLSID:4F4B2E32-B44C-450E-8683-6903FE9DDCEA" width="100%" height="100%">
<!--param name="SingleTree" value="ZENWORKS_TREE"-->
<!--param name="PortalView" value="false"-->
<!--param name="BannerURL" value="http://www.company.com/banner.html"-->
<!--param name="BannerHeight" value="80"-->
<!--param name="ShowTree" value="true"-->
<!--param name="ShowTasks" value="false"-->
<!--param name="AppDisplayType" value="1"-->
<!--param name="ShowAppFrameNavigation" value="true"-->
<!--param name="ShowIEToolbarButton" value="true"-->
Save this file to the hard drive. You can then use it as an XP background.
If you access a Web page served by the Apache Web Server, and if that Web page contains Japanese characters, such as the Japanese version of myapps.html, the characters on that page might appear garbled.
This is a known issue with the Apache Web Server, and can be corrected with a simple configuration workaround in Apache. To better understand the problem, see the Sun Developer Network site for an article entitled Creating Multilingual Web Sites with Apache. For specific information about how to work around the problem and configure the server, see the Apache HTTP Server Version 2.0 Documentation article entitled Content Negotiation.
The new Terminal Server system requirement on an Application object applies only to remote Terminal Server sessions. Sessions running at the Terminal Server console are considered to be remote sessions by default. This behavior can be changed by creating the following registry key on the Terminal Server itself:
Creating this registry key will cause sessions running on the Terminal Server console to be treated as non-Terminal Server sessions.
If users have a version of the Novell Client™ older than version 4.9 Support Pack 2 to login locally (that is, “Workstation Only”), the NWGINA will not authenticate to eDirectory and will not make any network requests. In addition, the Novell Client will have an unauthenticated or “monitored” connection to the eDirectory™ tree determined to be the primary tree.
If the user subsequently authenticates from the Novell Application Launcher using the Middle Tier Login, the NetIdentity client authenticates to the ZENworks Management Server serviced by the Middle Tier Server.
Attempts made by the Application Launcher to distribute an application through this authentication will fail because the files to be distributed are located on the server where the client has created a monitored connection. Through this connection, the client sees the sys: volume on the server (all users have rights to the \login directory on the sys: volume of a NetWare server because older clients authenticated by running login.exe).
To work around this issue, the user must right-click the redicon for the Novell Client in the system tray to log in to the server. Users should not right-click the icon in the system tray and select to log in.
When a distributed application is configured to be uninstalled from a workstation, the workstation does not currently prompt for a reboot when the uninstall is complete.
Because the uninstall might affect the Windows registry, other applications reading the registry at startup might be adversely affected unless the workstation is rebooted. Users should always reboot manually after a distributed application is uninstalled.
If you configure an .ini file application to be uninstalled with the Create Or Append To Existing Value attribute selected for uninstall, the value that was added during the original installation is not removed.
The only current workaround for this issue is a manual edit of the .ini file.
A key component of Novell Licensing Services, nls32.dll, does not ship with the current Novell Client. As a result, an error is generated when you try to use Software License Metering and Monitoring in Desktop Management.
To work around this problem, copy nls32.dll and nlsapi32.dll from the companioncd\companion1\licensing directory of the Companion 1 CD to each workstation where you want to check application licenses. On Windows 2000/XP workstations, copy to the c:\winnt\system32 directory. On a Windows 98 SE workstation, copy to the c:\windows\system directory.
When several Application objects previously set for cifs.nlm loaded, the NetWare server might abend when the first application is cached.are accessed by the Novell Application Launcher running against a NetWare 6.5 server with
We have identified the problem and fixed it in a NetWare 6.5 SP1 patch and in NetWare 6.5 SP2.
If you run ConsoleOne and ZENworks 7 with SP1 IR2 snap-ins locally from a Windows XP workstation where the ZENworks for Desktops 4 SP1b or 4.0.1 Desktop Management Agent has also been installed, you will not be able to import or export AOT or AXT files from ConsoleOne on that workstation. Doing so will cause ConsoleOne to crash.
We recommend that you avoid using this combination of software if you want to use ConsoleOne to import or export AOT or AXT files.
Instead, you should launch a local copy of ConsoleOne from a workstation that has the ZENworks 7 with SP1 IR2 Desktop Management Agent installed. This copy should not contain the ZENworks for Desktops 4 SP1b or ZENworks for Desktops 4.0.1 snap-ins.
When you create an application in snAppShot on a Japanese-enabled Windows XP workstation and then browse the applications install directory, the following error might be displayed:
External Exception C0000006
This issue will be addressed in the next release of snAppShot.
If you initiate the distribution of Application object from a cluster resource and then initiate a cluster resource migration before the distribution is complete, the distribution might time out before completing and will generate an error.
To work around this issue, you need to manually relaunch the distribution.
If you attempt to import an existing Application object's .fil files or registry keys when you create new Application object, the import of that information will fail if the location of the older information is located in a path that includes a folder name with a more than 8 characters, a space, or an extended character.
If you distribute chained, dependent applications to a Windows 98 workstation in a ZENworks environment where the Middle Tier and Desktop Management Servers have been upgraded to ZENworks 7 Desktop Management with SP1 IR2 but the Desktop Management Agent has not been upgraded from the 4.x version or from the 6.5 shipping version, the application distribution might fail with various errors.
In this situation, you might see the first few applications in the chain distribute normally, but a subsequent distribution of another application in the chain might seem to place the workstation in a disconnected state.
There are two methods of working around the problem:
Exit the Novell Application Launcher and then relaunch it to restart the distribution.
Upgrade the Desktop Management Agent to version 7.
If you install the Windows Internet Explorer Security Update KB905915 on a Windows 98 SE workstation where the Novell Application Launcher is used, the Web Browser view of the Application Launcher displays an application icon as a black, pixellated square.
We do not anticipate creating a fix for this display issue.
If a NAL application objects distributes either a registry or INI setting and a Windows shortcut that uses one of the special Windows macros such as %*APPDATA%, %*DESKTOP%, and %*STARTMENU%, the macros might resolve to the Local Service account rather than the currently logged in Windows account.
For example, the macros that should resolve to c:\Documents and Settings\Username\Application Data actually resolve to c:\Documents and Settings\LocalService\Application Data.
Workaround: Do one of the following:
Replace the special Windows macros with Windows macros such as %USERPROFILE%\Application Data, %USERPROFILE%\Desktop, and %USERPROFILE%\Start Menu
Distribute the Windows shortcuts in a chained application that does not contain registry or INI modifications.
This section identifies some areas of the Desktop Management Workstation Imaging component that might not work properly or that might require further configuration in ZENworks 7 Desktop Management.
If you selectand you specify a static IP Address on the property page of an Imaging Server Policy, then you restore the workstation image with that setting, and then you later change the setting to , the workstation does not obtain any IP address.
To work around the issue, you need to change the setting to DHCP and reinstall the NIC drivers on the workstation, or you must revert to the static IP setting.
The PXE-on-Disk Setup utility does not detect nor display drivers for PXE-compatible network adapters that are manufactured by NETGEAR, Inc.
The five boot disks created with zimgboot.exe do not have enough room to include all files, including USB drivers.
If a workstation requires USB drivers, users may see error messages similar to one of the following:
Load USB Modules /bin/runme.s: /lib/modules/2.4.22/kernel/drivers/usb No Such File or Directory
Load USB Modules /bin/runme.s: /lib/modules/2.4.22/kernel/drivers/usb/storage No Such File or Directory
If users whose workstations require USB drivers encounter these errors, you should prepare an imaging boot CD for their workstations. An imaging boot CD has enough space to include the proper USB drivers.
When you upgrade the NetWare nodes where Novell Cluster Service is installed to ZENworks 7 Desktop Management with Support Pack 1, ZENworks Preboot Services fails to detect any workstation imaging jobs, even though the Imaging Server policy is configured and applied.
To work around this issue and execute the assigned work, manually access theand select .
If you are running Novell eDirectory 22.214.171.124 or later on a SLES 9x, SLES 10, or OES Linux SP2 64-bit enabled server where ZENworks 7 Desktop Management with SP1 IR2 Linux Services is installed (that is, the Desktop Management Server components), ZENworks 7 Preboot Services causes eDirectory to shut down.
The issue occurs when you configure the Imaging Server policy with rules to enable a workstation to be imaged on its next bootup with a scripted image. When Preboot Services runs, eDirectory shuts down.
To work around the problem, you need to configure the policy so that the location of the image files is a non-Linux server.
This section identifies some areas of the ZENworks 7 with SP1 IR2 Remote Management component that might not work properly or that might require further configuration in ZENworks 7 Desktop Management with SP1 IR2.
The screen blanking feature might not work properly with some video adapters such as VIA Tech VT8361/VT8601, Hawk Eye Number 9 and ATI Rage P/M Mobility AGP 2x that have been configured in the managed workstations. We recommend that you test the screen blanking feature with the video adapter that you have before deploying the Remote Management Agent in your enterprise.
When you invoke the screen blank option on your managed workstation and change the color resolution on the workstation to 256 colors, the managed workstation might hang. To resolve this problem, restart the managed workstation.
If a managed workstation has multiple monitors, a remote session from a management console manages only the primary monitor of the managed workstation.
During a remote control session on the managed workstation, if you change the mode of display from DOS box application mode to full-screen mode, you do not receive updates until you change to the normal mode or close the DOS box.
If a user uses the Remote Desktop Connection to connect to a Windows XP workstation, and then initiates a Remote Control session on that workstation, the Remote Control console will be black and you will not be able to remote control it.
Users with a Windows XP workstation should log in locally before you attempt to remote control their workstations.
During a Remote Control session, you might not be able to remove the active desktop wallpaper on the managed workstation. This affects Remote Management performance.
To work around this problem, you must manually suppress the wallpaper of the managed workstation.
For wallpaper suppression, Windows XP behaves differently from other Windows operating systems. When you set the wallpaper, Windows XP creates a backup of it. When you disable the wallpaper, it is disabled from the primary location only. When you change the settings, the wallpaper might resurface.
Animated and the colored cursors on the managed workstation are not supported for Remote Management.
During a Remote Management session with a Windows XP managed workstation, if you place the mouse cursor on a window that is continuously changing (for example, Task Manager), the mouse cursor flickers at the managed workstation. This cursor behavior is apparent at the managed workstation only.
Wake-on-LAN service running on NetWare 6.5 SP1a (and later) server might not wake up target workstations if the schedule is modified.
To work around this problem, try restarting the service.
On Windows 2000/XP workstations, DirectX applications do not run in exclusive mode during a Remote Control or a Remote View session.
If the Service Control Manager is running when the Remote Management Agent is upgraded to ZENworks 7, the Novell ZENworks Remote Management Service is not created, even after you restart the managed workstation.
To resolve this problem, ensure that the Service Control Manager is closed before upgrade.
On a Windows 98 workstation, when you upgrade the Remote Management Agent from ZENworks for Desktops 4.0.1, ZENworks 6.5 Desktop Management or ZENworks 6.5 Desktop Management Support Pack 1 to ZENworks 7 with SP1, the Remote Management password, if set, is deleted.
Workaround: At the command prompt, enter the following command:
msiexec /i ”path_of_MSI zfdagent.msi” REINSTALLMODE=vamus
If you are installing via MSI application object, specify vamus in the REINSTALLMODE property.
IMPORTANT:This workaround is applicable only if you are upgrading from ZENworks 6.5 Desktop Management or a later version of the Desktop Management Agent.
The Remote Management Agent help might not launch from the Remote Management Agent icon in the system tray of the managed device.
To work around the problem and view the Help, navigate to the following location and double-click rcagent.chm: zenworks_agent_directory\remotemanagement\rmagent\nls\language_directory.
If you log in to the corporate tree from a managed workstation that does not have the Novell Client installed, through a Windows 2000 or 2003 Middle Tier Server, the IP address of the managed workstation might not be displayed when Remote Management is launched from the corresponding User object in ConsoleOne.
To work around this problem, see TID 3287250 in the Novell Support Knowledgebase. The document provides a link to a downloadable .dll that you can apply to ZENworks 7 Desktop Management with SP1 IR2 to fix the display problem.
This section identifies some areas of the Desktop Management Workstation Inventory component that might not work properly or that might require further configuration in ZENworks 7 Desktop Management with Support Pack 1.
If you want to reinstall the Inventory Server or the Inventory Database on Linux, you must first uninstall the component you want to reinstall, then proceed with installing the component again.
If you try to install Sybase for Linux clusters, installation may show the following error:
The installation of ZENworks Desktop Management has FAILED.
The following component(s) experienced a fatal error:
Workaround: This message is non-fatal, because it does not affect the Inventory service. However, check whether the Inventory and Sybase services are up and running.
After installing the Inventory Proxy, ensure that you change the value of Servlet2.path key to //usr//share//java//novell//zenworks//common//XMLProxyServlet.jar , which is present in the /etc/opt/novell/zenworks/zws.properties file.
If the Novell Client is not installed on inventoried workstations, and if you use double-byte characters in the Inventory Service object's scan directory (scandir) path, the .str files are not transferred to the Inventory server.
By default, the scandir path is the installation path where the Inventory server-side components and the database are installed (unless you manually changed it after the ZENworks 7 Desktop Management installation by configuring the Inventory Service object).
The Crystal Report Viewer window does not support keyboard functionality. You must use the mouse to perform all operations in the viewer window.
This section identifies other issues that might cause problems or require workarounds when you use ZENworks 7 Desktop Management with Support Pack 1.
The ZENworks 7 Desktop Management Agent does not work properly with versions of the NSure® SecureLogin earlier than 3.51.1.
If you install the ZENworks 7 Management Agent on a workstation that has a version of SecureLogin earlier than 3.51.1 already installed, the user's login attempts will fail and the workstation will reboot.
If you have already encountered this problem, you can return the workstation to a working state by following the instructions in TID 10096513 in the Novell Support Knowledgebase.
The issues identified in this section are related to how ZENworks interoperates with Novell eDirectory.
If you install ZENworks 7 Desktop Management on an OES Linux server where eDirectory is already installed, and then you subsequently upgrade eDirectory to 126.96.36.199, the Workstation Imaging component of ZENworks Desktop Management fails.
This issue also occurs when OES Linux is upgraded to SP1 or later on a server where ZENworks 7 is installed. To work around the issue, follow the steps in TID 10098801 in the Novell Support Knowledgebase.
Users of ENGL Zim and ENGL Ztoolkit (3rd party products) must upgrade to ENGL Zim 4.0 SP1 and Ztoolkit 4.0 SP1 before applying ZENworks 7 Desktop Management with SP1 IR2; otherwise, problems occur when performing imaging and when deploying automated Windows builds using ENGL tools.
For more information, see TID 3619822 in the Novell Support Knowledgebase.
This section identifies other issues that might cause problems or require workarounds when you use ZENworks 7 Desktop Management.
Workaround: Before upgrading the server from OES 1 to OES 2, manually delete the dhost RPM by executing the following command:
rpm -e novell-zenworks-zmgservices-dhost-7.0.1-0 -- nodeps.
After installing ZENworks in the cluster environment, the Inventory service fails to start automatically because the Database Policy is not effective.
Workaround: Delete the Database Policy and create it again. For setting the ZENworks Database Policy, see
Launching an RDP or ICA application from the Launch Item Gadget on a Windows XP SP2 workstation generates the following error message:
To help protect your security, Internet Explorer stopped this site from installing software on your computer. Click here for options...
If users are using Windows XP SP2 (or greater) workstations, they can click on the information bar at top of thedialog box in order to install the Citrix ICA/RDP client. Alternatively, you can have users contact you for help with installing the Citrix ICA/RDP client.
ZENworks 7 Desktop Management with Support Pack 1 does not support DNS-rooted trees or federated trees.
Workstation Import and Workstation Management (that is, policies pushed to workstations or users) may work differently when users connect through a VPN.For more information, see TID 10096902 in the Novell Support Knowledgebase.
If you are running ConsoleOne on a Windows machine configured with two different IP Addresses on two different networks, ConsoleOne will not be able to send data to eDirectory and will generate an error code.
You may see this behavior if you attempt to create a stream attribute against eDirectory running on a SUSE Linux server.
Currently, log files created by ZENworks 7 Desktop Management Services on Linux are formatted in the UNIX format; that is, they do not include the CR/LF characters typically used by common text editors used in a Windows environment (for example, Microsoft Notepad). This makes it difficult to read such files in a text editor.
To work around the problem, you can use Microsoft WordPad to open the log files. Make sure that the wordwrap option is selected in WordPad by clicking View > Options > Wrap to Window.
In this documentation, a greater-than symbol (>) is used to separate actions required when navigating menus in a user interface.
A trademark symbol (®, TM, etc.) denotes a Novell trademark; an asterisk (*) denotes a third-party trademark.
Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export, or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. Please refer to http://www.novell.com/info/exports/ for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals.
Copyright © 2006 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.
Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed at http://www.novell.com/company/legal/patents and one or more additional patents or pending patent applications in the U.S. and in other countries.
For a list of Novell trademarks, see the Novell Trademark and Service Mark list at http://www.novell.com/company/legal/trademarks/tmlist.html.
All third-party products are the property of their respective owners.