IBM Support

Windows 7 and IBM i NetServer

Technote (troubleshooting)


Problem(Abstract)

This document contains tips and recommendations related to all of the differences IBM i Support has seen when using Windows 7 to connect to the IBM i NetServer, rather than using a previous Windows version.

Resolving the problem

This document contains tips and recommendations related to all of the differences IBM i Support has seen when using Windows 7 to connect to the IBM i NetServer, rather than using a previous Windows version.

Caution: This document discusses making changes to the Windows registry with the registry editor, regedit. Before using this tool to make any changes to your registry, back the registry up, and make certain you understand how to restore it if a problem occurs. Consult Microsoft's knowledge base and help system for information on using regedit, regedt32 registry editor programs. IBM does not provide support for making changes to Microsoft's PC registry. If you have any questions on making registry changes, contact Microsoft.

Mixed Case Passwords

When mapping a NetServer drive from a PC running Windows 7, the Windows password entered as mixed case will only work if the IBM i QPWDLVL system value is changed to 2 and the NetServer users' passwords are changed to set the new hash value. See section on LanMan Authentication below:

Caution: Before making any changes to the QPWDLVL system value, refer to the IBM i Knowledge Center section documentation on Considerations for changing QPWDLVL from 0 or 1 to 2 . To link to this section of the 720 Knowledge Center now, go to:

http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzarl/rzarlconsdchg2.htm

Note: Information applies to all supported OS/400 versions.

LanMan Authentication

Windows 7 changed its default client security policy to use NTLMv2 authentication and has completely disabled the use of LANMANv1 (LM) password encryption. As a result, a case-insensitive password can not be sent from Windows 7. This can make connecting to NetServer more difficult; however, it is a good idea because LanMan password encryption can be easily deciphered using any number of easily obtainable programs.

For NetServer users, this means that a Windows 7 PC can not ever use a mixed case password to map a drive to an IBM i that has the QPWDLVL System Value set to 0. All passwords used to map NetServer drives must be entered in single case (all uppercase or all lowercase) if the IBM i is using QPWDLVL 0.

Changing the security policy ( Network security: LAN Manager authentication level) on the Windows 7 machine to Send LM & NTLM responses followed by a restart of the PC will allow users to map drives without a domain name being specified. This makes a difference when using the NET USE command. If a domain name is not specified and NTLMv2 is being used, the credentials will be rejected. However, with NTLM enabled, the credentials will be accepted without the domain name being included. The password will still have to be typed in lower case if the i is running at QPWDLVL 0 or 1.

You should take the following steps to set the security policy ( Network security: LAN Manager authentication level) on the Windows 7 machine to Send LM & NTLM responses:

1. Click on the Start button.
2. Type SECPOL.MSC in the search window.
3. Press Enter.

This will start the security policy editor in the Microsoft Management Console (MMC). See Note 5, below, before making this change.

4. In the security policy editor, select Local Policies.
5. Select Security Options on the left side.
6. Scroll down to and double-click Network security: LAN Manager authentication level.
7. On the Local Security Setting tab, drop the list of options down and select Send LM & NTLM - use NTLMv2 session security if negotiated.

A stop and restart of the PC is required after making this security change, in order for the change to take effect.

Note: NetServer does not, and never has, accepted a LANMANv2 password. Although Windows 7 can use LANMANv2, this will not enable Windows 7 to map a NetServer network drive using a mixed case password.

Note: As stated above, Windows 7 can not use a mixed case password to map a NetServer drive to an IBM i running QPWDLVL 0. Setting the security policy to Send LM & NTLM responses will allow users to map drives without a domain name being specified; however, it will not allow connections to be made using mixed case passwords.

Note: It has been reported to IBM that changing LAN Manager authentication level to Send LM & NTLM - use NTLMv2 session security if negotiated has resolved a problem where a User Profile (used to map a NetServer drive from that PC to the IBM i) was being mysteriously disabled for NetServer use. IBM has no information on why not using this setting could contribute to the profile being disabled for NetServer, but is including this information here as an option that users in a similar situation might want to test.

NTLMv2 Authentication problem

There is a known NTLMv2 authentication problem in NetServer that could affect Windows 7 connections, as well as connections from other Windows OS versions. While the APAR description (MA37975) is fairly specific, the fixing PTF should be on any IBM i where NTLMv2 issues of any kind are suspected. This is fixed in the base code of 7.1 and later versions of IBM i.

V5R4M0: MF47178 (included in Cumulative PTF package 0117)
V5R4M5: MF47174 (included in Cumulative PTF package 0117)
V6R1M0: MF47172 (included in Cumulative PTF package 0215)
V6R1M1: MF47173 (included in Cumulative PTF package 0215)

Reprompting issues (including unexplained 'Access Denied' messages)

If Windows 7 continues to prompt when given the correct IBM i user ID and password, on the Connect Using Different Credentials prompt (single case if the IBM i has the QPWDLVL system value set to 0), instead of entering just the user ID, try entering something like IBM_i_IP_Address\IBM_i_UserID OR xxx\IBM_i_UserID. For more details on why this often works, see IBM Technote N1016520 Windows XP Prompts Repeatedly for a User ID When Mapping a Drive: That document also includes some additional options.

