If you’re running Windows Server 2003 on Dell machines, you may know (or should) that Service Pack 1 breaks Dell OpenManage 4.3. This also applies to SBS 2003 SP1.
UPDATE: You may have discovered this by now, but when you install OM, Dell will want you to update your RAID controller drivers <i>and</i> the firmware too. It’s normal (and good!) practice for me to update all the drivers and firmware before a service pack, but I never got the notification from Dell about the drivers. Oops.
Windows Software Update Services, the successor to SUS 1.0, has finally shipped! I’ve been using the beta (and release candidate) for several months on my personal server and have been pleased.
One tool that was in the beta release was a notification tool that would email you whenever your WSUS server, or the machine or machines you administer had updates downloaded or applied. If you’ve ever used SUS 1.0, you probably remember the generic emails that MS would send you, only saying "This is a notification from Software Update Services: Content has been changed or removed". Right. Very informative. Or not.
Local notification from your own server is much more useful in an SBS shop since you can get a heads up on patches before they flow to your client machines. (at my shop, we install client patches automatically but servers wait until I can approve them for installation manually during scheduled downtime.)
UPDATE: The tool I was thinking of is still online: Windows Update Services API samples. The copy I downloaded still says "Beta 2" in the readme.
Go to the WSUS Download Site.
MS will update the storage limit of Exchange 2003 Standard to 75 Gigs with the release of SP2. More spam! I just implemented Exchange IMF to keep the mailstore down to a rational size, but this is good nows. (Via Susan Bradley)
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….)