Windows Forum

Ask something
Discussion Locked

Win 2000 and Explorer Network Response

0 helpful
55 replies

by brymar

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
I am in the midst of deploying 850+ Dell GX-240, 1.5GHz, 256 MB, 20GB Win 2000 Pro SP1 with a Netware Client in a heterogeneous environment. We are trying to deploy with IP only using the Netware for Win 2000 client (4.8 and 4.81). Most are base image deployment with a few special builds, so some may use CSNW with NWLink. Also using NDS, NDS4NT, WINS, and Netware 5.0. HELP!! HELP!! HELP!! HELP!! HELP!! When using Win Explorer or a drop-down box for resources as in "save as" or "browse", the network is very unresponsive. Sometimes Win Explorer will have blank white panes, the roving "flashlight", or an incomplete list os resources. It will almost always finish in due time and correctly, however this is unacceptable. I suspect layer 7 issues with CIFS/SMB between Win200 and Netware. Turned off file caching on the NW Client; marginal improvement. Tried using IP only, no NWLink; marginal improvement. HELP!! HELP!! HELP!! HELP!! This must have been seen elsewhere, but no Technetsolutions, only discussion forum arguments of this "Phantom delay"; some blame NIC drivers or other hardware conflicts. All drivers are current and listed on the HCL. Are there incompatibilities in NDIS from 9x to NT with Netware???? Are there inherent resource resolution messages and extraneous traffic due to the newly deployed security requests with Win 2000??? Are there newer CIFS/SMB requirements in Netware when using IP versus IPX??? Please help our deployment

55 replies

by brymar

Point value changed by question poster.

Added additional 10000 points for a total of 15000 to keep this at the top of the list.

Sending request to Microsoft local office and corporate in Redman.

Additional tweaks include running IP only anddisabling NWLink. Adjusting NW Client for proper name space resolution and redirection. Marginal improvement...

by mr. ezekial transistor

Well with so many variables I can suggest some possible answers, none I would think would be hardware though NIC driver is often a culprit. My best answer is get the post-SP2 Service Pack hotfix (or Win2000PreSP3Fix) that addresses an Mstask.dll issue. I think you can only get it through MS Tech Support at this point because it seems they took it off their site. Reference (Q269590)and tell them they are jerks for not having available!

by mr. ezekial transistor

P.S. I know every monkey and their Mother is going to add in some junk just because you put 15000 pts. there but try what I suggested as I rate it 85% likely to solve your problem.

by shanghai sam

Contacted Microsoft and opened a support call. Still in testing and evaluation phase. Received mstask.dll and no change in performance. Thanks anyways

by matt duggan

This will probably sound too obvious to be of any help, but have you tried a packet capture of one of these situations? Perhaps knowing what it is that the workstation is talking to while it is frozen will be of help. At least it could help you narrow the search down.

Another option we came up with here was putting a client workstation on the same segment as the servers (both NDS and AD). Perhaps something in the middle (router? switch? another workstation?) is interfering.

Failing all that, have you been able to reproduce this in a test environment, with absolutely no extraneous factors (isolated segment, no users, no stray traffic, nice quiet room)?

by shanghai sam

Currently several engineers are analyzing over two dozen captures with clearly several thousand frames. Nice try, but no real help...

by timthetoolman

Hi,

I know you didn't want Technet articles but I believe your problem is a problem of name resolution.

The following article describes the method used and techniques you can use to fix the problem.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q172218

(remove spaces from the above URL)

Other information you haven't supplied in your answer is... Can you ping other machines using IP address? And using the NetBIOS name? What are the differences if any?

If none, then you can eliminate nic and driver problems.

Do you have a DNS server? Is it operating correctly for the new machines? Or are they re-trying several times and timing out before going for NetBIOS resolution?

Try the suggestions at the bottom of the above article.

Cheers,
Tim.

by timthetoolman

but I must admit having looked at electrokungfu's answer in detail he seems to have picked up a great reference!

Obviously you'll be looking at that first!!!

Cheers,
Tim.

