We have a network of 16 heavily used Windows 98 PCs connecting to a Server 2003 machine. These machines are experiences long delays when opening/running files on the network during times of peak usage (1:30-2:30pm daily), sometimes lasting a minute. The user will just get a black DOS screen as the executable is waiting to open, where usually it would pop up in well <1 second. This is particularly vexing because Server 2003 performance counters do not show a long period of high load - most stats never even reach above 5%.
When these 16 clients were connecting to a 6 year old DL380 running Linux, we had some slowness, but no delays. We recently transitioned to Active Directory, and upgraded the file server as well. The file server has dual quad core processors, 4X more memory, more disks, faster drives (15K vs. 10K), etc ... so it doesn't seem to make sense that it can no longer handle concurrent processing.
Since we're using Win98, is there some setting that we should change on 2003 to optimize disk read/writes? All file operations are to flat files, and all writes are done by a single user (multiple users cannot access the same database at a time). Any other thoughts on how to track this down ... we haven't had any luck over the past month.
Note: unfortunately we cannot upgrade beyond Win98 for another 2 years, we're waiting for legacy software to be rewritten and this critical software only runs on Win98 due to use of hardware interrupts.
When all else fails, throw a network sniffer at it. Have a look at what's actually happening on the wire while a client computer is waiting, maybe you'll be able to see what's it actually waiting for.
EDIT:
BTW, do you use WINS on your network? This could also be a NetBIOS name resolution problem. Windows 98/NT clients like to use that instead of DNS, and without WINS it will try to resolve names using broadcast queries, which can be a real pain at network peak usage times.
I agree it is most likely SMB signing/authentication and/or Netbios name resolution. Netbios name resolution can be tested w/ NbtStat.
If that proves not to be the case then I would disable OpLocks on the server. Besides corrupting Access files it also seems to cause access issues. I haven't seen disabling it cause a problem but the change can be reversed if it somehow makes things worse.
http://support.microsoft.com/kb/296264 http://support.microsoft.com/kb/296264
Have you tried Server 2003 Performance Advisor? Might help you dig into the problem further.
Can you post any promising events from the Windows 98 clients and the domain controllers?
Furthermore, what is name resolution like on the clients? I would try rebooting to flush the DNS cache (
ipconfig /flushdnsdoes not work in Windows 98) and thenping domain.local. See what you get back, and how long it takes.I had an issue where DNS caused a 30 second delay because there were multiple A entries for the domain controller (it was multihomed, public and private networks).
What ended up happening was the client would first try to connect to the public IP address assigned to the DC. This would fail after 30 seconds and then it would attempt to connect using the private IP addressed assigned to the DC. This would work.
If you want to quickly skip that testing, you could always try \\[server ip]\share\executable.exe and see if it launches quickly.
Are the virtual machines accessing the network via a bridged virtual adapter or via NAT?
We had Active Directory mirrored on this server, and upon removing it the problems disappeared. In such a small environment (25 users), why would this make a difference?