November 9, 2006
The following updates were made to this readme:
The information in the following section was changed for this update:
Installing the ZENworks 7 with SP1 Middle Tier Server on Linux Upgrades the OES Xtier Component.
The information in the following section was changed for this update:
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 NetWare®, Windows, or Linux* server platforms is included.
The issues included in this document were identified when ZENworks 7 Desktop Management was initially released. For information about issues corrected after the initial release, see TID 10097368 in the Novell Support Knowledgebase.
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.
What’s New:
For an overview of what’s new in this release, see What's
New in ZENworks 7 Desktop Management with Support Pack 1
in
the Novell
ZENworks 7 Desktop Management Installation Guide.
There are some limitations on the scope and environment where you can use ZENworks 7 Desktop Management.
For more information, see TID 10019161 in the Novell Support Knowledgebase.
If these ports are not opened, the SLES 10 server cannot be added to the eDirectory tree where you plan to install ZENworks.
If NetWare 6.5 SP2 is installed on the server where you authenticate workstations for ZENworks functionality, you will not be able to administer the eDirectory™ tree or a server with ConsoleOne® 1.3.6 until you upgrade the version of the Novell Client™ installed on the machine to 4.9 SP2 or later.
We recommend that you do not install the version of the Novell Client (4.90.0 SP1a) that ships with eDirectory 8.7.3. This version requires additional patches in order to work with Windows Server 2003. Instead, we recommend that you install the Novell Client for Windows 4.91, which is available for download from the Novell Product Download Web site.
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 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.
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 user@company.com
where 2 identifies that you are selecting the second listed item, 1234567890 is your activation code, and user@company.com is your e-mail address.
Then do one of the following:
rug pin -entire-channel oes
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 configure the silent.properties installation file to use the default of installing all of the ZENworks 7 Desktop Management with SP1 components to a cluster node, the installation program experiences fatal errors during the Middle Tier Server installation. These errors are listed in the installation log file.
The ZENworks Middle Tier Server is not cluster-enabled and will not fail over, and the regular ZENworks 7 Desktop Management Services on Linux with SP1 installation program disables its installation to a cluster node. The silent.properties installation method has not been similarly adjusted. If you use silent.properties, we recommend that you select the Server installation set only to avoid fatal errors.
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 the setting, 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:
Open /etc/opt/novell/xtier/xsrvd/envvars in a text editor.
Replace this line:
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}":/opt/novell/xtier/lib
with this line:
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}":/opt/novell/xtier/lib:/opt/novell/nmas/client/lib
Use the following command to restart novell-xsrvd:
/etc/init.d/novell-xsrvd restart
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 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 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.
The Desktop Management Server installation program requires free space on the designated system drive of the workstation from which you are installing. If the installation program fails, it might be because there is not sufficient free space to continue.
You must create sufficient space in order to continue with the installation. If your Windows drive is almost full, you can set the environment variable to use disk space on another drive.
Example: SystemDrive=D:
The Desktop Management Server installation program reads the NetWare server’s autoexec.ncf file to find and use the first listed BIND IP Address statement. If the file has two or more BIND IP Address statements and if the first address is incorrect or inactive, the installation fails.
To correct the problem, make sure that the correct IP address is listed first in the autoexec.ncf file.
If you use a Windows 2000 server with ConsoleOne installed to install Desktop Management ConsoleOne snap-ins to another server, Windows adds the new installation path to ConsoleOne to its registry, which also includes the default location of the previously installed ConsoleOne.
If you use this same Windows 2000 server to install ConsoleOne snap-ins to another server, the installation fails because it uses the default path for installation.
If you cannot install the snap-ins from another server, we recommend that you delete the default value from the following registry entry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App_Paths\ConsoleOne.exe
The Desktop Management Server installation program fails to install to a cluster in a multi-server eDirectory tree when the Prerequisite Check check box is selected and the Cluster object is not the first server in the Server Selection list.
To work around this problem, deselect the check box.
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 the Application object > click , click the tab, then click .
In the field, type \\server_name\sys\public\zenworks\c1update.exe.
or
In ConsoleOne, right-click the Application 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:
When you install the ZENworks 7 with SP1 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.
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.
IMPORTANT:Do not install the ZENworks 7 with SP1 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 Middle Tier Server. For more information, see Configuring
or Reconfiguring Installed ZENworks Processes Running on Linux
in
the 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 . In this case, the workstation does display a prompt for reboot. You can use the 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.
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 the list 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 the list. 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 of to 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 the settings 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 install the Workstation Imaging component of ZENworks 7 Desktop Management.
If you reinstall or upgrade the Workstation Imaging component of the ZENworks Server installation, the following lines are added to the Desktop Managementlog.txt log file:
Imaging\NTa Components NOT successfully installed on
<server_name> at <installation_path>
Imaging\NTb Components NOT successfully installed on
<server_name> at <installation_path>
The installation log file (zenworks_for_desktops_server_installlog.log) indicates that the zenimgdsr.dll file was not successfully copied. This condition exists because the original .dll file remains open on the server during the installation. Both the ZENworks for Desktops 4.x and the ZENworks 7 Desktop Management versions of the .dll are the same, so the failure to install is inconsequential.
If you want to avoid the error, you can rename zenimgdsr.dll on the server and then run the installation program.
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 lists the components that you can optionally uninstall,
including the Middle Tier Server (see Uninstalling
ZENworks Components on a Linux Server
in the 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 upgrade from older versions of ZENworks Desktop Management or ZENworks for Desktops to ZENworks 7 Desktop Management.
When configuring the upgrade Application object for the Desktop Management Agent, you should set the application to , so that after the agent is installed the user can no longer see the application in the Novell Application Launcher. We also recommend that you do not enable uninstall for the Application Object.
Administrator rights are not needed to upgrade the Desktop Management Agent. The user’s privileges are elevated temporarily by the Desktop Management Agent during the installation.
If you upgrade the ZENworks Desktop Management Agent already installed on Windows 98 to the ZENworks 7 version of the agent, the installation displays a message after the workstation reboot stating that an error has occurred in ncred9x.dll. No user login is possible after this failed upgrade and the workstation is left in a bad state.
The error occurs because of a flaw in the Windows 98 MSI engine that does not properly update certain files.
If you want to avoid this problem, you need to include the following property on the MSI Application object for Windows 98 workstations only:
REINSTALLMODE=vamus
This will properly place the files on the Windows 98 workstation.
For more information about setting MSI properties, see “MSI Tab” in “Reference: Application Object Settings” in the “Application Management” section of the ZENworks 7 Desktop Management Administration Guide.
When configuring the upgrade Application object for the Desktop Management Agent, you should set the application to , so that after the agent is installed the user can no longer see the application in the Novell Application Launcher. We also recommend that you do not enable uninstall for the Application Object.
Administrator rights are not needed to upgrade the Desktop Management Agent. The user’s privileges are elevated temporarily by the Desktop Management Agent during the installation.
If you upgrade your ZENworks Desktop Management Server to ZENworks 7 with SP1 (NetWare, Windows, or Linux server platforms) but do not upgrade the ZENworks 6.5 Middle Tier Server software to ZENworks 7 with SP1, and if the Middle Tier Server is running on NetWare 6, workstation associated group policies will fail to distribute to workstations where the ZfD 4.x or ZENworks 6.5 Desktop Management Agent is installed.
To work around this issue, make sure you upgrade the Middle Tier Server to ZENworks 7.
When you upgrade ZENworks for Desktops (ZfD) 3.2 Support Pack 3 to ZENworks 7 Desktop Management with Support Pack 1 (SP1), the zenwsimp.ncf and zenwsrem.ncf files are changed from to their ZfD settings to ZENworks 7 Desktop Management with SP1 default settings. If you want to use the ZfD 3.2 settings for Workstation Import or Workstation Removal, you need to manually edit the files to reset them after the upgrade.
When you upgrade from ZENworks for Desktops 3.2 SP3 to ZENworks 7 Desktop Management with SP1, the SP1 installation program lists components, such as Remote Management Wake-On-LAN and Inventory Proxy, that were not available for the 3.2x release. If you want these newer components to be included in your upgrade, select them for installation when you see them displayed.
If you upgrade a ZENworks Desktop Management Server from ZENworks for Desktops (ZfD) 3.2 SP3 to ZENworks 7 and then you subsequently reimage the workstations in the environment with a ZfD 3.2 image, or if you remove the Novell Client from the existing ZfD 3.2 workstations and then reinstall it, workstation associate applications might not display on these workstations.
If you need to reimage a ZfD 3.2 workstation or remove the ZfD 3.2 client from a workstation prior to it being upgraded to ZENworks 7.x Desktop Management, you should subsequently install the ZENworks 7 Desktop Management Agent on that workstation. Doing so causes the workstation associated applications to reappear.
If you upgrade a ZENworks Desktop Management Server from ZENworks for Desktops (ZfD) 3.2 SP3 to ZENworks 7.x and then you subsequently reimage a Windows 98 workstation in this environment with a ZfD 3.2 image, or if you remove the Novell Client from the Windows 98 workstations in this environment (where ZfD 3.2 is installed) and then reinstall the client, the Novell Application Launcher fails to run on the workstation.
The issue occurs because the application file storage location that used in ZfD 3.2 Application Management (on the server) differs from the file storage location used in ZENworks 7 Application Management (on the workstation).
If you need to reimage a ZfD 3.2 Windows 98 workstation or remove the ZfD 3.2 client from a Windows 98 workstation prior to it being upgraded to ZENworks 7.x Desktop Management, you should subsequently install the ZENworks 7.x Desktop Management Agent on that workstation. The newer version of the Desktop Management Agent recognizes the current location of the application files that have been distributed to the workstation.
When you upgrade to ZENworks 7 Desktop Management with Support Pack 1 Services on Linux, the installation program does not detect ZENworks 7 Desktop Management components that were previously installed. Instead, all components are selected for upgrade by default. If these components remain selected during the SP1 installation (that is, if you don’t change the default selection), those components that were previously installed are upgraded to ZENworks 7 Desktop Management with SP1 and the components that were not already installed are installed for the first time.
Although the installation program interface does not indicate which components were previously installed (this behavior differs from the Windows/NetWare installation), there are no negative consequences if you upgrade them to SP1.
When you try to upgrade the ZENworks 6.5 or the ZENworks 7 XML Proxy Server to ZENworks 7 Desktop Management with SP1, the XML Proxy Server is not selected by default in the installation: the installation program does not detect the previous version of the XML Proxy installed on the server.
To work around this issue, manually select the check box corresponding to the XML Proxy Server in the installation wizard of ZENworks 7 Desktop Management with Support Pack 1.
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.
Some NetWare servers might generate a 500-level error when you attempt to import workstations after editing the hosts file on that NetWare server.
To work around the problem, reboot the NetWare server where you installed the ZENworks Middle Tier Server and whose hosts file you edited for workstation import.
If you try to authenticate through the Middle Tier Server to a Desktop Management Server installed on a Windows 2000 machine that already has Active Directory* (installed because the Desktop Management Server acts as the Primary Domain Controller) and eDirectory (installed to accommodate Desktop Management) both installed, the authentication fails unless the user logs on with a full context.
The reason for this failure is a contention for the default LDAP port between the Active Directory and eDirectory LDAP listeners. To work around this port conflict, during the install of eDirectory either choose an LDAP port other than the default of 389 or modify the object found in the server’s container in ConsoleOne, then use the NSAdmin utility in the Middle Tier Server to configure the Middle Tier Server to communicate over that port.
To configure the port in NSAdmin:
In the Address box of Internet Explorer, type the URL for the NSAdmin utility. For example:
http://server_name_or_IPAddress/oneNet/nsadmin
In the Value field of the LDAP Port configuration parameter, specify the LDAP port number you already set in eDirectory and which the Middle Tier Server should use to communicate with the Desktop Management Server > click Submit.
NOTE:Do not attempt to use another Internet Browser (such as Mozilla Firefox) instead of Internet Explorer to run the NSAdmin utility. Other browsers fail to run NSAdmin properly.
For more information regarding this issue, see TID 10073537 in the Novell Support Knowledgebase.
If you try to manually unload the Middle Tier Server Handlers (for example, xzen.nlm) running on NetWare 6, the server abends.
On NetWare 6, you should use NVXADMDN to unload Apache and Middle Tier handlers. Use NVXADMUP to restart Apache and Middle Tier handlers.
On NetWare 6.5, you should use AP2WEBDN to unload Apache and Middle Tier handlers. Use AP2WEBUP to restart Apache and Middle Tier handlers.
Using ndscons.exe on Windows 2000 to verify the connection between the Middle Tier Server and the Desktop Management Server does not work unless you have Administrator rights for the local Windows 2000 user.
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 click from 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, the link 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:
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.
If you install ZENworks 7 Desktop Management Services with Support Pack 1 on Linux, Automatic Workstation Import will fail on that Linux server if the server also has eDirectory 8.8 installed.
By default, eDirectory 8.8 places the nds.conf file in /etc/opt/novell/eDirectory/conf/ directory, while eDirectory 8.7.3 places nds.conf in its /etc directory. Currently, the import service looks for this file in the /etc directory, and so fails in an eDirectory 8.8 environment. This issue does not occur when eDirectory 8.7.3 on the server is upgraded to eDirectory 8.8.
To work around this issue, create a soft link to /etc/opt/novell/eDirectory/conf/nds.conf in the /etc directory and restart the workstation import service:
ln -s /etc/opt/novell/eDirectory/conf/nds.conf /etc
/etc/inid.d/novell-zdm-awsi start
If you have upgraded a ZENworks for Desktops 3.2 system to ZENworks 7 Desktop Management with SP1, you might be retaining an Automatic Workstation Import policy created in ZENworks for Desktops 3.2 in your eDirectory tree.
When you introduce Linux server into this upgraded ZENworks 7 environment, and then you associate the existing Import policy to the Desktop Management Server installed on a Linux server, Workstation objects fail to import.
The issue occurs because the older import policy causes the import service on Linux to fail. To work around the problem, delete the existing Server Policy package, recreate a new Server Policy Package with ZENworks 7 Desktop Management snap-ins, associate this new package to the Linux server, and then configure a new Import policy.
NOTE:Similar behavior occurs with the Automatic Workstation Removal policy and the Workstation Inventory policy configured in ZENworks for Desktops 3.2. To work around the issue, follow the procedure explained above.
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.
The startup scripts for Windows Workstation Group Policies configured in the Workstation Policy Package might not run consistently when scheduled for system startup in ZENworks 7 Desktop Management, even when is selected.
To work around this issue, run wmwait.exe as the first command in the startup script. This program delays the script and checks whether Workstation Manager has authenticated the connection. When the connection is authenticated, the program closes and the startup script proceeds normally.
Make sure that you do the following as you modify the startup script:
HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Workstation Manager\Group Policies"UseSyncGroupPolicyEvent"=dword:00000001
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, \\137.65.167.123\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 the check box.
In the field, 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)-only environment. In order to run the Novell iPrint client, you must have at least one NetWare 6 (or later) or OES Linux in your tree to