IBM i NetServer Debug Checklist for Client Connection Problems

Using System i Navigator:

Open System i Navigator, expand My Connections | the system's connection | Network | Servers, and then select TCP/IP. Check to see if i5/OS NetServer shows as started in the list of TCP servers that is returned. If it does not show as started, then right click on NetServer and select the option to start.

Using IBM Navigator for i:

Open Navigator for i, expand Network | Servers, and then select TCP/IP Servers. Check to see if i5/OS NetServer shows as started in the list of TCP servers that is returned. If it does not show as started, then right click on NetServer and select the option to start.

Using a 5250 emulation session:

From the operating system command line, type the following:

WRKSBSJOB SBS(QSERVER)

Press the Enter key. Look for the QZLSSERVER job. QZLSSERVER is the NetServer job. If QZLSSERVER is not active, then NetServer is not started.

Alternatively, from the operating system command line, type the following:

WRKJOB QZLSSERVER

Press the Enter key. If no active QZLSSERVER job is found, then NetServer is not started.

In either case, try running: STRTCPSVR *NETSVR .

If NetServer does not start, refer to IBM Technote N1019128 IBM i NetServer Debug Checklist for Startup Failures.

Some PTFs deal with problems with mapping NetServer network drives. Review the Recommended Fixes information at http://www-01.ibm.com/support/docview.wss?uid=nas8N1021480 and confirm that the system has the current NetServer PTFs applied.

To view the information, choose the correct release, then select the IBM i NetServer topic from the drop down menu.

The recommendations from the Recommended Fixes website are for PTFs that need to be applied IN ADDITION to the current Cumulative PTF package. If the system is not at the current Cumulative PTF Package level, and the Cumulative PTF Package can not be applied at the current time, contact IBM Support for a listing of those NetServer PTFs that were on prior Cumulative PTF packages.

Note: Not all APARs fixed by each PTF are listed on the Recommended Fixes pages. This means that each PTF listed might fix problems in addition to the one(s) described in the listed APAR.

Using System i Navigator:

Open System i Navigator | My Connections | the system's connection name | Network | Servers and select TCP/IP. When the list of TCP servers is displayed on the right side of the window, right-click on i5/OS NetServer and select Properties. On the General tab, locate Server Name. This is the name to use when mapping a NetServer drive. To edit the NetServer name, click on the Next Start button, and change the Server value.

Additionally, if the option (on the same tab) is set to 'Allow i5/OS NetServer access using the system name' Yes, then connections can also be made to the IBM i system name.

Using IBM Navigator for i:

Open Navigator for i, expand Network | Servers, and then select TCP/IP Servers.

When the list of TCP servers is displayed on the right side of the window, right-click on i5/OS NetServer and select Properties. On the General tab, locate Server Name. This is the name to use when mapping a NetServer drive. To edit the NetServer name, click on the Next Start button, and change the Server value.

Additionally, if the option (on the same tab) is set to 'Allow i5/OS NetServer access using the system name' Yes, then connections can also be made to the IBM i system name.


Note: Any changes made do not take effect and do not show up in NetServer Properties until NetServer is ended and restarted.

 

o

Confirm that the PC user is signed on a PC network (domain) or the Windows desktop. This sign-on is required to enable Microsoft networking functions. To confirm that the user is signed on and to determine the user ID used, go to a DOS prompt, and type NET CONFIG WORKSTATION (for a Windows XP/7 or above workstation) or NET CONFIG SERVER (for a Windows 2003/2008 or above server).

Windows 7 and above does not really include a Search for Computer or Find Computer function, as earlier versions of Windows did. Consult your Microsoft Documentation or contact Microsoft Support if you need to find a way to do this function.

Historical Information: On Windows XP, do a Search for Computer using the TCP/IP address of the NetServer. To do so, right-click on My Network Places, and use Search for computer. If the NetServer is found, double-click to open it and view the shares. At this point, a NetServer drive can be mapped by right-clicking on the share and selecting Map Network Drive.

Although the Search for Computer function is no longer available in current Windows versions, here are some other trouble-shooting steps that might be helpful:
 

o	Are you able to access other PCs and computers on the network (from this PC)? If not, there is a problem with Microsoft Networking.
o	PING the IBM i by name and TCP/IP address. If either PING is not successful, there is a TCP/IP configuration, network, or name resolution problem unrelated to NetServer.
o	Does a firewall exist between the PC and the IBM i? If so, ports 137, 138, 139, and 445 must be open. If only Windows XP/7 and above clients are used, in most cases only port 445 must be opened. However, IBM Support has seen instances when these versions of Windows do revert to using ports 137,138, and 139. If NetServer access is attempted across the internet, it is possible that the Internet Service Provider (ISP) might have blocked one or more of these ports as well. Some virus activity has been known to attempt access using port 445 and some ISPs have blocked port 445 because of that potential risk. If IBM i Access for Windows is installed on the PC, the i Access CWBPING command can be used to check for an open route to the ports used by NetServer. Use the following syntax: CWBPING xxx.xxx.xxx.xxx /port:137. Repeat for 138 and 445.
o	Confirm that the QZLSSERVER job is active in the QSERVER subsystem and that the job is in EVTW status. WRKACTJOB SBS(QSERVER) can be used to determine the status of the job. If not, refer to IBM Technote N1019128 IBM i NetServer Debug Checklist for Startup Failures.
o	Type NETSTAT, and select Option 3. Press F14 to display port numbers. Verify that ports 137, 138 (required only for name broadcasts/browsing), 139, and 445 are active and listening. If NetServer is started and any of these ports are in a state other than Listen, contact the Rochester Support Center because a TASKINFO dump might be required.
o	If you are able to connect mapped drives to PCs on the network, Ping and CWBPING are successful, and the NetServer job is active, contact IBM Support for assistance in determining whether the Coded Character Set ID (CCSID) indices on the system might have been been corrupted.

If NetServer access by TCP/IP address works, but NetServer access by the NetServer name fails, there is a name resolution problem on the Windows network.

If NetServer is can not be accessed by name, do the following:

o

Confirm the NetServer name is correct by running NBTSTAT -A nnn.nnn.nnn.nnn (substituting the system's TCP/IP address) from a DOS prompt. This displays the NetBIOS Remote Machine Name Table that has an entry with the NetServer name (if it is started) similar to: QRCHASBDS <20> UNIQUE Registered

o

Configure an LMHOSTS file on the PC to resolve the NetServer name to the TCP/IP address of the system. In addition, the NetServer name and TCP/IP address should be added to the DNS server and/or WINS server on your network. For assistance with these steps, see IBM Technote N1017921, The iSeries NetServer Does Not Appear in Microsoft Windows Network Neighborhood. Note: Some versions of Windows can be configured to specifically use or not use LMHOSTS. Ensure the PC is configured to use an LMHOSTS file, if one exists. On Windows 2000/XP, this setting is found by right-clicking on My Network Places and selecting Properties. From the Network Connections Window, right-click on the connection being used and select Properties and Internet Protocol (TCP/IP), and click on the Properties button. On the General Tab, click on the Advanced button, and select the WINS tab. Ensure that Enable LMHOSTS lookup is selected. For Windows 7 and above, consult Microsoft documentation on how to enable LMHOSTS lookup.

If NetServer is found but Location says Unknown, the system is not able to authenticate the user ID it received.
 

o

The user ID used to sign on the Windows network is not a valid IBM i user profile or the Windows password for that user ID is not valid on the i. For Windows NT/2000/XP and above: Double-click on the NetServer to open it and sign on with a valid user ID when prompted. For a complete explanation of NetServer user profile issues, refer to IBM Technote N1010590, IBM i5/OS NetServer Security. For directions to enable GUEST support, see IBM Technote N1016971, Configuring IBM i NetServer to Use a GUEST Profile.

 

o	Confirm that one or more QZLSFILE or QZLSFILET job(s) are active in the QSERVER subsystem, have a type of PJ (prestart job), and have a status of PSRW, DEQW, or (if QZLSFILET) TIMEW. If any QZLSFILE jobs show up as type BCI, refer to the QZLSFILE Jobs Start as BCI Jobs section shown below. To check all of this, run the following command at the IBM i command line: WRKACTJOB JOB(QZLSFIL*) press Enter, then press <Shift><F2>.
o	Confirm that a share exists for the Integrated File System directory being mapped to. For additional information, see IBM Technote N1017477, Creating an IBM i NetServer File Share. Historical information: To map to a subdirectory, if using an older version of Windows, create a share to the subdirectory. Microsoft Networking, and the Windows NT and 9x platforms did not allow the mapping of drives below the first level share. For additional information, see IBM Technote N1017714, Can a NetServer Share Be Qualified When Mapping a Drive?
o	Determine whether it is possible to map to one share (like \QIBM) but not another. Check the permissions on the share. Using System i Navigator, expand the system | Network | Servers and click TCP/IP. When the TCP/IP servers are displayed on the right, double-click i5/OS NetServer. Expand Shared Objects, right-click on the share being mapped to, and select Permissions to view or change the authority to the share. Using Navigator for i, expand File Systems and select File Shares. When the list of File Shares are displayed on the right, right-click on the share being mapped to, and select Permissions to view or change the authority to the share.
o	If NetServer can be located (using Search for Computer) and the shares can be viewed but opening or mapping to a share causes a hang or an error, the QUSRSYS/QYSMSVRE user index might be damaged or at a previous level. To resolve this problem, delete the user index; it will be re-created on the next use. However, note that all Host Server customization will be lost unless the object is restored from a previous backup. For additional information, contact the Rochester Support Center.
o	Trying several methods of mapping the drive can help identify where the problem is. For additional information, see IBM Technote N1019414 Mapping a Drive to IBM i NetServer.
o	For Access denied messages, refer to IBM Technote N1019406 IBM i5 NetServer Debug Checklist for 'Access Denied' Errors.
o	Determine whether a mixed-case password is used on the Network logon. For additional information, refer to IBM Technote N1017262, Mixed-Case Passwords Fail with IBM AS/400 NetServer and IBM iSeries NetServer at QPWDLVL 0, 1.
o	Determine whether a Windows NT/2000/XP (or above) service (for example, the RUNRMTCMD command or Windows Scheduler) is being used to access a mapped drive. IBM Support recommends using a UNC path rather than a mapped drive if a service is being used.
o	Windows XP (and above) have encryption problems that can prevent user IDs and passwords from being correctly passed to the operating system. For additional information, refer to IBM Technote N1016520, Current Microsoft Windows Operating Systems Prompt Repeatedly for a User ID When Mapping a Drive.

It is recommended that NetServer QZLSFILE jobs run as prestart (PJ) jobs. However, they might start as batch interactive (BCI) jobs for a variety of reasons including: the subsystem the prestart jobs are configured to run in has not been started, the subsystem description does not contain the QZLSFILE prestart job definition, the definition does not set the jobs to auto-start, or the QUSRSYS/QYSMSVRE user index is damaged.

To confirm that the QZLSFILE jobs run as type PJ rather than BCI, do the following:

o	Use the WRKACTJOB JOB(QZLSFILE) command, and press F14 (<shift> <F2>)to view all of the prestart jobs. Confirm that one or more QZLSFILE job(s) are active in the QSERVER subsystem, has a type of PJ (prestart job), and has a status of PSRW or DEQW. If the QZLSFILE jobs are not active, run the STRPJ command and confirm they have started as type PJ.
o	If any QZSLFILE jobs have a type of BCI, end them manually.
o	If the prestart jobs do not start or if they start as BCI when accessing NetServer, the QUSRSYS/QYSMSVRE user index might be damaged. For information on deleting and re-creating this user index, contact the Rochester Support Center. If this problem occurred after an upgrade to new release, the QYSMSVRE index might be at an older, incorrect version. The most common cause of the problem is an incorrect upgrade or restore of library QUSRSYS. For additional information, refer to IBM Technote N1016699, Problems Mapping a Drive to IBM i NetServer after Upgrading IBM i OS version
o	Beginning wiith V5R2 NetServer, it became possible to configure NetServer to run in a subsystem other than QSERVER. To view this configuration, go to i5/OS NetServer Properties and select the Subsystem tab. By default, All Clients will be selected with subsystem QSERVER specified. If the option Use Server Defaults is selected, the QZLSFILE jobs will attempt to run in subsystem QUSRWRK, which (by default) is not configured to run QZLSFILE prestart jobs. If this option is selected, the QZLSFILE jobs will start in QUSRWRK as BCI, which is not desirable. For additional information, contact the Rochester Support Center.

QZLSFILET is the V5R4 (and above) job that handles threaded connection requests. QZLSFILE still handles non-threaded connection requests. The first session that is established from a particular client will determine which of these jobs will process subsequent sessions. If a PC already has a connection established to a threadsafe file system such as the root, attempts to map a drive to a non-threadsafe file system (such as QDLS) or attempts to drill into a non-threadsafe file system will fail with an access denied type error. This can include repeated prompting for the User ID and Password. For additional information about QZLSFILET and threading support on V5R4, refer to IBM Technote N1015061, iSeries NetServer Threaded Request Support Introduced in V5R4M0.

If the above steps do not resolve the problem, the following information is required:

o	The operating system release and cumulative PTF package level.
o	Ensure the current NetServer PTFs are applied. Refer to the Get Current PTF listing for i5/OSNetServer at the Recommended Fixes Web site at: http://www-01.ibm.com/support/docview.wss?uid=nas8N1021480
o	The Windows Client version (Windows 7/8.1/10/2012 Server or above) and service pack level.
o	If a browser is being used to access NetServer, obtain the version and service level of the browser.
o	The name of file or directory being accessed, the type of file (text file, Word document, and so on), and the size of the file.
o	The NetServer share name and full path to which this share points.
o o	Any VLOGs with major codes of 4400, 4401 and 0700 F2xx. SMB version information if running on OS 720 or above. CALL PGM(QZLSMAINT) PARM('40''0') Send the resulting QPCSMPRT Spooled file.
o	Additional documentation might also be required. Examples might include SMB SLIC traces, Task Dumps and TRCCNN traces. Contact the Rochester Support Center for the specific requirements and for assistance with collecting and formatting the traces.

If Kerberos has recently been configured on the network, refer to the following IBM Technote for useful information and links specific to this topic:

N1019201 Kerberos and the IBM i NetServer.