Reprompting can also occur for any authentication error, including an invalid User ID and/or password, trying to access QDLS where the user is not enrolled in the system directory, trying to access QDLS using the QZLSFILET thread capable prestart job (see QDLS access with QZLSFILET enabled section below), etc.

Threading issues: Windows 7 might display a pop-up window saying an internal error occurred when a user tries to map a drive to a share that points at the QDLS file system if the PC is already connected using a threaded job. See the following Rochester Support Center Knowledgebase documents :

N1015061 iSeries NetServer Threaded Request Support Introduced in V5R4M0 :

N1018967 Disabling and Re-enabling the Use of the Threaded QZLSFILET NetServer Job:

Windows Vista, Windows XP, and previous Windows versions returned an access denied message or just reprompted in this same situation. Windows 7 might display those same symptoms (access denied or reprompt), as well as possibly returning the internal error.

Kerberos issues: It appears that there might be issues with SMB signing in a Windows 7 Kerberos environment that prevent clients from being able to map drives using Kerberos. As a circumvention, you should either disable SMB Signing ('Require Clients to Sign Requests' on the Security Tab of NetServer Properties) or set NetServer Authentication Method (on the Security Tab of NetServer Properties) to 'Passwords/Network Authentication', which will allow clients to use Encrypted Passwords when they are unable to connect using Kerberos.

QDLS access with QZLSFILET enabled

Previous Windows versions have re-prompted with an 'Access Denied' message. While this behavior might still occur with Windows 7, "There is not enough memory to complete this operation." with a re-prompt has also been seen on Windows 7 when an attempt is made to map a drive to QDLS when a drive was already mapped to the root file system. See Rochester Support Center Knowledgebase document N1015061 iSeries NetServer Threaded Request Support Introduced in V5R4M0:


Performance Tips
1. A situation has been seen where Windows 7 delayed up to 40 seconds after a mixed case password failed to authenticate. In at least one case, performance was greatly improved by avoiding such authentication failures. Because mixed case passwords will not work when using Windows 7 to map a NetServer drive (see section on LanMan Authentication above) the work-around is to manually type in a lowercase password if the Windows/Domain password is in mixed case.

