1.2 How the Novell Client 2 SP3 for Windows Differs from the Novell Client for Windows XP/2003

Using the Novell Client 2 SP3 for Windows differs in a few ways from using the Novell Client for Windows XP/2003. For users and network administrators who are familiar with the Novell Client for Windows XP/2003, knowing these differences can help the transition to Windows 8 and Windows 7 run more smoothly.

1.2.1 Novell Client for Windows XP/2003 Features Not Included in the Novell Client for Windows

The following Novell Client for Windows XP/2003 features are not included in the Novell Client for Windows:

  • Compatibility with any version of Windows other than Windows 8, Windows 7, Windows Server 2012 or Windows Server 2008 R2.

    The Novell Client 4.91 for Windows continues to support Windows XP and 2003.

  • Compatibility to NetWare 5.0 and all prior versions.

  • Novell Graphical Login at Windows boot.

    There is no direct concept of this in Windows 8 and Windows 7, because the Graphical Identification and Authentication (GINA) credential input extension model was replaced by the credential provider model. For more information, see Create Custom Login Experiences With Credential Providers For Windows Vista and Section 3.0, Authenticating to a Novell Network.

  • Queue-based or NDPS printing support.

    Printing support is provided by iPrint

  • 16-bit applications and libraries.

  • Compatibility Mode Driver (CMD).

  • NetWare IP (NWIP).

  • IPX/SPX protocols and API libraries.

  • Catalog Services version of contextless login.

  • NetIdentity Client.

  • Bindery-mode authentication.

  • UNC path handling (NWFilter).

1.2.2 Service Location Protocol (SLP) Differences

Both the Novell Client 2 SP3 for Windows and the Novell Client for Linux use the OpenSLP User Agent (UA) for performing Service Location Protocol (SLP) based name resolution. OpenSLP is an open source effort to maintain a standards-compliant SLP User Agent (UA) and Directory Agent (DA) implementation. More information on OpenSLP can be found at http://openslp.org.

For Novell Client 4.91 for Windows XP/2003 users, there are noticeable differences between how the Novell Client 4.x SRVLOC SLP User Agent (UA) operates and how the OpenSLP LIBSLP UA operates. This section describe some of the significant known differences between the two SLP User Agents.

Novell Client 4.x SRVLOC User Agent

By default, the following behaviors occur with the Novell Client 4.x for Windows XP/2003 SRVLOC User Agent (UA):

  • The SRVLOC UA initiates discovery of new SLP Directory Agents (DAs) as soon as Windows provides notification that a new TCPIP network interface was created (that is, as soon as each network interface indicates it is physically connected and also has an IP address assigned to it). SRVLOC initiates a DHCP Inform request for SLP configuration information and/or a multicast query for SLP DAs at that time, as appropriate, and saves the SLP DA information learned from each interface.

    Any SLP DAs that were manually configured on the workstation are considered global, and apply to all interfaces. Any SLP DAs that are learned through DHCP or by multicast are associated with the specific interface over which they were learned. When a network interface becomes disconnected, the SLP DA information associated with that interface is also removed.

  • When the Novell Client issues a name resolution request through SRVLOC, all SLP scopes that the SRVLOC UA has been configured with or learned from DAs are used when making the request. For example, if a Novell Client 4.x machine knows of scopes “CORPORATE” and “PARTNER,” a name resolution request is made for both “CORPORATE” and “PARTNER” on any DAs that declared that they support these scopes.

  • If the SRVLOC UA was configured to support both SLP v2 and SLP v1 and the SLP v2 DAs did not return answers for a query, or the DAs did not support the scopes being queried, the SRVLOC UA issues an unscoped SLP v1 query to any SLP v1 DAs or by multicast to determine whether the service was registered in the SLP v1 unscoped scope.

  • The SRVLOC UA supports diagnostic and status information that can be queried programmatically. The SLPINFO.EXE tool queries and presents this information to aid in confirming and troubleshooting SLP configurations.

  • When unicasting directly to an SLP DA, the SRVLOC UA uses UDP datagram communication unless the answer being returned by the DA cannot fit within a UDP datagram. In such an event, a TCP connection to the SLP DA is created long enough to obtain the large result.

  • To work around the issue described in Novell Client is unable to communicate with OpenSLP Directory Agent over SLPv2, the SRVLOC UA allows setting a “Use SingleEquals in Where (V2)” policy to cause a single equals character to be used in predicate strings.

  • DHCP-based SLP configuration information is retrieved by the SRVLOC UA through the Novell Client NWDHCP.SYS driver. DHCP-based SLP configuration can be successfully retrieved even when the Windows network adapter is not using DHCP for its IPv4 address configuration, and instead has a static IPv4 address assignment.

