Can you name me a software company that is responsive, and quickly resolves integration and application errors?
Well, yes that is a good point. One rarely gets this kind of responsiveness except from authors of free software.
Nevertheless, the problems within Windows are frequently of a different sort than one encounters elsewhere. In many cases the problems only occur because of Microsoft's paranoid coding and packaging practices.
For example, did you know that it was impossible to upgrade the hardware on a server runing Microsoft Systems Management Server? One of our analysts spent about three months working with Microsoft's technical support (we have a Priority Comprehensive contract) attempting to upgrade SMS 1.1 that was running under Windows NT 3.51 and SQL Server 6.0 on a uniprocessor Pentium 90 to SMS 1.2 under NT 4.0 and SQL Server 6.5 on a dual-processor (430HX) Pentium 166. After months of the runaround ("Follow this procedure", "Maybe this will work", "The engineers said to try this other thing"), Microsoft finally abandoned the charade and admited that it was not possible to do this. The core problem is the Windows NT SID, and the fact that SMS stores the SID inside the SMS database. SMS will not run if reloaded to a system with a different SID. Even if you decide to violate Microsoft's decree that thou shalt not clone Windows NT, the difference between the uniprocessor and multiprocessor HALs kind of shoots that plan all to hell.
Thus, to do this, we had to scrub our entire network of all vestiges of the previous implementation of SMS (including, for example, c:\sms.ini from every workstation in the network) and start again from scratch. Microsoft got so carried away with their paranoid copy-protection schemes that that even their top-level support people couldn't fix the problem.
How many problems are only resolvable by editing the registry? And, you know all those knowledge base articles that tell you how to edit the registry to fix this or that? What do they say, right after the problem description and just before the solution? Right: "Edit the registry at your own risk". Microsoft won't support you after you've edited the registry. Try asking their tech support people a question about editing the registry -- they won't respond to it. If you can't fix a problem without doing something that will cause Microsoft to abandon you to your system, how can NT be viewed as "supportable"?
A few weeks ago I had a hard drive go bad on an NT 4.0 Server that was running SP3. It was the second hard drive, which just had my home directory it; the C: drive was fine. NT wound up being very confused, so I did what Microsoft almost always says to do: I re-installed, which of course took me back to the original release, with no service packs. I then applied SP5/128 (since that was something that needed doing anyway), and IE 5.0. Everything was fine until the reboot after installing IE 5.0. At that point, I got the vile "NTDETECT ERROR" at boot. I spent a while trying to fix this; I built a custom boot floppy, replaced the NTDETECT exectutable, and so on. But the whole thing was just hopelessly confused, and in the end I just wiped the disk and started over again with a fresh install.
The observation that I'd make here is that no other operating system I've ever used (and I've used many) would die in such an obscure fashion. On a Solaris, Linux and even a DOS system you can usually rebuild the boot drive bit by bit. With Windows NT, such reconstruction is usually not an option. Microsoft doesn't even give you any way, other than Windows Setup, to reinstall the boot loader on the C: drive.
I am unaware of a single Windows NT sysadmin who thinks that the way that the whole NT install and boot system works is good. People just put up with it, and Microsoft refuses to change it no matter how many of their customers don't like it.
--Bob |
