Novell Client for Windows refers to the version of the Novell Client for Windows 7, Windows 8, Windows 10, Windows Server 2008 R2, and Windows Server 2012.
Novell Client 2 SP4 for Windows refers to the support pack release of the Novell Client for Windows 7, Windows 8, Windows 10, Windows Server 2008 R2, and Windows Server 2012 product.
The following changes are included in Support Pack 4.
Novell Client 2 SP4 for Windows is extended to support NCP volumes that are greater than 16 TB.
Novell Client 2 SP4 has implemented the Lazy Close feature which can be enabled in the Novell Client Properties. Prior to Novell Client 2 SP4, theparameter was available in the Novell Client Properties since it was planned and intended for inclusion in Novell Client. However, beginning with Novell Client 2 SP4, setting the parameter to "On" will cause the actual "Lazy Close" behavior to occur.
The Lazy Close feature provides performance benefits for applications that are repeatedly accessing the same files frequently and in rapid succession. Instead of closing a file handle with the NCP server immediately, Lazy Close will wait for a short duration of time, so that if an application wants to immediately re-open the same file again, Novell Client will be able to proceed using the already open NCP file handle without causing any delay.
The Lazy Close feature and the caching of byte-range locks that was introduced in Novell Client 2 SP3 (IR10), intend to further maximize application performance when Novell Client for Windows "File Caching" is enabled. The Lazy Close feature is currently disabled by default, and must be turned on for workstations that use applications which can benefit from this optimization. Also, the Lazy Close feature is always disabled if the File Caching feature is not turned on.
There are optional Lazy Close-specific File and Directory timeouts available that can be configured in the Novell Client Properties. Even though configuration is not required, these parameters are available in case there are application scenarios where a shorter or longer delay can help maximize performance improvements. For more information, see Lazy Close: in the Novell Client 2 SP4 for Windows Administration Guide.
Novell Client 2 SP4 modifies the behavior of the previously introduced Bad Name Cache and Bad Address Cache. Previously, the Bad Name Cache and Bad Address Cache were always enabled, such that every bad server name or address was cached for 5 minutes, with no way to disable these features. Beginning with Novell Client 2 SP4 for Windows, you can now enable or disable the Bad Name Cache and Bad Address Cache using the BadNameCacheEnabled and BadAddressCacheEnabled registry entries. For more information, see TID 7015227.
Novell Client 2 SP4 introduces a Permanent Good Name Cache that enables you to define the list of only those servers and eDirectory tree names that Novell Client should attempt to resolve and connect to. By defining this list, Novell Client will attempt to resolve and connect to only those servers or eDirectory tree names that are specified in this list and will not attempt to connect to any server or eDirectory tree name that is not specified in this list. It is essential to include the eDirectory tree name to this list to enable login to the eDirectory.This feature can be used by using the registry entries PermanentGoodNameCacheEnabled and GoodNameCacheList. For more information, see TID 7015227.
Novell Client 2 SP4 also modifies the registry entry name for the previously introduced Permanent Bad Name Cache feature. Beginning with Novell Client 2 SP3 (IR8), Permanent Bad Name Cache enables you to rectify performance issues caused by delays in attempting to locate resources which cannot be reached by Novell Client. The Permanent Bad Name Cache feature is controlled using the registry entries PermanentBadNameCacheEnabled and BadNameCacheList. In Novell Client 2 SP3 IR (8), the Permanent Bad Name Cache was controlled using the BadNameCacheEnabled registry entry. However, beginning with Novell Client 2 SP4, it is controlled using the newly introduced PermanentBadNameCacheEnabled registry entry. For more information, see TID 7015227.
IMPORTANT:The Novell Client 2 SP4 for Windows (IR1) is only for Windows 7, Windows 8, Windows 10, Windows Server 2008 R2, and Windows Server 2012 on x86 or x64 platforms. This client will not run on Windows Vista, Windows Server 2008, or earlier Windows platforms.
The Novell Client 2 SP4 for Windows (IR1) is supported on the following platforms:
Windows 10 (x86 or x64)
(Enterprise Edition, Education Edition, or Professional Edition)
Windows Server 2012 R2
Windows 8 (x86 or x64) excluding Windows 8 RT
Windows Server 2012 (x64)
Windows Server 2008 R2 SP1 (x64)
Windows Server 2008 R2 (x64)
Windows 7 SP1 (x86 or x64)
Windows 7 (x86 or x64)
(Ultimate Edition, Enterprise Edition, or Professional Edition)
NOTE:The Novell Client for Windows is also supported in Remote Desktop Services and Desktop Virtualization environments.
The Novell Client for Windows might run but is not supported on Windows Starter, Home Basic, and Home Premium editions. On Windows Server platforms, the Novell Client for Windows might run but is not supported on Datacenter Edition, Web Server Edition, or on Server Core installations using any edition.
The Novell Client for Windows supports Novell Open Enterprise Server (OES) 2015, OES 11 SP2, OES 11 SP1, OES 11, OES 2, and NetWare 6.5.
To install the Novell Client 2 SP4 for Windows, run the setup.exe file located in the C:\Novell\Novell Client 2 SP4 for Windows directory.
The NMAS client installed with Novell Client for Windows includes NICI as a required dependency. Uninstalling the Novell Client automatically uninstalls the NMAS client, but intentionally does not uninstall NICI because other applications on the workstation besides NMAS or the Novell Client may still be using NICI services.
If you uninstall the Novell Client with the intention of installing a previous version of the Novell Client, it is recommended that you also uninstall NICI (and NICI for Windows x64, if running Windows x64) before re-installing the previous Novell Client for Windows release.
Attempting to install the initial an earlier Novell Client for Windows without first removing NICI can result in one or more of the following issues:
During installation of the Novell Client for Windows on Windows 7 x64, the NMAS Challenge/Response method will report a 1603 error. This is because the NMAS client included in the initial release cannot resolve its required dependencies using the newer version of NICI still present on the machine.
When starting up, the Windows welcome screen on Windows x64 displays an error, such as The procedure entry point CCSX_Authenticate could not be located in the dynamic link library ccswx64.dll.
The NICI installer of the older NICI version can damage the existing newer NICI installation. For example, attempting to install NICI 2.7.3 when NICI 2.7.4 is already present, or attempting to install NICI 2.7.4 when NICI 2.7.6 is already present. Subsequent attempts to use NICI can report -1471 0xFFFFFA41 NICI_E_SELF_VERIFICATION errors due to the damaged NICI installation.
The Novell Client 2 SP4 contains NICI 2.77.3, and the Novell Client 2 SP2 and earlier versions contain NICI 2.76. If you are intending to uninstall NICI 2.77 or later and re-install NICI 2.76, an additional step is necessary. The Novell NICI installer intentionally leaves behind certain NICI files, including CCSW32.DLL and CCSWX64.DLL. Due to an issue in the NICI 2.76 for Windows x64 installer, re-installing NICI 2.76 on Windows x64 is unable to overwrite the CCSWX64.DLL file left behind by the NICI 2.77 or later installers.
To uninstall a later version of NICI and re-install NICI 2.76 on Windows x64, in addition to uninstalling the NICI product, you will need to rename or delete the CCSWX64.DLL from the Windows SYSTEM32 directory.
IMPORTANT:If you omit this step, NICI 2.76 will still appear to install correctly, but attempting to login to Novell eDirectory using NMAS will fail with a NICI-specific NICI_E_SELF_VERIFICATION (-1471) error. When this issue happens, or before this issue happens, rename or delete the CCSWX64.DLL in the Windows SYSTEM32 directory and then run the Novell Client 2 SP2 or earlier installation again to re-install NICI 2.76 successfully.
If you fail to follow these guidelines, features that require NMAS will not function, due to one or all of the above conditions.
These guidelines and issues also apply to installing the Novell Client on a Windows Server 2012 machine where Novell eDirectory 8.8 SP5 or later has already been installed. Novell eDirectory on Windows Server 2008 includes NICI 2.7.6 or later, and installing previous versions of the Novell Client which include NICI 2.7.4 or earlier can cause the NICI installation to become damaged.
The path to any and all files within a Novell Client for Windows installation set must not exceed 256 characters.
Currently this means the directory path into which you extract the installation set must not exceed 214 characters. This limit is relative to the traditional MAX_PATH or 256-character limit in Windows applications, but also takes into account additional path space that is needed for running the installation.
If the installation set is being accessed from a remote network location, for example \\servername\volumename, the length of the network server and volume name also counts against the maximum depth, due to underlying processing that makes use of the real path to the installation set. Even if a mapped drive letter and/or the feature is used for accessing the installation set, the limit is measured as if a UNC path had been used.
If the Lazy Close feature is set to "ON", the 8.3 (short file name/DOS name) file name support will be unavailable for Novell Client. For example, a Dir /x command will display blank characters instead of the DOS/short file names and will display only the long names for the files in a mapped drive. Also, 16-bit applications will not be able to retrieve the 8.3 file names for the files.
"Login with Non-Novell Credential Provider" feature is currently not supported when a user tries to login using Microsoft Windows Live ID and Password. Novell plans to fix this in the future release of Novell Client. Also note that "Login with Non-Novell Credential Provider" feature works when PIN-based or Picture Based Login is enabled for the same Microsoft Windows Live ID.
The NetWare Administrator utility (nwadmn32.exe) and ConsoleOne are not supported on Windows or with the Novell Client for Windows, except where explicitly declared by the ConsoleOne release notes.
After installing Novell Client 2 SP4 on a machine which was previously using Novell Client 2 SP1 or earlier, during the next boot-up the “Username” field will come up blank rather than defaulting to the previous “last logged-on user” info. Once a new login has been performed using the Novell Client 2 SP4, future logouts and/or reboots will correctly show the last logged-on user info again. Note that the Novell Client login profile information (the eDirectory tree name, context, and so on.) has not been lost; only a one-time inability to display the last logged-on username.
This issue is not observed when you upgrade to Novell Client 2 SP4 from Novell Client 2 SP3 or SP2.
If you install the Novell Client for Windows on a machine with multiple local users, after rebooting, you are asked to log in to the Novell Client. At this point, there are only two available tiles: one for the local administrator user, and one for the Novell Client. You will no longer see the individual tiles for the local users.
This is working as designed. The Novell Client for Windows follows Microsoft’s recommendations to filter out the local user accounts after installing the Novell Client. If you install the workstation into a Microsoft Domain, the local user tiles are also filtered out, and the Novell Client follows this behavior.
When logging in to eDirectory via the Windows welcome screen, thebutton that is displayed is not active and therefore cannot be clicked.
When logging in to a Windows workstation using the Novell welcome screen, Novell connections made during the login will persist only if the Windows account you specify is not currently logged on to the workstation. If the Windows account specified is already logged in, Windows will reconnect you to that existing session when you log back in to the workstation, regardless of what eDirectory credentials might have been supplied, or whether they're the same as the eDirectory credentials already in use for that running session (if any).
This applies to both Fast User Switching and connecting via Remote Desktop Connection.
If you log in to a Novell server using a UNC path in Windows Explorer and specify more than just the server and volume, the Windows Explorer window will appear in the foreground and the Results page will appear in the background.
If you specify only the server and volume, authenticating with a UNC path works correctly.
If you are currently authenticated to eDirectory, after entering your old password and new password, you will see a Change Password dialog box after clicking thebutton. From the Change Password dialog box, you can choose which resources you want the password change to go to.
If you are not currently authenticated to eDirectory, the password change will only be performed for your Windows account.
When you detach from a mapped Novell drive, the mapped drive icon displayed in Windows Explorer changes to a red X to indicate that the mapped drive is no longer accessible. If you use the Red N icon to re-authenticate to the Novell tree (and you selected theoption when you originally mapped the drive), the mapped drive icon does not update to show that the drive is accessible again.
The LDAP Contextless Login feature in the Novell Client for Windows includes the following limitations for those familiar with the Novell Client 4.x for Windows XP/2003.
When invokingfrom the Novell welcome screen (the login dialog seen at boot time and when logging out of Windows Vista), the LDAP Contextless Login lookup cannot be triggered when viewing the tab. If LDAP Contextless Login is enabled, a lookup is performed after the user attempts to log in to eDirectory from the welcome screen.
This is different from the LDAP Contextless Login behavior when running LOGINW32.EXE or selecting the option from the Red N menu on the desktop. In those instances, you can see the effect of the LDAP Contextless Login lookup prior to actually proceeding with the eDirectory login.
The options to search eDirectory using information other than a complete username (for example partial usernames using wildcards, or alternate attributes such as phone number or e-mail address) have been disabled in the Novell Client for Windows. Only complete usernames can be used for LDAP Contextless Login.
Ifis chosen as an option in a login profile for Tree, Context, or Server, it cannot be removed by simply editing the field when logging in or by saving the profile on successful login. Any values entered in these fields during login will not be saved when is enabled for that field. This is working as designed.
If you set theoption (available on the Advanced Login tab in the Novell Client for Windows Properties dialog box) to (meaning that the drop-down list will not be displayed on the Novell Login dialog box), your next login will automatically use the last profile you logged in with.
If you want to use the default profile when theoption is turned off, make sure that you log in using the default before you turn the option off.
If you set theoption (available on the Advanced Login tab in the Novell Client for Windows Properties dialog box) to (it is Off by default), the Novell Login will require a password change on the next-to-last grace login instead of the last grace login.
To work around this issue, use one of the following options:
Avoid this setting. Users are prompted to change the password on every grace login, but on the last one they have the option of canceling out and potentially getting locked out if they log out one more time without changing the password.
Add one to the number of grace logins. The message will tell users that they have four, three, then two grace logins, and then they will be required to change the password.
Suggest that users change their password while they still have two or more grace logins.
The Novell Client for Windows ignores the SET CLIENT FILE CACHING ENABLED parameter on NetWare servers. Caching is on by default. Setting the parameter to on or off has no effect on the Novell Client behavior. This set parameter does still affect the NCP server’s behavior with regard to granting level 1 oplocks when requested.
To disable caching for a client, do the following:
Right-click the Red N in the System Tray.
Selectand set it to .
For information on File Caching, see “Advanced Settings” in the administration guide for the client.
Out Of Disk SpaceError
When a user or directory quota has been exceeded, the expected error condition will reflect only
out of disk space, in whatever manner the application chooses to report this error condition. The error status will not differentiate between
the disk is out of total physical space and
the current user or directory quota has been exceeded.
When logging in to both eDirectory and Windows through the credential provider of the Novell Client, the processing of login scripts stored in eDirectory now starts at the same time other login scripts are processed, such as the Windows user login script. This means that eDirectory login script execution will start (but not necessarily finish) before the user's Desktop is built.
In addition, existing Windows policies such as Run logon scripts synchronously now apply to how the Novell logon script execution will be handled. This appears to be the default behavior in Windows Server with Terminal Services, but the policy may need to be explicitly set in other Windows configurations.
If you require that logon script processing must finish before the user's desktop is built, you can enable this Windows policy in the Group Policy Editor (GPEDIT.MSC) under> > > > . Note the same policy is also available as a User Configuration policy.
In Windows 2000 SP4 and Windows XP SP1 and later, by default Windows will require that the roaming profile directory successfully pass a test for specific Windows-based permissions. This test fails against Novell paths since permissions are based on eDirectory permissions instead of Windows permissions, and can fail against Windows- or other non-Windows-based servers as well.
Windows defines a
Do not check for user ownership of Roaming Profile Folders policy
CompatibleRUPSecurity) to allow opting out of this security check where necessary. Enabling this policy is required to successfully store roaming profiles on a Novell server or other Windows or non-Windows server where the security check cannot succeed.
In the Novell Client for Windows XP/2003, installation of the Novell Client automatically enabled the
CompatibleRUPSecurity policy by default, regardless of whether it was known that user profiles were being saved to Novell paths. Administrators who did want to allow the new Microsoft security test to be performed had to override and disable the policy.
Installation of the Novell Client on Windows Vista and later does not enable the
CompatibleRUPSecurity policy by default. Administrators must enable this policy if they intend to store roaming profiles on Novell or non-Novell servers that will fail the Microsoft security check.
NOTE:In addition to being able to push this policy setting out with normal Novell ZENworks or Microsoft Group Policy methods, the Novell Client also provides a parameter UNATTEND.TXT.in . This parameter can be set during installation through use of a Novell Client Properties File (NCPF), for example
After running the Novell Client Installation Manager (NCIMAN.EXE) application on Windows 7, 8, 10, or Windows Server 2012, Windows may prompt with the Program Compatibility Assistant as though NCIMAN.EXE was an installation program that may not have completed successfully.
NCIMAN.EXE is not actually a program that attempts to install or uninstall any part of Novell Client software, and is just a tool for creating and editing Novell Client Property Files (NCPF), such as an UNATTEND.TXT file.
This warning can be ignored by simply selecting thelink offered by the Windows Program Compatibility Assistant.
As part of establishing a TSClientAutoAdminLogon policy, it is required to create a DefaultLoginProfile value to specify which Novell Client login profile should be used for the eDirectory portion of the login.
For Windows Server configurations where only a single Novell Client login profile exists anyway (for example, Default), there is no issue and the single profile will be successfully used. But it has been observed that when more than one login profile is defined, it is possible for the TSClientAutoAdminLogon attempt to use the last-used Novell Client login profile for a user instead of the login profile explicitly specified in the DefaultLoginProfile configuration.
This represents an unintentional behavior, and is being examined for future versions of the Novell Client. The workaround if this issue is encountered is to define and use just a single Novell Client login profile, at least on Windows Server machines on which Terminal Services and TSClientAutoAdminLogon are expected to be used.
If a file copy operation is in progress with many and/or large files and the user attempts to either clear their eDirectory connections or change whom they are logged into eDirectory as while the file copy operation is still in progress, it has been observed that instead of the expected file access failure it is possible for the workstation to report a
blue screen or kernel-mode bugcheck.
This issue is being examined for future versions of the Novell Client. The workaround is to recommend that users not attempt to clear their existing eDirectory login or NCP connections out from under a file copy operation that is in progress.
Running PUTTY.EXE from a Novell path can sometimes cause the workstation to become non-responsive. Analysis has shown that the Novell NCP server appears to become non-responsive to the workstation right at the time SSH-specific communication is attempted by PUTTY.EXE.
This issue is being examined for future versions of the Novell Client and/or the Novell NCP servers.
In cases where the Novell Client credential provider used by the Windows welcome screen login is switched between
Computer Only Logon mode and
Novell Logon mode prior to performing a Novell Logon login attempt, the Windows account name used during the login attempt might be whatever Windows account name was specified in the field while the credential provider was in Computer Only Logon mode, instead of the correct Windows account name saved and retrieved from the tab of the effective Novell Client login profile.
This represents an unintentional behavior, and is being examined for future versions of the Novell Client. The workaround is to avoid the switch between Computer Only Logon mode and Novell Logon mode when possible. And when the issue does occur, provide the correct Windows account credentials in the Windows logon fields that appear after the attempt to use the incorrect Windows account name.
The Novell iPrint 5.32 and iPrint 5.30 clients contain an issue in which incorrect security is established on the [HKEY_LOCAL_MACHINE\Software\Novell] registry key, if and when the Novell iPrint client was the first installed software that needed to create this registry key. This registry security issue is addressed in the Novell iPrint 5.35 client and later.
If the Novell iPrint 5.32 or iPrint 5.30 client is installed prior to the Novell Client 2 SP4 for Windows, the security that is established on the [HKEY_LOCAL_MACHINE\Software\Novell] registry key causes incorrect security to be propagated to the Novell Client's own registry sub-keys. In addition, the incorrect registry security can cause the Novell NMAS Challenge Response Method installation to fail with Error 1603, due to incorrect registry security which was propagated to the Novell NMAS Client's registry sub-keys.
The Novell Client 2 SP1 (IR1) contained some mitigation for this issue that could clean-up the incorrect registry security established by Novell iPrint and proceed with a successful Novell Client installation if the Novell Client 2 SP4 or earlier Novell Client installation had not already been attempted and failed after installing the Novell iPrint client. If a failed Novell Client installation had already been attempted after installing the Novell iPrint client first, the Novell Client 2 SP1 (IR1) installation will still fail due to the improper registry security which has already been established.
The Novell Client 2 SP1 (IR2) contains further mitigation which will actually clean up the registry security issue created by the Novell iPrint client, and furthermore will clean up the incorrect security which may have already been propagated to the Novell Client registry sub-keys and the Novell NMAS Client sub-keys. So on a machine where the Novell iPrint 5.32 or iPrint 5.30 client was installed prior to the Novell Client for Windows, but a Novell Client for Windows installation has already subsequently failed, the primary corrective action to perform is to install Novell Client 2 SP1 (IR2) on top of the previously failed Novell Client for Windows installation.
There is however one scenario under which even the Novell Client 2 SP1 (IR2) fix will be unable to detect and clean-up registry security problems which still exist due to the Novell iPrint client installation. This problem scenario occurs specifically when all of the following conditions are met:
Novell iPrint 5.32 or iPrint 5.32 was installed before the first Novell Client installation.
Novell Client 2 SP1 or earlier was installed without NMAS, and with or without NICI.
Same machine was then upgraded to Novell Client 2 SP1 (IR1); installed with or without NMAS, and with or without NICI.
Same machine was then upgraded to Novell Client 2 SP1 (IR2); installed with or without NMAS, and with or without NICI.
In this specific sequence where the initial failed Novell Client installation was performed after explicitly deselecting Novell NMAS from being installed with the Novell Client, the subsequent mitigations for the Novell iPrint security issue performed by the Novell Client 2 SP1 (IR1) and Novell Client 2 SP1 (IR2) installations are unable to detect or correct that further clean-up of the Novell iPrint registry security permissions is still necessary.
The symptoms that occur when a machine is still in this broken state include a crash that occurs whenever the Novell Client login dialog would have been presented. For example, when attempting to invoke the “Show Advanced Options” link on the Windows welcome screen, the Windows LogonUI.exe process can crash. When trying to invoke “Novell Login” from the red 'N' menu in the Windows taskbar notification area (systray), the Novell NWTRAY.EXE process can crash.
Unfortunately the incorrect permissions established on the registry by Novell iPrint client will also prevent successful un-installation from being performed after the machine is already in this state. This remaining scenario where the Novell iPrint registry permissions are not successfully cleaned up is being examined for additional mitigation in future versions of the Novell Client.
Establishing an eDirectory AutoAdminLogon configuration requires that a Windows AutoAdminLogon configuration is also established. Meaning at minimum an automatic Windows account logon will occur if only a Windows AutoAdminLogon is configured; or both an eDirectory account logon and a Windows account logon will occur if both eDirectory AutoAdminLogon and Windows AutoAdminLogon are configured. Any workstation where only an eDirectory AutoAdminLogon is configured will now have the AutoAdminLogon configuration ignored, instead of experiencing undefined results.
For more information on configuring a Windows AutoAdminLogon policy or both an eDirectory AutoAdminLogon and Windows AutoAdminLogon policy, see Section Novell Client 2 SP4 for Windows Administration Guide.
The Novell Client 802.1x Authentication integration does not succeed when Microsoft Server 2008 R2- based RADIUS service is being used for 802.1x authentication.
For more information, see TID 7007679 or bug 631640.
With the Novell Client installed in Windows 8, if you enter the “Show Advanced Options" dialog, or if you proceed with a login attempt when the login profile is not yet populated such that Novell Client forces you to see and populate the "Show Advanced Options" link, delaying any further input at this point will cause the Windows lock screen to be displayed behind the "Show Advanced Options" dialog.
In some cases the lock screen will display after 60 seconds and then dismiss itself after another 60 seconds. This will happen in a continuous sequence without any user intervention. Novell plans to fix this issue in a future Novell Client for Windows release.
If Novell Client 2 SP4 for Windows (IR1) does not work on Windows 10, ensure that you have latest Windows 10.
If you install the Novell Client 2 SP4 for Windows (IR1) on Windows 7 or 8.1 and then upgrade the Windows to latest Windows 10, the already installed Novell Client 2 SP4 for Windows (IR1) might not work properly. To avoid this issue, ensure that the Novell Client 2 SP4 for Windows (IR1) is newly installed on Windows 10.
This issue is being examined and will be fixed for future versions of the Novell Client.
Relative distinguished name paths are not supported for mapping network drives. For example \\tree\server_volume.context. (note the trailing period) is not supported whereas \\tree\server_volume.context (no trailing period) is.
Possible crash during rename if the target file is opened while rename is in progress. (Bug: 934729)
Possible deadlock when NCP oplock break request is received while file is being closed. (Bug: 932390)
Unable to upgrade from SP3 IR10 to IR10a, IR10b or SP4 using NCP-based UNC path when Windows UAC is turned off. (Bug: 929707)
Crash in NWTRAY.EXE when attempting to change the password for a connected Windows share resource. (Bug: 926471)
Novell Client can fail to respond to an NCP oplock break request after specific sequence of operations. (Bug: 924017)
The NCP-level DENY_WRITE permission can be omitted if the Windows-level FILE_SHARE_DELETE was requested. (Bug: 923541)
eDirectory intruder lockout can occur after changing password when MS15-011 / KB3000483 is applied. (Bug: 920558)
Opening of mapped drives and UNC paths delayed after applying MS15-011 / KB3000483. (Bug: 919801)
Support OES 2015 feature of NCP 87,72 and NCP 87,73 supporting reads and writes larger than 64KB for increased performance. (Bug: 919150)
When FILE_NO_INTERMEDIATE_BUFFERING is requested, NCP oplock can be requested even though it is already acquired. (Bug: 918008)
When an application truncates a currently-cached file, the previously-cached memory was not being released. (Bug: 917965)
Added "unsupported operating system" agreement page to display when installing future versions of Windows. (Bug: 914854)
Drive mappings or directories could show errors or display as empty, over time or with very busy NCP servers. (Bug: 913226)
Failed NCP rename attempt may be reported back to Windows as though rename was successful. (Bug: 912437)
Novell Client LDAP Contextless Login dialogs or prompts may appear behind Novell or Windows login. (Bug: 912127)
Performance loss because Novell Client may give up a Level 2 oplock in attempt to acquire Level 1, but ends up without any oplock. (Bug: 911548)
FILE_SHARE permissions could be incorrectly tracked when multiple instances of the same file are opened. (Bug: 911542)
FILE_SHARE permissions could be incorrectly tracked when FILE_READ_ATTRIBUTES was the only desired access requested. (Bug: 911540)
Possible kernel-mode crashes in multiple drivers due to object manager not accurately returning indication of new object creation. (Bug: 910518)
Possible kernel-mode crash in NCCACHE.SYS when closing one of multiple handles open to the same file. (Bug: 910152)
Update LDAP Contextless Login LDAPSSL library to use TLS and disable SSLv3 (POODLE; CVE-2014-3566). (Bug: 909416)
Possible kernel-mode crashes in multiple drivers due to object manager not maintaining exclusive access as intended. (Bugs: 908929,903450)
Windows installation of MSI package fails from NCP-based UNC path, but succeeds from NCP-based drive mapping. (Bug: 908842)
Possible kernel-mode crash in Windows Offline Files (CSC.SYS) driver during failed open of NCP-based file. (Bug: 908697)
Addition of "Unlock Workstation Credentials" setting in the Novell Client Properties. (Bug: 908106)
Path accessible by both CIFS and NCP may fail when "UNC Path Filter" is enabled. (Bug: 908052)
Password confirmation message for updating NMAS Challenge/Response questions was confusing in all languages. (Bug: 906933)
Unnecessary additional prompt could occur when changing expired eDirectory password. (Bug: 906172)
Possible deadlock during file rename if another process is trying to open the same file. (Bug: 904443)
Possible crash in XTSVCMGR.EXE due to thread creation & termination race condition. (Bug: 903541)
Addition of "Bad Address Cache Enabled" setting in the Novell Client Properties. (Bug: 902427)
Kernel-mode software examining Windows FSRTL_ADVANCED_FCB_HEADER file sizes could see stale values for NCP-based files. (Bug: 896868)
Parent folder allowed to be renamed while file is open, which prevents the file from being successfully saved. (Bug: 895060)
Updated BadNameCacheList functionality to support both "whitelist" and "blacklist" usage. (Bug: 888382)
Implemented Novell Client "Lazy Close" feature for increased performance when caching is enabled. (Bug: 885911)
Support OES 2015 feature of NCP 89,20 supporting directory enumeration responses up to 64KB for increased performance. (Bug: 881313)
Improved rejection and handling when entering invalid username such as "." or "=" which are also eDirectory delimiters. (Bug: 879496)
Added "Windows 8.1" and "Windows Server 2012 R2" as Novell Client product names that will be displayed. (Bug: 832584)
Hovering mouse over Windows credential provider "Submit" button would show "No Label" on Windows 8 and later. (Bug: 792001)
Added "Make Script tab read-only during login" in Novell Client Properties, to disable Script tab while still running scripts. (Bug: 677441)
Support OES 2015 feature for multiple NCPs to support NCP volumes and restrictions of 16TB or more. (Bug: 516101)
Deleting a file may report success but not actually be deleted, if file is sill open on another NCP connection. (Bug: 477793)
First release of Novell Client 2 SP4 for Windows.
For information on installing, using, and administering the Novell Client for Windows, see http://www.novell.com/documentation/windows_client/index.html.
For information on Login Scripts, see the Novell Login Scripts Guide.
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 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 © 2008-2015 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 Novell trademarks, see the Novell Trademark and Service Mark list.
All third-party trademarks are the property of their respective owners.
"OpenSLP" is copyrighted to Caldera systems. Novell ships a modified version of OpenSLP for the Novell Client for Windows. Novell supports the modified OpenSLP software shipped with the Novell Client for Windows.
Copyright © 2000 Caldera Systems, IncAll rights reserved.Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Caldera Systems nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE CALDERA SYSTEMS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.