Novell Client interactions with MUP and MPR

How does an application know which network provider it should use?
How does changing the network provider order impact performance?
How does an application know which network file system driver it should use?

Network Provider

Network clients (including the Novell Client for Windows) designed for Windows provide a network provider DLL, which is registered such that Windows' Multiple Provider Router (MPR) knows how to call it.  Any time an application invokes a WNet API (e.g. WNetAddConnection), MPR calls each of the installed network providers in turn, according to the configured Windows "Network Provider Order", until one of them reports successfully handling the operation for the path specified.  MPR stops as soon as the current network provider successfully handles the call, and doesn't call any of the remaining providers.

Network Redirector

Network clients (including the Novell Client for Windows) designed for Windows also provide a network file system driver (redirector), which is registered such that Windows' Multiple UNC Provider (MUP) knows how to call it.  Any time a Windows file system API (e.g. CreateFile) is invoked with a network path, Windows sends this path to Windows' MUP driver.  MUP in turn calls each of the registered network redirectors (in parallel and/or with slightly varying algorithms, depending upon the version of Windows involved) to determine which redirector reports successfully handling more of the path.  (e.g. In response to \server\volume\path, multiple redirectors might claim to successfully handle the \server portion, but only one or more redirectors might claim to successfully handle the entire \server\volume\path.)
 
The operation is not a strictly serialized "call the first one and if it fails, call the next one" like it is for MPR.  For MUP, multiple redirectors will be queried even if "the first one" already responded with success, and MUP will make its final decision based upon the responses it received from multiple redirectors.  The Windows "Network Provider Order" (see TID 7000693) is used to help break "ties" in the MUP decision process, and depending on the version of Windows, can also be used to optimize "how much longer will we wait for other redirectors to respond" if a preferred redirector according to the "Network Provider Order" has already reported successfully handing the complete path.
 

In both cases -- the Windows MPR interacting with third-party WNet provider, and for Windows MUP interacting with third-party redirectors -- Windows calls the registered network clients at a time of Windows' choosing.  It is not up to the Novell Client or any third-party network client to somehow wrestle control away from Windows.  The MUP and MPR frameworks are specifically intended for arbitrating between multiple installed network clients, both Microsoft-provided and non-Microsoft-provided.

On Windows 6.x, the Novell Client is attempting to connect to the server because either a Windows MPR/WNet API has been called (WNetAddConnection, etc.), or because a Windows file system API / MUP has been called (CreateFile, etc.) with that server name specified.
 
An application would not know what network provider needs to be used (nor does MUP provide that granularity for file system-level API calls anyway).  It's exactly the intention of both MPR and MUP to use each of the installed Windows network providers and determine which of them can access the path specified.  That's what MUP and MPR are abstracting the application from needing to know; the application simply has to invoke the Windows WNet or file system API, and MPR or MUP takes care of determining which of the installed network providers can best get the job done on any given machine the application is running on.

A more technical description can be found in the Microsoft Hardware Development Center article "Support for UNC Naming and MUP."