Slashdot Mirror
Microsoft Recalls Small Business Server
dasButcher writes to tell us VarBusiness is reporting that hot on the heels of many other delays, Microsoft has recalled their Small Business Server 2003 R2. The operating system started shipping to OEMs, distributors, and systems builders in July but was immediately recalled after a recent audit.
The article cites 'non-final code' that was found in the audit. At least they found the error before it went out to the public. It's a bit slim on details but it sounds like no end user organizations are using it yet. So, in a way kudos to MS for finding the problem and addressing it rather than just sitting on their hands and making users download even more patches to replace the 'non-final' code.
For those of us who can't be bothered to RTFA:
"This routine check of the initial software on the manufacturing line found that it contained portions of code deemed "non-final," according to Microsoft... Microsoft plans to swap in the 'final' code, then reissue Small Business Server 2003 R2 to its manufacturing partners,"
Argh.
Read carefully. 3600 units of SBS went out. None went to end users. They were still in the process of building systems around it.
To hell with your case fans. Software can kill, ask anyone who lost a loved one to Therac-25.
Is this another recall, or is Slashdot about three weeks behind in the news?
D efective-Windows-Small-Business-Server-2003-R2-Pro duct-31365.shtml
http://news.softpedia.com/news/Microsoft-Recalls-
--I thought I was wrong once, but I was mistaken.
Actually, it is not all that scary to support. Almost all of my supported sites run SBS2003, and I and they love it. It provides a clean and easy support structure, though it suffers the "dammit" effect that most software suffers in the way of missing or round-about ways of getting to some features.
.Net apps. I would like to add a fourth for handling their specialized apps which require their own SQL engines, to take the load off the main SBS server. In the end, though, what does help is a good disaster plan.
:)
The eggs-in-one-basket thing is inevitable in small business. As has been said before, many small businesses do not have the budget to support multiple boxes and IT/support staff. The wizards in SBS2003 make administration nearly a snap, and the rest of the process can be handled with clever automation. SBS can be the foundation of a multi-server environment -- at one site we have three, the SBS server, a TS server, and a WebServer for
First off, DO NOT RUN A SERVER ON A SINGLE HARD DRIVE. Read that again several times, repeat it, write it on a chalk board a hundred times, spell it out in your Alphabits. Even RAID1 is better than nothing.
Secondly, have a good and reliable backup solution. Tapes are great, and there are several well-priced alternatives which can provide reliability and durability. I prefer tapes, and for large installations an AIT or DLT-V4 drive is great, while smaller installations can handle DAT72.
Secondly-and-a-half, keep an up-to-date ASR tape and floppy on hand! I keep one of these for each customer locked in a fire-resistant and water-resistant media vault.
Thirdly, TEST your backup solution. Build another box, do an install and restore the backup. Make sure your plan works, lest you be caught with your pants down when it counts. VirtualPC, VMWare, etc. are great for this if you do not have extra hardware lying around. You *do* have the Action Pack, right??
Fourthly, have an action plan in place in case one of your clients (or your own site) suffers a catastrophic failure. Be ready to order new equipment, test and restore backups, and spend a day or more on-site getting things back up and running. Fire, frost, or frippery can and do happen.
Fifthly, have recovery software available. I purchased RTools a while back, with FAT, NTFS, and RAID recovery tools. Some people prefer OnTrack or some other tools. I have had great results with RTools. While not the Alpha-Omega of site recovery, such software can prove invaluable in the process. But it early, learn how to use it, and be prepared.
BTW: In reference to the issue of new hardware, REMEMBER MS LICENSING. If you build systems, STAY AWAY FROM OEM SOFTWARE. But it is cheaper, right? Yeah, until your motherboard dies and, technically, so does your OEM licensing. Buying canned systems is not so much of a problem since you can (generally) rely upon the OEM to provide an exact replacement. But if you build your own or order a custom system, things change VERY rapidly, and your favorite Socket AM motherboard may not be available for long after AM2 comes out. (Ran into this problem with a PIV 1.7 rig with the original socket. UGH!)
Attend your local InfraGard general meetings, consider becoming a member. These meetings are often very interesting, especially when they cover topics such as this. You will have a chance to learn from the processes and mistakes of your brethren in the industry. I like to hear tales of state agencies who learned lessons the hard way
In essense, you have to be a tech Boy Scout and always be prepared. I always kinda liked the term "Technology Samurai." I cannot say that I am ready for every possible disaster, but I like to think that at this point I have a good start.
Ok you would be mad to try using a zx81 to run a nuclear power station but consider
a PLC tends to have memory in the 1 - 4k range and racks full of IO cards. If I remember correctly the z80 cpu could address 64k of address's as I/O or memory.
1 bit is all it takes to operate a valve or a motor or read a sensor.
8-16 bits for an analog input or output.
while the ad's seem far fetched in reality the PLC's actually being used will not be that far removed from a ZX81.
for further reading try googling for words like wonderware allen bradley omron SCADA.
simple PLC's run most of the worlds automated processes.
Blarney Quality Restaurant, Plants