by shanghai sam

Name Resolution priority and provider priority are areas already tuned and areas that are additionally in evaluation. Testing with both Microsoft and Netware clients is underway. Thanks again, but no real help...

by cwunder3

Try updating your Novell Clients. There are newer clients out now and patches to the client. The 4.81 is problematic.

by cwunder3

There is SP3 for Novell Client 4.8 that fixes multiple issues including Dell specific errors and network bottlenecks.

by shanghai sam

No real help. Various client from 4.71 to patched 4.81 were tested with no differentiation in performance noted. Thanks for the info...

by drakocy

MS-Explorer can only process the data it has received. Your comment that "It will almost always finish in due time and correctly" leads me to believe it is network/bandwidth related.

Layer 1 Solution?
Any CRC errors on the NIC? "netstat -e 2" from a command window will show you information in 2 second intervals. a lot of CRCs = a lot of duplicated work!

Layer 2 Solution?
again if you are using an Ethernet interface then you may want to turn off the "auto-detect frame type" feature in the IPX protocol. The auto-detect feature sends out 4 times as much traffic as necessary hoping that one will be responded too! You will need to select the correct Ethernet Frame type to match your LAN, so that you will continue to receive IPX SAPsand RIPs.

There may also be excessive collisions for your Application on the LAN and you may want to consider Ethernet Switching instead of Bridging.

Layer 3+
The IPX protocol was designed to support small-medium LANS (less than 500) and doesn't scale well unless the LANs are segmented with routers caching this information.

You may also want to consider limiting who is responding to the broadcast browse request packets. A URL describing the way MS-Network works can be found at http://www.net.cmu.edu/docs/arch/ms-networking.html

Good Luck,
Doug Rakocy,
CCIE/CCNP/CCNA/CCDP/CCDA/MCSE

by shanghai sam

We have plenty of bandwidth. While this may eventually lead to NDIS 5 versus 5.1 and the HCLQ of our boxes, there are many new packets as a result od Win 2000. BS or Browsing Services is leading us to rethink our deployed clients and our topology. Thanks for the graet insight!!!

by mm212

I ran into this EXACT problem on Windows XP Pro RC1. Unfortunately, I can't give you an answer, but I will give you what it isn't. It is most likely not a hardware problem. After I tried XP for a while, I went back to Win2K and have had no problems.I tend to believe it is in the driver or (more likely) the Novell Client and the way it interacts with the OS. Be sure you get the latest client and drivers for your NIC. Good luck!

by ustutz

Sounds like a browsing problem. Make sure you have only the protocols you need on your clients (TCP/IP and IPX/SPX). Delete all others (NETBeui, etc.). On your DCs make sure you have both protocols configured (both TCP/IP and SPX/IPX). That way your clirnts can get all browser information from one master browser. Also, in NT4.0 you could hack the registry to fix the browse master to the PDC. Haven't had a need to check that on W2K yet.

by ustutz

One afterthought: Are deploying - i.e., imaging - over the LAN? That will actually force any LAN to its knees. I'd separate the imaging process from the desktop deployment. Run an assembly line in a spare office with a cheap little hub for all the image work. Don't connect to the production LAN until you are ready to set PC on the user's desk.

by chris hirst

It would be nice to know the NIC involved. I would put money on it being 3com. While it is very nice to know the machine spec some hint of the network setup might help in solving a networking problem. Also if it has been seen elsewhere there is every chance of it appearing in a Technet article, So don't exclude the reference library that most of us will make use of on a regular basis.
Anyway you can reject this when you post up the network info.

Chris.

by mike.yazdzik

have you check the binding order for your nics? i have had problems similar to this and setting the binding order and the provider order did the trick. the network provider must have Microsoft WIndows Network first if your using a domain environment. the browser service will use the first provider first to browse the network. if novell is first it will give delays like your talking about.

by grbeckmeyer

Change the network provider order to make Microsoft the first provider.

