I own what may be the world's slowest SBS machine.  At home, I have a white-box machine from my workplace with a defective motherboard (Biostar, what a surprise!) that was gutted and filled with another old motherboard that came from the curb (literally!).  (The Biostar board used to be in a server.  Don't ask.) 

I used this to run Debian for awhile and it was my "test" machine.  Now it runs Small Business Server 2003.  Sort of.

The minimal requirements for SBS 2003 (at http://www.microsoft.com/Windowsserver2003/sbs/evaluation/sysreqs/default.mspx) cite a 300 MHz processor, 256 MB of RAM and 5 gigs of free HD space.  Microsoft's recommended specs--which are the true minimum requirements--cite a 550 MHz processor (AMD or Intel) and 512 MB RAM.

My server has a 266 MHz PII and 256 MB of RAM and about 17 GBfree out of a 27 GB hard drive (at 5400 RPM.) 

To my surprise, the server's been very stable, if very slow;  it got slower yet when I installed Service Pack 1 for SBS 2003.  I reinstalled from scratch (needed to do that anyway as it was still sharing space with my old broken Debian install), reapplied SP1 and defragged.  Still slow.

(BTW, I recommend a defrag and a disk cleanup after installing the service pack, after, of course, verifying that the install is OK.  I'd never seen a disk so fragmented.)

I found something interesting running Process Explorer (www.sysinternals.com):  wspsrv, the ISA 2004 firewall service, was spiking my CPU at 100% at 5 second intervals. 

One would think that my server is the victim of a DDoS or that I accidentally opened up relaying on Exchange (both of which I have had sad experience with), but the machine is behind a SOHO router with nothing whatsoever being forwarded to it.  It can get updates from MS, DNS, NTP time syncs and incoming HTTP but that's it.  The viruses go to my workstation. 

Further investigation with Filemon (another Sysinternals tool) reveals that wspsrv is loading msfpccom.dll and reloading it at about 5 second intervals.

According to a quick Google search, msfpccom.dll is used to provide scripting support for ISA, but there seems to be no obvious reason why ISA would need to reload this DLL over and over or even if it is a cause rather than a symptom of some other problem.

I think it's a low memory condition.  Remember that SBS also runs Exchange, SQL Server and MSDE (the desktop SQL), all of which contend for memory aggressively under normal circumstances.  One would think this DLL would remain in the system cache.  Or not. 

(I'm not sure how I can determine if that DLL access is backed by the system cache or read in directly from the disk and my system may be too heavily loaded for me to find this out.)

I'm ordering new RAM, a motherboard and CPU.  If nothing else, it's driving me nuts to have to make a cup of coffee while my terminal session logs in.  Stay tuned.

UPDATE:  My server has the new motherboard:  Sempron-based 1.8GHz and 512M RAM.  After getting SBS 2003 SP1 on the new system, I conclude that the technical reason why my old system was slow:  It was junk!  And ISA 2004 should NOT run on 256 Megs.  (I really need a gig of ram on my server, but that's another purchase....)