Poor performance accessing Microsoft Office documents on a Novell server.

Poor performance accessing Microsoft Office documents on a Novell server.
Long delays saving a Microsoft Word document to a Novell server.
Long delays opening a Microsoft Word document on a Novell server.
Long delays saving a Microsoft Access database to a Novell server.
Long delays opening a Microsoft Access database on a Novell server.
Long delays saving a Microsoft Excel spreadsheet to a Novell server.
Long delays opening a Microsoft Excel spreadsheet on a Novell server.
Long delays saving a Microsoft Powerpoint presentation to a Novell server.
Long delays opening a Microsoft Powerpoint presentation on a Novell server.
Long delays saving a Microsoft Office document to a Novell server.
Long delays opening a Microsoft Office document on a Novell server.
Long delays when selecting to create a new e-mail message
Microsoft Word hangs when starting.
Microsoft Excel hangs when starting.
Microsoft Powerpoint hangs when starting.
Microsoft Office application hangs when starting.

There are a number of known issues regarding accessing Microsoft Office documents located on Novell servers.This solution will attempt to document all of the known issues. We will attempt to update this solution as we learn more about the problems and solutions. Most of the information gathered is based upon analysis of numerous packet traces from multiple Novell customers.

Problem 1:
This problem is related to the way that Windows Explorer works on these OS's. When Explorer is opened to browse a directory, it looks for the file desktop.ini. When you are across a slow link - Dialup, etc., these attempts to resolve this file can add up to 20-30 seconds for each file activity. The reason Explorer looks for this file is to determine how to display the directory information. For example, the type of icon for a particular type of file. When you open up an Office document, the Office application calls Explorer to locate the file. During this process it scans every drive mapping attempting to locate this file. It will also scan any NT servers as well. This process adds significant delays to any file operations.

Solution 1:
There is currently no resolution to this problem. Microsoft would have to instruct customers how to disable this feature of the OS. Novell's current recommendation is to limit drive mappings so that the delay will be minimal.

Problem 2:
When a request to open a file on the NetWare server is issued, the Client for Microsoft networks appears to take control and attempts to talk to the server as if it were a Microsoft server. This eventually fails and control is passed to the Novell client for Windows NT/2000 which succeeds - operation then continues normally.

Packet traces show the workstation performing a DNS lookup for the NetWare server name, then a WINs lookup, and then a Netbios broadcast. DNS returns the NetWare servers IP address, WINS does not, neither does the broadcast. Most of the delay appears to be while the workstation waits for the timeout period for the broadcast to expire. If the IP address of the server is found through any mechanism, then the workstation attempts to connect to the NetWare server using Microsoft protocols (Netbios/SMB). After attempting the connection two or three times, this fails, and then uses the Novell Client, and the process continues normally.

The server/volume attempting to be accessed has a mapped drive on the client.

Solution 2:
This issue is addressed in the Novell Client 4.91 for Windows XP/2003 and later.  The correct value to appear in the Windows "ProviderOrder" list is in fact "NetwareWorkstation".  And the correct value for the Novell Client's "DeviceName" value is in fact "\Device\NetWareRedirector".  These are exactly the values that will already be present in these configurations when installing Novell Client 4.91 for Windows XP/2003 or later.
 
Note: Previous to 4Aug2009, this TID suggested two workarounds and a solution of making a Registry key change, per Microsoft article KB Q171386.

The Microsoft KB 171386 article originally described a valid issue in the IntraNetWare Client 4.6 time frame, in which the Novell Client's "DeviceName" value was being incorrectly set to "\Device\NetWareWorkstation" instead of "\Device\NetWareRedirector".  The description in KB 171386 at that time correctly described updating the "DeviceName" value to reflect the actual Novell Client redirector device object, "\Device\NetWareRedirector".
 
This disparity was addressed in post-4.83 and post-4.90 Novell Client updates, and no longer exists as an issue in Novell Client 4.91 for Windows XP/2003 and later.
 
Sometime prior to September 2003, and still as of July 2009, the KB 171386 description was updated, in Novell's assessment, to INCORRECTLY describe how to address the issue.  The KB 171386 description now asserts that the value cited in the Windows "ProviderOrder" list needs to be the same as the "DeviceName" value.
 
This is not correct, and is not true even for Microsoft's own Microsoft Client for Microsoft Networks.  Which uses "LanmanWorkstation" (the name of the service entry) within the "ProviderOrder" list, but has "\Device\LanmanRedirector" as the "DeviceName" of its redirector device object.  Which Novell agrees is the correct configuration that Windows requires; but this disagrees with the description now present in KB 171368.
 
Novell's assertion is that the KB 171368 description is no longer correct for any Novell Client version.  And regardless, was originally intended to describe an issue which no longer exists in the Novell Client 4.91 for Windows XP/2003 and later.
 