To change the provider order in Windows 2000:
My Network Places - Properties - on top bar Advanced - Advanced - Provider
order - Highlight Netware and click the down arrow(or Microsoft and click the up arrow). Click OK and if needed, Cancel. Go back in to make sure that change took place. Reboot.

by mteff

I know this may not be what you want to hear, but I have run into this issue as well. I spent numerous hours trying to investigate the problem, with no luck on find a reasonable answer to why. Other then that NW and MS dont play well together.

It came down to this, browsing MS resources was slow, but browsing to NW resources was fine. The only solution: Since the NW Client wasn't need, I went back to using MS's Client services for NW.

Browsing speeds to NW servers and MS servers were fast and stable. So if you can do with out the NW client, do so.

by emosier

One of the most common issues with the problem of browsing the network is an installation and configuration issue. My Windows 2000 Pro stations browse both my Microsoft and Novell services without issue.

Critical things that must be right:

1) The client install. Did you choose "typical", or IP only?, or what? The client must be installed with the proper protocols to work right.

2) SLP - Critical for the Novell side of things to work right. Dump the SLP options out with your DHCP server, and make sure the clients get configured properly. Make sure your DA's are working properly.

3) The caching features of the client help, if properly configured to match settings on the NW Servers.

4) Bindings: You must clean up the W2K bindings. By default the MS client binds to all protocols. You sure don't need MS binding to IPX, nor IPX/32 for NW. At the same time, in a mixed environment of IPX and IP, you may not need the NW client binding to IP.

Summary: Install, configure, and properly deploy SLP services. Configure the clients to match. Check your ws's bindings. Turn your client caching back on. Life will be good.

by emosier

If you are in need the specifics of any of this, or would like TID numbers, let me know. Windows and Netware play well together, IF properly configured.

- Erik Mosier, CNE since 91

by shanghai sam

...see answer 3. We are attempting pure IP from all clients. Protocols, providers, resolution are all under scrutiny. Thanks anyways. BTW, we don't use a DA and all is good in pure IP with access to only Netware. It really lies with MS and the redirector interfacing with NDIS.

by decdac

I believe the main problem is in browsing on Win2000. We had one master browser that was on a Samba setup, it seemed not to answer the requests from the domain controller quickly enough, but the DC kept trying over and over again to get the browsingupdate. You should check to make sure that all of the domains being checked (and workgroups) are adequately responding.

by shanghai sam

...definitely helped us. We are reviewing our workgroups. While the one lone MS domain with its handle into NDS is fine, most other rouge WG's are too slow, not needed, and not reliable. Taking MS out of the networking schema is great, but not workable. We are still working with a consultant, Dell, and Microsoft to tune the remainder. Thanks for the great insight!!!

by joseph moore

I think the Mstask.dll suggestions are right on the money, but I will make a suggestion that, in addition, might help, and that is to increase the Autodisconnect setting.
I had some browsing delays on a Win2k box until I set the autodisconnect setting to never disconnect; well, that isn't exactly true. You can set Windows to autodisconnect (sever its active connections) once every 8171 years!
Try typing this in a command prompt:
net config server /autodisconnect:-1

Here is the url for Technet article Q138365:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q138365
(please remove any spaces)

Hope this helps.

by shanghai sam

...See answer 1. BTW we are not losing mappings but moreover taking to long to find them. Thanks anyways.

by maxwell edison

You can experience a delay as long as 30 seconds when you try to view shared files across a local network from Windows 2000. For example, this delay would effect your search if you:

1. Right-click the My Network Places icon on your Windows 2000 desktop, click Search For Computers, and search for a Windows 98 or Windows Me computer name; or

2. Click Start, Run, and then type \\computername in reference to a Windows 98 or Windows Me machine.

Microsoft confirms this is a problem in Windows 2000. See Microsoft article Q245800

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q245800

(REMOVE SPACES from the pasted URL.)

The problem doesn't occur when browsing directly to a named computer share, just when using the computer name.

Windows 2000 is using the extra time to search the remote computer for Scheduled Tasks, a slow and unnecessary process. What follows is a work-around that dramatically speeds things up.

----------