Authentication failures can also be seen in situations where Windows does not encrypt the password correctly if the resource is untrusted. See Rochester Support Center Technote N1016520 Windows XP Prompts Repeatedly for a User ID When Mapping a Drive: for additional details and information on how to circumvent this sort of failure by using a combination such as iSeries_IP_Address\UserID when mapping the drive.
2. Sharing the root file system (share path of /) is not recommended when NetServer drives will be mapped from Windows 7. A situation has been seen where Windows 7 was indexing everything under root, and when it began to index /QNTC/*, NetServer was overloaded and experienced delays. Because the /QNTC file system is on the root of the IFS, this problem is not encountered when sharing at a level other then root.

Note that neither is sharing of the /QNTC file system recommended. QNTC is the file system that allows an IBM i system to access PCs on the network. Rather than having a client PC access the IBM i (using NetServer) and then access other PCs from there, it is recommended that a PC that has a need to access another PC on the network do so directly (bypassing the need to connect to the NetServer).
3. Many Windows 7 users have seen performance issues when opening IFS documents on a NetServer network drive. In some cases, changing the Web Client Start-Up type from Manual to Automatic has improved performance. Follow the steps below to do this:

a. Click Start.

b. Click Run.

c. Type services.msc and click [ok].

d. From the list of Services listed, double click on Web Client, and change Start-up type from Manual to Automatic. This value defaulted to Automatic in Windows XP. The default was changed to Manual in Windows 7. Having this service automatically start up (and therefore always active) can sometimes improve performance.

Alternatively, totally Disabling the Web Client has caused drastic performance improvements for other users.

a. Click Start.

b. Click Run.

c. Type services.msc and click [ok].

d. From the list of Services listed, double click on Web Client, and change Start-up type from Manual or Automatic to Disabled.
Note: IBM does not know what functions do and do not use the Web Client. Users who are concerned that setting the Web Client to Disabled will break other functions should contact Microsoft for information on the function of this service.
4. It has been reported that in some cases, disabling SMB Signing ('Require Clients to Sign Requests' on the Security Tab of NetServer Properties) has improved the speed of making connections for both Windows 7 64-bit and Windows 7 32-bit clients. This was reported in a Kerberos environment and might or might not apply to an environment using encrypted passwords rather than Kerberos.
5.



6.
If opening an Excel file that is stored on a NetServer share is slow and NetServer configuration setting "Allow opportunistic locking" is already disabled, see Microsoft Articles 2570623 and 2501584. If Office File Validation is in place, install the update described there. If that does not fix the problem, try disabling Office File Validation as described in Article 2570623 work-arounds.

It has been reported that in at least one case, disabling File and Printer Sharing for Microsoft Networks on the adapter settings significantly increased the speed of the file copy on a large file. To make this change, go into Change adapter settings, right click on the Local Area Connection, select Properties, and remove the check mark from File and Printer Sharing for Microsoft Networks.
Notes:
1. Windows 7 is officially supported when connecting to IBM i NetServer OS V5R4 and above, beginning December 1, 2009. Current NetServer PTFs are required.

New Cumulative PTF Packages will not be listed in this knowledgebase document. It is the client's responsibility to keep track of new Cumulative PTF Packages. To locate the current package, go to the Preventive Service Planning - PSP Web site at http://www-912.ibm.com/s_dir/sline003.nsf/sline003home , select All Preventive Service Planning Documents by Release, select your release; then for V7R1, click on SF98710 Current Cumulative PTF Package, for V6R1 and V6R1M1, click on SF98610: Current Cumulative PTF Package or for V5R4M0 and V5R4M5, click on SF98540: Current Cumulative PTF Package.

In addition to the Cumulative PTF Package, all fixes from the Recommended Fixes Web site must also be applied. The Recommended Fixes Web site can be found at http://www-912.ibm.com/s_dir/slkbase.nsf/recommendedfixes . On the Recommended Fixes site, select your release (V7R1, V7R2 or V7R3, then select the product. The Recommended Fixes Web site is reviewed every two weeks and updated with new PTFs as they become available.
2. In the December 2009 time frame, a defect was suspected in Windows 7 that was preventing Windows 7 from running executables from NetServer mapped drives on a NetServer that did not support NT style error codes (V5R4 does not support NT style error codes; this was a new function at V6R1.). There are certain DLLs that Windows searches for when running an executable. The Windows client should look first in the directory where the executable is located, and then search the system path. When connected to NetServer V5R4 (which does not support NT style error codes), Windows would search only the directory where the executable existed and the DLLS are not in that directory (they do not belong in that directory). Windows did not go on and search the system path. When Windows did not find the DLLs, the executable failed to run. When connected to a NetServer that supported NT style error codes, Windows correctly searched the system path for the needed DLLs. This appeared to be a Microsoft defect with Windows 7, and the NetServer developers had recommended that users who encountered this problem contact Microsoft.

Update added 02/17/2010. Microsoft article 978869 describes a fix which appears to correct the problem of Windows 7 searching for DLL files in the incorrect path. To view article 978869, go to the Microsoft Support page at //support.microsoft.com/ and search for 978869. A link to the hotfix should be available in the resulting document.
3. Print/Printer issues: In at least one case, a Windows 7 user was unable to connect to her printers, although the file shares were accessible. Here are the steps that were taken to resolve that issue:

a. Verified that security policies were set properly according to this technote.

b. Restarted and changed the PC password to match the iSeries password.

c. Went into NetServer properties in iSeries Navigator and checked Allow NetServer Access using system name.

d. Created a new iSeries DEVD:

CRTDEVPRT DEVD(WINDOWS7) DEVCLS(*VRT) TYPE(3812) MODEL(1) ONLINE(*NO) FONT(11)

Note: Type and Model on the CRTDEVPRT command will vary, depending on the printer involved.

e. Found this new printer in Basic Operations and right clicked to create a new share; took all the defaults.

f. Accessed the system using \\SYSTEMNAME and double clicked on the printer.

g. Was prompted to select a driver; driver was selected.

h. Printed to the printer and moved the resulting *USERASCII SPLF to another printer OUTQ, and it worked fine.
4. When deleting a directory which contains objects with Windows 7 or Windows Server 2008 using iSeries NetServer, an Access denied error is returned instead of a Directory not empty error. This causes the delete of a folder from the Windows GUI to fail with a Folder Access Denied error instead of deleting the folder and its contents. This issue is described in APAR MA38734. You should refer to the APAR for information on the current PTF for OS/400 V5R4M0, V5R4M5, V6R1M0, and V7R1M0. APAR MA38734 can be reviewed online by going to http://www-912.ibm.com/n_dir/nas4apar.nsf/nas4aparhome, clicking on Search, and searching by the APAR number.
5. If there is a need to set LAN Manager authentication level back to 'not set' for any reason, this change can not be made through secpol.msc. To the best of our knowledge, this change can only be made by deleting the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel registry key. This means delete only LmCompatibilityLevel. Do not delete the entire path or even any of the preceding levels in the path. Contact Microsoft if you need assistance or have questions on doing a direct edit of the PC registry.
6. A user maps a NetServer drive in Windows 7; however, then the user cannot see it. This has to do with Windows User Account Control. In Windows 7, UAC (User Account Control) is on by default. Network drives that are mapped from a session using an administrative token are invisible to sessions that do not have an administrative token, and vice versa. Microsoft Support article 937624 is written for Windows Vista; however, it describes a situation that can also be seen with Windows 7. Search Microsoft's Support site at //support.microsoft.com for 937624 in order to view the article. This is something that IBM has no control over; however, IBM does want Windows 7 NetServer users to be aware of this.

Historical Number

539958206

Document information

More support for: IBM i
Host Servers

Software version: Version Independent

Operating system(s): IBM i

Reference #: N1018525

Modified date: 21 January 2013


Translate this page: