Error: 601: Error getting user information

Keywords: 	 Error: 601: Error getting user information  w9xUserInfo

Question:

We are sporadically getting the following error message while running our logon script:
WIL Extender Error: 601: Error getting user information fullName = w9xUserProps (logonServer, userName, 1)
We only see the message occasionally (less than 1% of the time). I haven't been able to duplicate the error for troubleshooting purposes. And to make it even better, the error isn't even listed in the documentation!
Here's where it's failing. The code has already tested for the operating system and set winFlavor to "wnt" or to "w9x"...
If winFlavor == "wnt" AddExtender ("WWWWNT34I.dll") userInfo = "wntUserInfo" userProps = "wntUserProps" memberGrps = "wntMemberGrps" getCon = "wntGetCon" cancelCon = "wntCancelCon" addDrive = "wntAddDrive" Endif If winFlavor == "w9x" AddExtender ("Www9x34i.dll") AddExtender ("Www9534i.dll") AddExtender ("Wwn3z34i.dll") userInfo = "w9xUserInfo" userProps = "w9xUserProps" memberGrps = "w9xMemberGrps" getCon = "w95GetCon" cancelCon = "w95CancelCon" addDrive = "w95AddDrive" Endif ; Measure time (in ms) that it takes to get info over the network linkStartMs = GetTickCount () userName = StrUpper (%userInfo% (0)) fullName = %userProps% (logonServer, userName, 1) homeShare = %userProps% (logonServer, userName, 5) homeDrive = %userProps% (logonServer, userName, 6) groupLst = %memberGrps% (logonServer, userName, @GLOBALGROUP, 0) linkEndMs = GetTickCount ()
I'm trying to do all the network access together in order to determine the speed of the network link. The script adjusts its behavior if a slow link is detected.

Thanks so much for your help...

Answer:

How do you pick up the username? On 95 systems there is a problem reliably getting the username depending on how fast the server logs you on.

I'm not happy with the way you pick up the user name. Especially in a login script. Use the w95GetUser function instead. It has code to automatically retry during a login process.

Question (cont'd):

I'll change it and see if that helps.
I am curious though... Why are you not happy with this method of getting the user name? I got it directly from the documentation.
New info: The script runs fine on ~1000 PCs. They rarely get the "601" error (only 2 incidents in the past 2 weeks). Our dial-up notebook PCs with combo (Ethernet/modem) cards seem to be getting the vast majority of the errors.

Thanks again for your help...

Answer:

The logon process is somewhat asynchronous, and different in the 95/98/NT environments.

The initial determination of the userid is the most problematic. People usually use w95GetUser(@default) which works in a logged on session but often fails in a login script because the user is not fully logged on yet, and windows is not quite setup to support all the functions.

There was an alternate method in a tech support article which seems to work well.

In your case, you are going after the currently logged on user name. But if the user is not fully logged in when the command is executed...then I would expect it to fail. Perhaps over the slower dialing links the script is getting ahead of the phone line traffic and when it makes the request...well I'm not sure but I am worried.

For debugging you could maybe add a TimeDelay(10) in there to give the other processes time to think.

Question (cont'd):

As a test I changed the failing line to:
fullName = %userProps% ("%logonServer%", "%userName%", 1)
so that the values of the variables would be included in the error message. When it failed, I checked the logon server and username and they were perfect!

Could error 601 indicate some sort of timeout situation *within* the w9xUserProps call itself? It is definitely getting valid parameters passed to it...

Answer:

Make the error occur again then look in your WWWBATCH.INI file and find the LASTERROR line associated with the extender.

With that information we might be able to look up a better error message

Another user comments:

You are actually dealing with two problems here. The first one (IMHO) is that you are checking to see if the user is connected by RAS rather than directly. Here is a MUCH easier way to check this (and the way that we do it)

This is how we test our Win95 systems to NOT run update programs if RAS connected.


; Start of Winbatch Code

; errormode MUST be turned off for this query to avoid Winbatch crashing if NOT remote
ErrorMode(@OFF)
RemTest=RegQueryBin(@REGMACHINE,"System\CurrentControlSet\Services\RemoteAccess\[Remote Connection]")
ErrorMode(@CANCEL)
If RemTest=="01 00 00 00"
	Remote=@TRUE
	Display(2,"Connection Status","System is connected by RAS")
Else
	Remote=@FALSE
	Display(2,"Connection Status","System is connected to local network")
EndIf

	; End of Winbatch Code

The second problem, your timeout is with the Combo cards. Win95 does NOT like combo cards, in that it does not isolate each function of the card, and run them separately. We noticed this problem here first and it was confirmed by Microsoft. When you first turn your remote Win95 workstation on, it initializes the network portion of the Combo card which makes it take FOREVER to start up, especially if you have Persistent connections. Then, when you go and run your RAS session, since you have already logged in to the workstation, Win95 assumes that you have logged into the network and will NOT run the Login script.
We fixed the problem around here by getting the Combo cards exchanged for separate Network and Modem cards. Also, the newer versions of the laptops we were using started shipping with internal modems, negating the issue.
I am NOT sure if Win98 has the same problem with Combo cards, MS may have fixed it (it may even be fixed in the latest OEM versions of Win95 (OSR2.5 and later) but we haven't been able to test this. Hopefully, I have shed some light on your problem and you may want to try testing on a laptop with separate NIC and Modem cards.

Resolution:

A few weeks later, the user reported the following:

It turns out that something similar was also failing on remote server tools - with Enterprise Administrator, which is doing the same thing as w9xUserInfo. It's a Microsoft problem.

There are two DLLs that need replacing - they were either the wrong version or 0 byte files:


	RPCRT4.DLL
	RPCLTC1.DLL

A patch from Microsoft, DCOM98 PATCH, updates these files and the OLE responsible for the remote procedure call.

Here's a paired down article from MS:

INFO: DCOM98 Release Notes

SUMMARY

DCOM98 is installed by the Visual Basic installation program. Visual Basic and some applications created in Visual Basic require DCOM98 to be installed in order for some components to run properly. DCOM98 extends support for DCOM (Distributed Component Object Model) for Microsoft Windows 98 and Microsoft Windows 95. DCOM98 is not required for Windows NT systems; DCOM is an intrinsic part of the NT operating system.

This article contains the DCOM98 Release Notes.

MORE INFORMATION

The release notes are only available after DCOM98 has been installed. After DCOM98 is installed, the release notes may be found at the following location:


\Windows\System\Dcom98\relnotes.txt

DCOM98 is also available on Disk 1 of the Visual Basic installation CD-ROM in the DCOM98 folder. For more information about the two files in this folder, please see the Release Notes below.
DCOM98 Release Notes
DCOM98 extends support for DCOM for Microsoft Windows 98 and Microsoft Windows 95. Please note the following instructions, guidelines, and features new to this release of COM and OLE functionality for Windows 95 and Windows 98.
Distributed COM (DCOM) extends the Component Object Model (COM) infrastructure, transparently and naturally adding support for reliable, secure, and efficient communication between COM components, such as ActiveX Controls, scripts, and Java applets residing on different machines in a LAN, a WAN, or on the Internet. With DCOM, your application can be distributed across locations that make the most sense to your customer and to the application.
For more in-depth information, please read the DCOM Technical overview, available on the Microsoft COM Home Page at:
http://www.microsoft.com/com/

I. INSTALLATION NOTES A. Downloading and Extracting DCOM98 After downloading DCOM98, you will have one or two compressed executable files on your hard drive: DCOM98.EXE contains the COM system DLLs DCM98CFG.EXE contains the DCOM Configuration utility II. RELEASE NOTES Replacing DCOM98 with Older Version Prohibited In previous releases of DCOM95, you could replace a newer version of DCOM95 with an older version of DCOM95. DCOM98 now checks version numbers on installation and does not allow you to install an older version on top of a newer version. This change will avoid problems with incompatible versions of DLLs. Setup creates a directory called DCOM98 under your system directory. DCOM98 File List This table lists the version numbers of files distributed with DCOM98: oleaut32.dll 2.30.4261 secur32.dll4.10.1999 compobj.dll2.3.1 ole2.dll2.3.1 ole32.dll 4.71.2512 olecnv32.dll 4.71.2512 olethk32.dll 4.71.2512 rpcltc1.dll4.71.2512 rpcltc5.dll4.71.2512 rpcltccm.dll 4.71.2512 rpclts5.dll4.71.2512 rpcltscm.dll 4.71.2512 rpcns4.dll 4.71.2512 rpcrt4.dll 4.71.2512 rpcss.exe 4.71.2512 storage.dll2.3.1 stdole2.tlb2.30.4261 stdole32.tlb 2.1 imagehlp.dll 4.00 dllhost.exe4.71.2512 comcat.dll 5.0 iprop.dll 4.00 rpcmqcl.dll4.71.2512 rpcmqsvr.dll 4.71.2512 olepro32.dll 5.0.4261 asycfilt.dll 2.30.4261 This table lists the version numbers of files distributed with DCM98CFG: mfc40.dll 4.1.6139 msvcrt40.dll 4.21.0000 dcomcnfg.exe 5.00.1601.0 oledlg.dll 1.0 ciscnfg.exe4.71.2424 You can find additional information about DCOM on the COM Home Page at http://www.microsoft.com/com/ Additional query words: Keywords : kbVBp600 kbNTOS kbWinOS95 kbWinOS98 kbRegistry kbDCOM kbVS600 kbsetup Version : WINDOWS:6.0 Platform : WINDOWS Issue type : kbinfo

Another User's Resolution:

Another user reported getting the 601 error due to a misconfiguration of the target machine. He had LastError=1722 (NetUserGetInfo) in his WWW-BATCH.INI file. This error indicates: "The RPC server is unavailable"

When he looked at the machine eventlogs, he had massive networking problems around the browser service on the BDC. Seemed to be a multihomed machine with some Novell SW running. There's a documented problem with this type of machines at MS.

Here's an article from MS that details the problem: Event ID 8021 or 8032 on multihomed master browser due to subnets linked.

Event ID 8021 or 8032 on multihomed master browser due to subnets linked.

Cause:

On a master browser computer with multiple network cards running the TCP/IP protocol, Event 8021 and Event 8032 are occasionally recorded in the System log. This can occur if both network cards are linked to the same subnet, or are indirectly linked together by other subnets. Microsoft has confirmed this to be a problem in Windows NT Server 4.0.

Solution:

As a workaround, you can disable the bindings for all but one of the TCP/IP subnet transports to the Workstation service, or remove all but one of the network cards. You can also stop the 'Computer Browser' service, but you will be unable to browse other networks.

1) Do one of the following as a workaround:

a) Disable the bindings for all but one of the TCP/IP subnet transports to the Workstation service.

b) Remove all but one of the network cards.