The correct Novell Client reference within the Windows "ProviderOrder" value is "NetwareWorkstation".  And the correct Novell Client "DeviceName" value is "\Device\NetWareRedirector".  And these are exactly the values already being established with installation of the Novell Client 4.91 for Windows XP/2003 and later, and do not require modification.

Problem 3:
When Microsoft Office documents are created then templates are associated and stored within the Office document. When these files are then transferred across to different systems then the original template location (network resource) cannot be located. This causes a delay as the application attempts to locate the resource.

Solution 3:
This problem can be resolved with modifications to the application. Please see TID10024669.

Problem 4:
Most virus protection schemes incorporate the scanning of office documents for Macro virus's. Virus scanning software can be located at either the server, the client, or both. If the application is configured to scan the documents during open or close then the end user will see a delay during this process.

Solution 4:
It is recommended that virus protection be disabled as a test to see if the delay is eliminated. If it is determined that the virus protection software is causing the delays, consult the virus protection vendor for proper configuration information.

Problem 5:
When launching Microsoft Office applications all installed printers are contacted. This same symptom was reported to occur with other Windows based applications. In most cases not all printers were being resolved but only the default printer. Set the default printer to a local printer to see if this condition can be elliminated. This condition can cause delays if the printers cannot be located. This is extremely noticeable when attempting to launch Microsoft Office applications from an undocked laptop computer. If the computer is not connected to the network and the application is started, each defined printer will cause delays as the application attempts to resolve the resource. Even while the computer is connected to the network if printers are installed on the computer that no longer exist, the application will pause while the application attempts to resolve the printers. The application appears to be in a hung state but after several minutes, it will start responding again. By deleting the printers then the application no longer hangs when starting.

Solution 5:
Novell engineering has made some changes in the Novell client to validate whether the network connection is either up or down. This will not eliminate the problem if the printer is no longer available or the computer is connected to a different network where the printers cannot be resolved. Also, the solution for the network connection being validated correctly is currently being investigated by Novell engineering due to some random customer reports. There potentially is some hardware that falsely indicates network availability through our detection process. The current solution is included in support pack 3 for the Novell client for Windows NT/2000. Hardware not working with this solution should be reported to Novell Technical Support.

Problem 6:
The final issue is related to the way that the Novell client for Windows NT/2000 is designed. The Client originally did not incorporate a bad name cache for network resources. As a result, every time a network resource was requested, the client would always search for the network resource. An optimal configuration would implement a bad name cache so that each time a resource is requested, the client would check the bad name cache to see if the resource was valid. This feature is included in the current Novell client for Windows 95/98 but not in the Novell client for Windows NT/2000.

Solution 6:
Beginning with the NWFS.SYS dated 2Jan2002, the Novell Client for Windows NT/2000/XP corrects performance problems caused by delays in attempting to locate non-findable resources. This is accomplished by adding a bad server name cache. This functionality is controlled via "Bad Server Name Cache Enabled" and "Bad Server Name Cache Timeout" which are settable from the Advanced Settings tab of the Novell Client Configuration properties page (via the red "N" system tray icon).

The corresponding registry entries are:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetwareWorkstation\Parameters]
"Bad Name Cache Enabled"=dword:00000001
"Bad Name Cache Timeout"=dword:0000012c

"Bad Name Cache Enabled" can have a value of 0 or 1.  0 is off and 1 is on.

"Bad Name Cache Timeout" is how long the name will stay in the cache.  This value is in seconds and the default is 300 seconds (5 minutes). Enter this value as the number of seconds, in hexadecimal.

The NWFS.SYS cache is able to remember bad names even if they appear to be valid UNCs (ie \\.\Display3).

Note that there will be a delay the first time the Client tries to locate a resource, but subsequent tries will be fast, thanks to the bad name cache. To eliminate the initial delay, it is also possible to pre-populate the bad server name cache. This is done by editing the registry (no user interface is currently available)

The name of the registry value is "BadServer" which is a multiple string value.  Server names added to this value will never timeout.  For example, if you have a NT4 server that you connect to, you can put its name in the "BadServer" value and the Novell Client will never try to resolve that name.

How to add server named to the BadServer value:

WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them.

1. Run Registry Editor (REGEDT32.EXE).

2. From the HKEY_LOCAL_MACHINE subtree, go to the following key:

      \SYSTEM\CurrentControlSet\Services\NetwareWorkstation\Parameters]
    
3. From the Edit menu, select Add Value.

4. Add the following (using Server1, Server2, and Server3 as examples):

      Value Name: BadServer
      Data Type:  REG_MULTI_SZ
      Data:       Server1<CR>Server2<CR>Server3

NOTE: <CR> Indicates you should hit Enter on the keyboard

5. Choose OK and quit Registry Editor.

6. Shut down and restart Windows NT.

Formerly known as TID# 10065560

Edited entire document, and changed solution to Problem 2. See Internal notes for previous entry.