Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
1  
"we're waiting for legacy software to be rewritten and this critical software only runs on Win98 due to use of hardware interrupts" -> isn't this a case for virtualisation? –  ta.speot.is Feb 6 '10 at 5:37
1  
The 98 PCs are actually running as virtual machines from XP or Vista desktops. But the software still only runs from 98 unfortunately. –  Jess Feb 6 '10 at 5:40
    
Your previous server was running Linux - do you have any details on the Samba config that you were using on that? –  Helvick Feb 6 '10 at 10:51
    
Not at the moment - we simply used the standard config file and modified it to use WinBind and our old NT 4 PDC. No further modifications were made. –  Jess Feb 6 '10 at 23:07
add comment

5 Answers

up vote 3 down vote accepted
+100

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.

share|improve this answer
1  
I'd venture a guess it's something SMB Authentication related, and the sniffer will turn this up. The linux box would have had much more lenient authentication requirement than an AD member server. This would probably be turned up by WireShark (or similar). –  Chris S Feb 22 '10 at 20:56
    
Chris/Massimo - great thoughts! It actually was a pain getting our win98 sessions to authenticate against 2k3, so this is a possibility. Any recommendations or links on how to research this further? –  Jess Feb 22 '10 at 21:14
1  
For sniffers: WireShark. It's just the best one around. For SMB authentication when old client systems are involved: support.microsoft.com/kb/555038. –  Massimo Feb 23 '10 at 6:50
    
We didn't use WINS originally, but added it a few months ago. –  Jess Feb 23 '10 at 15:37
add comment

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?

share|improve this answer
add comment

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

share|improve this answer
    
Interesting, OpLocks could definitely be a contributing factor given we use an old DOS-based database. –  Jess Feb 23 '10 at 23:58
add comment

Have you tried Server 2003 Performance Advisor? Might help you dig into the problem further.

share|improve this answer
    
I hadn't hear of that, I'll give it a try. –  Jess Feb 6 '10 at 7:47
    
Nothing eye opening. We have been running it every 10 minutes from 1:30-2:30 (when our system has the most problems), and it always shows relatively low IOPS(~30), and never has max read/write bytes/sec above ~1MB. –  Jess Feb 22 '10 at 20:19
add comment

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 /flushdns does not work in Windows 98) and then ping 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?

share|improve this answer
    
Thanks for the ideas. I'm not sure what you mean by "promising events" though. There are no warning or error events popping up in the event view occurring when we have these issues. Also, rebooting does not seem to help, this issue only happens during times of heavier use (from ~1:30-2:30 pm), and pinging the domain is instantaneous even then. The VMs are accessing the network via a bridged virtual adapter. –  Jess Feb 6 '10 at 5:54
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.