How bad is the NT problem?

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

Is there anyone who can help put these two articles into perspective. How many users and companies will be affected by serious NT bugs? How many so-called mission-critical systems will be affected? I'm afraid I don't even know what a Terminal Server is, PNG, or how important it is to a function NT system.

I'm assuming that its too late for Microsoft to fix these problems. No one in their right mind is going to trust that Microsoft is going to come up with a last minute fix that does NOT need at least six more months of testing.

http://www.pbs.org/cringely/pulpit/pulpit19990311.html

by Robert X. Cringely

The current version of NT is 4.0. In order to make changes and improvements in the current product, Microsoft gives out for free what it (and IBM before it) calls Service Packs. These are bug fixes and feature upgrades. The most stable version of NT available right now is version 4.0 using Service Pack 3 (SP3). Unfortunately, SP3 is not in itself Y2K compliant despite Microsoft's past claims to the contrary. The company has since shipped additional hotfixes (fixes to the Service Pack) that make SP3 sort of Y2K-ready. But sort of isn't good enough, and even Microsoft has recognized that by issuing a new Service Pack specifically for Y2K -- SP4. That's the good news. The bad news is that SP4 is buggy and there are now so many hotfixes to it that Microsoft is preparing SP5.

Now pretend you are in charge of computers for some big company. This is March. Y2K is looming. In order to be ready for the end of the year, the smart thing to do is "freeze" all software by June 30. This means Microsoft is almost out of runway. If there is not a 100 percent complete and reliable Y2K fix for Windows NT real soon, things will get ugly.

Is anyone in Redmond on top of this? Not that I can see. The Microsoft spokesman in Melbourne said the answer was Windows 2000, but he couldn't say Windows 2000 would ship by June 30, nor would he guarantee it would ship without bugs.

Here's a dose of reality. Windows 2000 is a HUGE technology change. For a moderate to large shop it will take at least six months of planning, design and testing before they could even consider deployment. A very important aspect to the migration is to clean up and simplify the present NT 3/4 operation. If you've let your shop evolve out of control into a chaotic mess, you've got to fix it first. Yet what we know so far is that the last stable version of NT isn't Y2K-ready, the version that is supposed to be Y2K ready isn't reliable, and Microsoft's answer is to shift your entire system to a new OS that probably won't be reliable, either.

http://www2.gol.com/users/png/index.html

by PNG.

"Microsoft's NT Terminal Server Edition (TSE) is under fire yet again after the company admitted the product is still not Year 2000 compliant, despite having already issued a Y2K patch TSE, which has faced a barrage of criticism from both analysts and users for its high licensing costs, was released non compliant in mid 1998.

Microsoft promised Year 2000 fixes first in September

and then December, neither of which were delivered..."

"...According to industry analysts Gartner Group, Microsoft 'quietly' posted a set of Year 2000 hot fixes for TSE in January this year, but has now admitted these are inadequate."

-- Goatherd (goatherd@baa.com), March 15, 1999

Answers

The simple, straight forward answer to your question is "it depends".

PNG is essentially correct. Windows 2000 is simply not an option for most companies at this point in time given Microsoft's notoriously buggy software releases. (a favorite adaptation of the old quote around our shop is "The service pack's not done until all your applications won't run.")

Also, Microsoft's recent shift to requiring SP4 for NT for "Y2K readiness" is a hit on some of those organizations that thought they were compliant with NT + SP3 + Hotfixes. Our own tests with SP4 revealed it to be incompatible with some of our apps. As a result, it is on hold at our shop until ... (new application code is released, new drivers are released, new APIs are release, workarounds are found, Microsoft issues a hot fix, vendors quit pointing fingers at each other, SP5 comes out, or we decide to go totally Linux)

There are two issues that stick out. First, the most important issue here for the technical staff lies in understanding the precise nature of the remaining Y2K bugs in NT4 + SP3 + Hotfixes (or SP4 if that's they way you're going). Many bugs are inconsequential or apply to aspects of the operating system which your particular installation may not use (or even have installed). For example, only a tiny fraction of NT installation are using Terminal Server (TSE). Of course this is not much consolation if your site happens to be one that is. In many, but not all cases, the known bugs can be either ignored or worked around. Which brings us to issue #2 and the real Achilles heel of the entire Y2K mess --- testing.

NT is very large and very complex. It has hundreds of components, many of which are optional. It behaves very differently based on a multitude of cutomizable settings. In short, nearly every installation of NT is unique in some aspects. This makes testing your own configuration of NT essential.

Unless you have done thorough testing of your specific configuration of NT with the applications you normally run, you must either accept that Microsoft knows and discloses the full extent of all Y2K-related deficiencies in NT or that you will be able to sucessfully fix on failure. Both of these strategies are part of what got us here in the first place.

Unfortunately, I see far too many people relying on statements of compliancy from vendors rather than dedicating the resources required to truly test their 'mission-critical' systems.

To Microsoft's credit, they have acknowledged and publically posted a great deal of what they do know about NT's Y2K issues. This information can be used by motivated sites to determine which of the known issues are insignificant, which can be worked around, and which are show stoppers (assessment).

But in the end, only rigorous testing of your own specific installation should give you a high degree of confidence. ("This operating system is fully protected by a false sense of security!") And unfortunately, this type of testing is only performed in the most motivated of organizations. The average organization is either unwilling or unable to dedicate such resources. (Sure, you can test -- just don't let it interfere with marketing deadlines.)

-- Arnie Rimmer (Arnie_Rimmer@usa.net), March 16, 1999.


I can think of one company that's probably having kittens over NT4's Y2K bugs. They shifted their entire product line's embedded processors from OS2 over to Windows NT4, for Y2K reasons and to meet customer demands. Now their new software platform isn't ready for Y2K and they've got to scramble.

Glad I'm not still working there. They've got over two thousand systems fielded worldwise that they've got to upgrade with new CPUs and new software. And now they've got to integrate even more new software without their usual integration and test period.

I see some field service folks earning more frequent flyer miles than they can use, with or without Y2K.

WW

-- Wildweasel (vtmldm@epix.net), March 16, 1999.


I've been reading Robert Cringely for years, and he is usually right on the money, IMHO.

Linux or Netware. Novell has done a great job getting ALL versions of their network OS Y2K compliant. Also blows the doors off NT performance wise. If you're thinking of switching, do it quickly. <:)=

-- Sysman (y2kboard@yahoo.com), March 16, 1999.


Been there, done that :-)

Installed SP 4, and some third-party web apps wouldn't work. When I called the vendor, they couldn't guarantee a release date for the patch. So, do a have a "compliant server" with angry users not able to use their apps, or keep the users happy and not be compliant? SHEESH.

-- Faze the Nation (dazed@confused.com), March 16, 1999.


My "handle" says it all.

-- vbProg (vbProg@MicrosoftAndIntelSuck.com), March 18, 1999.


Moderation questions? read the FAQ