In Windows 2000, click Start, Run,type regedt32, and click OK.

In the Registry Editor, navigate to the following branch:
HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/Current Version/Explorer/RemoteComputer/NameSpace.

Under that branch, select the key {D6277990-4C6A-11CF-8D87-00AA0060F5BF}. This key instructs Windows Explorer to search for Scheduled Tasks. If you wish, pull down the Registry menu and click Save Key to back up this value. Name the output file, say, Scheduled.reg, and you can easily restore the key if necessary.

Delete the key and close the Registry Editor.

This change takes effect immediately and doesn't require a reboot, so you can determine how much it speeds up the process.

Good luck,

Maxwell

by sojournist

Change the binding order of the protocols. Clients will try to connect to resources with the protocol listed first on the adapter's protocol binding properties.

Clients never learn which servers respond to which protocols. They always connect with the protocol listed first. Then, if connection fails using that protocol, it will resort to communicating with the next protocol, and so on.

If you added NWLink and CSNW to a client, it will use those resources to connect to Netware services and browse the Bindery ONLY after it has failed to do so with TCP/IP (listed higher in the binding list).

Changing NWLink to the top will force workstations to try NWLink first, boosting response time (because it doesn't have to wait for TCP/IP tofail) and saving you the frustration of the flashlight.

by maelgwyn

I know it may be stupid, but have you tried to install GSNW and use it to share to the 2k network? It would solve problems of using nwlink on each wkstn.

Hope it gives anyone an idea (at least)

by shanghai sam

No real help, we are trying to eliminate all client IPX chatter and use pure IP. Thanks anyways...

by therock_3333

i dont know if someone said this already, but is windows autodetecting the wrong frame type for ipx\spx, or perhaps wrong protocol binding order

by mhindt

Remove the file and print sharing from all the workstation that you do not wish to have file and print sharing. The Microsoft client uses a broadcast to find the computer even if WINS is installed (I imagine try to get to the browse master in 850 computer network would be a nightmare esp. if it is a workgroup and not a domain). You might try to change the WINS/Netbios node type from the default H-node to P-node. You can change the Node type in either the DHCP server when it assings IPs or on the clients under the reg key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters

Set it to 2

by xanderoth

Well, just another suggestion to help you out. Turn off the autosensing capabilities of all the NICs and hub/switches. If you have 10Mb connections to the network (JetDirect printers for example- pull em or upgrade to 100Mb cards)

The lack of proper media-type detection can occasionally cause timeouts in several services, including netlogon and browsing. This problem can affect any O/S.

Good Luck and remember- Fdisk, format and forget about it.

by shanghai sam

...no real help as we are 100BaseT shop and configure our NICs when possible. However fdisk is still a good choice. Thanks for the laughs around here...

by semi-pro 64

We have Dell computers at my company and we were having some of the same problems. On our computers (Dell 330 Precision) the computers have the NIC built into the motherborad, and for some reason, they ran slow. I put in new PCI NIC into the computers in question and things work fine now.

by shanghai sam

Dell is coming in Monday. They feel the hardware may be an issue. I feel the NIC could best be utilized as a paperweight, but it is embedded. Your test of an additional PCI is great. Along with all other acceptable answers, your may prove just as valuable. Dell has even noted their engineers could, if necessary, rewrite or bugfix the firmware.

by brymar

While no one answer was the "Silver Bullet", those accepted help steer our tiger team into a workable plan. We have met our immediate objectives and formed some short and long term goals. The immediate performance tweaks included removing the Microsoft Client where possible, and tweaking the Netware Client for IP and our resolution schema. The protocols used, their prioirty, and the network types accessed all played into the problem. We assessed that problem well, but still had degradations. Even now I can dog slow a box in less than 30 seconds, so we are not out of the woods yets. Those answers accepted gave insight to larger issues than we were ready to see. Our end wires devices are more of the problem than we wanted to discuss. Win 2000 was and is new for our environment. Thanks for all who answered and especially those who took "ownership" as well. Thanks again...

This discussion is closed to new replies.