Novell Client 2 SP3 for Windows OpenSLP LIBSLP User Agent

By default, the following behaviors occur with the OpenSLP LIBSLP User Agent (UA) used in the Novell Client 2 SP3 for Windows:

  • The OpenSLP UA does not perform “preemptive discovery” of SLP Directory Agents (DAs). Instead, the OpenSLP UA waits until there is an actual name resolution request to perform, at which point SLP DA discovery by DHCP and multicast can occur. Both DHCP Inform discovery of SLP configuration information and muticast-based discovery of DAs and services occur over all active interfaces.

  • The OpenSLP discovery process attempts SLP scope and DA discovery in a specific order: first, by manually configured DA and scope information; second, by DHCP-supplied DA and scope information; and finally, by DA and scope information learned from multicast. This order is important because the OpenSLP DA discovery process stops as soon as one or more DAs are successfully found.

  • During the DA discovery process, the OpenSLP UA intends to find and use just one DA. The OpenSLP UA looks for a DA that supports any one of the scopes the OpenSLP UA is currently configured to use. For example, if the OpenSLP UA currently knows of scopes “CORPORATE” and “PARTNER,” OpenSLP looks for any DA that supports “CORPORATE” or any DA that supports “PARTNER.”

    Whichever DA the OpenSLP UA finds first is the only DA (and therefore the only scope) that the OpenSLP UA uses to obtain answers from. The OpenSLP UA does not query both the DAs serving “CORPORATE” and the DAs serving “PARTNER.” The UA queries only one or the other.

    While the OpenSLP UA supports configuration with multiple scopes and DAs, the OpenSLP UA only expects to find or use one of those scopes (and therefore, only those DAs supporting that scope) within a given network environment.

    There is some merit in manually configuring an OpenSLP UA workstation with a list of more than one scope and more than one DA if the workstation physically moves between networks that require one scope versus the other. DHCP-delivered SLP configuration information can achieve the same goal by delivering only the scope name and DA address information appropriate for the network environment that the DHCP server serves.

  • The OpenSLP UA is designed for SLP v2 operation only.

  • Neither the OpenSLP UA nor the manner in which the Novell Client 2 SP3 for Windows employs it currently supports the level of diagnostic information that SLPINFO.EXE provided. The OpenSLP project supports logging in general, but currently only supports logging in the OpenSLP DA, not the OpenSLP UA.

    As such, capturing a network traffic LAN trace of a workstation's SLP interaction is usually the most effective tool for troubleshooting SLP-related actions on a Novell Client for Windows workstation or Windows 2008 server.

  • When unicasting directly to an SLP DA, the OpenSLP UA always uses TCP connections to the SLP DA. UDP is still used for multicast and broadcast discovery and queries, but DA connections are TCP-only.

  • The OpenSLP UA (or more specifically, the SLPNSP name service provider used by the Novell Client 2 SP3 for Windows and the Novell Client for Linux) does not yet provide a solution for the issue of using a single equals character in a predicate string.

  • DHCP-based SLP configuration information is retrieved by the OpenSLP UA through the Microsoft DHCP Client Service included with the Windows operating system. The Microsoft DHCP Client Service only supports retrieving DHCP-based configuration information when the Windows network adapter itself is configured to acquire IPv4 address information via DHCP. If the Windows network adapter is configured with a static IPv4 address, the SLP DA and/or SLP scope list will need to be manually configured on the machine, as the it will not retrieve SLP configuration information via DHCP. Or the machine will need to successfully learn SLP DA and scopes via multicast every time the machine boots. For more information, see Novell Client 2 does not retrieve SLP information when using static IPv4 address.

1.2.3 LDAP Contextless Login Differences

The LDAP Contextless Login feature in the Novell Client 2 SP3 for Windows includes the following limitations for those familiar with the Novell Client 4.x for Windows XP/2003.

  • The options to search by attributes other than username (for example, phone number or e-mail address) have been disabled for the Novell Client 2 SP3 for Windows release.