c) Stop the 'Computer Browser' service.
NOTE: If you stop the 'Computer Browser' service, you will be unable to browse other networks.

2) After performing one of the workarounds, wait for at least 10 minutes and check the Event log to see if errors 8021 and 8032 are still being recorded in Event Viewer.

3) If this problem still occurs, locate, remove, and reinstall any protocols for which browsing is failing:

a) In Event Viewer, find the transport and protocol that failed.
NOTE 1: The failed transport can be identified in the event error message by text similar to 'The browser was unable to retrieve a list of servers from the browser master <PDC> on the network \device\<protocol_netcard>' or 'The browser service has failed to retrieve the backup list too many times on transport of <protocol_netcard>', where <protocol_netcard> indicates the transport.
NOTE 2: The transport for NetBIOS over TCP/IP will appear as 'NetBT_<network card driver name>', such as 'NetBT_E100B1'. The transport for other protocols will appear as follows:
NetBEUI protocol appears as: Nbf_<network card name>.
IPX/SPX protocol appears as: NwlnkIpx (the network card name does not appear).
NetBIOS over NwLink appears as: NwLnkNB (the network card name does not appear).

b) Check the status of the Browser service for all installed protocols:

1] Open Command Prompt.

2] Type the following at the command prompt and press ENTER:
BROWSTAT STATUS
NOTE 1: The Windows NT Server 4.0 Resource Kit must be installed to run the Browstat utility.
NOTE 2: The browser status for all transports will be displayed. Ignore any transports that list 'NdisWanX'; these represent bindings to remote access devices.

c) Remove and reinstall the protocols for which browsing is failing:

1] Record protocol configuration information:

a] Open Control Panel.

b] Double-click the 'Network' icon. (The 'Network' dialog box appears.)

c] Click the 'Protocols' tab.

d] Select the desired protocol, and click 'Properties...'. (The '<protocol> Properties' dialog box appears.)

e] Record the protocol configuration on each of the tabbed pages.

f] Click 'Cancel' to close the '<protocol> Properties' dialog box.
NOTE: The information you recorded will be used to reconfigure the protocol after you remove and reinstall the protocol.

2] Remove the protocol:

a] On the 'Protocols' tabbed page of the 'Network' dialog box, select the protocol(s) to remove from the 'Network Protocols' list box.

b] Click 'Remove'.

c] Close the 'Network' dialog box.

d] Close the 'Control Panel' window.

3] Restart the computer.

4] Reinstall the protocol:

a] Open Control Panel.

b] Double-click the 'Network' icon. (The 'Network' dialog box appears.)

c] Click the 'Protocols' tab.

d] Click 'Add...'. (The 'Select Network Protocol' dialog box appears.)

e] Select the protocol to reinstall and click 'OK'.

f] Reconfigure the protocol settings:

1} Select the reinstalled protocol and click 'Properties'. (The '<protocol> Properties' dialog box appears.)

2} On each tabbed page of the dialog box, select the appropriate options using the information recorded in step 3)c)1].

3} Close the '<protocol> Properties' dialog box.

g] Close the 'Network' dialog box.

h] Close the 'Control Panel' window.

4) Restart the computer.
NOTE: If reinstalling the protocol does not correct the problem, there may be a problem with your network adapter. Contact the vendor to see if there is a new version of the driver available.

Article ID:   W13521

Filename:   601 Error Getting User Info.txt

File Created: 2001:03:13:11:04:16

Last Updated: 2001:03:13:11:04:16

Database Search

TechHome

Error: 601: Error getting user information

Question:

Answer:

Question (cont'd):

Answer:

Question (cont'd):

Answer:

Resolution:

Another User's Resolution:

Event ID 8021 or 8032 on multihomed master browser due to subnets linked.

Cause:

Solution: