There is no question that much of the effort spent on the year-2000 problem will be spent on legacy business applications. But even something as simple as a file-and-print server is not immune to the problemBetween hardware glitches in PC BIOSes and year-2000 issues in Microsoft's Windows NT, the NT platform is at best worrisome when it comes to year-2000 preparedness.
If you've already tackled the year-2000 bug on your NT network, good for you. If not, it's time to get started. In this Action Plan, we cover the bases you need to bring your NT machines up to par.
What the bandwagon says
Microsoft has stood by Windows NT as being year-2000 ready for quite a while now. First, the company claimed that NT with Service Pack 3 (SP3) was compliant. Then Microsoft released several year-2000 fixes for SP3 as well as Service Pack 4 (SP4), which contained additional year-2000 fixes.
Now, the company has quietly released Service Pack 5, which purports to fix the problems that SP4 caused, as well as also fix some additional year-2000 bugs. What Microsoft is really saying is that it has fixed all of the year-2000 problems found so far, and it has no idea if there will be more, but the problems will probably be fixed if they are found. I would not describe this approach to year-2000 preparedness as direct. But it is really all that Microsoft's customers have to work with.
Hoping to get a straight answer, I pointed my handy Web browser to the Microsoft year-2000 page available at www.microsoft.com/y2k and was greeted by the smiling Mr Bill himself.
Going to the source
Granted, Microsoft's year-2000 information has become, well, more informative, but it still doesn't win any prizes for clear, concise writing. (I know, I know, let he who is without sin cast the first stone . . . ) The site lists year-2000 compliance information for Windows NT 4.0 with each of the major Service Packs: No. 3, 4 and now 5.
The gist of what Microsoft claims is that Windows NT 4.0 with Service Pack 3 is year-2000 compliant, with a few minor exceptions, as long as some post-SP3 updates are applied to the system. Furthermore, Windows NT 4.0 with SP4 is compliant, with some updates, and will be maintained as compliant for a while should future problems arise. Finally, Windows NT 4.0 with SP5 is fully compliant according to what Microsoft currently knows about year-2000 problems in Windows NT. These statements depend upon you updating ancillary Microsoft software to compliant versions.
Testing for bugs
To be fair, after five weeks of our own high-level testing of NT, it has been hard to come up with any significant year-2000 bugs: A typical NT system will work fine after it is booted with the clock set ahead to Jan. 1, 2000. That's not to say that the existing problems shouldn't be fixed -- they tend to have cumulative effects that could, over time, seriously impact the reliability of an NT system.
The problem is that Microsoft can't say with 100 per cent certainty that it has completely explored every nook and cranny in Windows NT and fully eradicated year-2000 issues. At this point, the only valid year-2000 test, unfortunately, is to run NT day in and day out in a production environment after Jan. 1, 2000. Then we'll know once and for all whether or not it is compliant.
Microsoft applies the same logic to Service Pack 4, which you hopefully have not yet installed. Look at the huge list of SP4 bugs fixed in SP5, you will understand why; you can find it on Microsoft's site. The SP4 bug fix list takes up an alarmingly large percentage of the list.
Door No. 3 or door No. 5?
The way I see it at this point, there are two choices: Figure out all of the fixes you need to apply to SP3, then patch it up to buy some time to build your Linux network; or bite the bullet, install SP5, and pray that it's not as bug-ridden as Service Pack 4. If you installed SP4, it looks like you get to do it all over again with Service Pack 5. One look at the list of SP4 bugs fixed in SP5 should tell you why.
Assuming that you haven't yet installed SP4, the choice you make depends largely on what you are doing with your NT servers. If you use them mainly for file-and-print services, and therefore don't have a ton of applications dependent on the NT operating system, you can probably go the SP5 route somewhat painlessly.
My machine is a basic file-and-print server, so I decided to go the SP5 route. SP5 weighs in at 33MB, so you probably won't be downloading it over your dial-up connection. Also, it doesn't require any previous Service Packs, which is nice.
SP5 has prerequisites that must be met in order to be year-2000 compliant, according to Microsoft. These include updates to several ancillary Microsoft products, such as Internet Explorer, Active Directory Services, Data Access Components, and FrontPage 97. Microsoft's Web site provides a thorough list of the updates you need to make for any of the Service Packs to be compliant.
The list of updates and fixes in SP5 is extensive, so make sure you review it for compatibility with any third-party software you may have installed on your NT servers. One noteworthy update in SP5 is euro currency compatibility, which is a nice update for folks facing that issue in addition to year-2000 issues.
If you go the SP3-plus-updates route, you will follow a similar process, although you may have to apply several smaller updates as well. Again, the steps to follow are identified in the year-2000 information for SP3 in Microsoft's Resource Centre.
If you run tons of third-party applications on your systems, you might want to step through the post-SP3 updates carefully to make sure that you don't break anything else by creating, for example, a conflict between a third-party application and a DLL updated by the Service Pack.
Users complicate things
Once this is complete, you are not out of the woods yet. You still have to worry about year-2000 compatibility in your third-party applications and in any end-user data, such as spreadsheets, residing on your NT system.
For third-party applications, a visit to the vendor's Web site is a great starting point for looking at year-2000 issues in its software.
SP3 and post-SP3 fixes
¥ User Manager and User Manager for Domains do not recognise 2000 as a leap year¥ Leap-year issues in Date/Time Control Panel¥ Date/Time Control Panel applet displayed date may jump ahead one day¥ Find Files displays date incorrectly after 1999¥ Document property window displays date incorrectly in custom fields¥ Custom dates with "00"do not work in Office document properties¥ Logout.exe program in file-and-print services for NetWare reports dates incorrectly after 1999¥ NT client displays print queue dates incorrectly for queues on non-NT systems¥ NetWare migration Y2K issues¥ Y2K issues when DOS-based NetWare client attempts to connect to NT server running file-and-print services for NetWare¥ PS1-compatible machines will not boot after 1999¥ Restore log date issues in NTBackupRemaining issues¥ Windows Internet Naming Service/Dynamic Host Configuration Protocol (WINS/DHCP) Admin date issues¥ Custom date problems under certain circumstances with Word for Office 97¥ BIOS date value does not immediately update on Jan. 1, 2000¥ OLE Automation issues for users of English version¥ COleDateTime function issues in mfc40.dll¥ Four-digit year format issues for non-English regional settings¥ MSMQ date issuesSP4 fixes¥ Problems in SP3 and post-SP3 fixes¥ WINS/DHCP Admin date issues¥ The Date/Time Control Panel applet can update the system clock; was not listed as SP3 issueRemaining issues¥ BIOS date value does not immediately update on Jan. 1, 2000¥ COleDateTime function issues in mfc40.dll; fixed by post-SP4 update¥ MSMQ date issues; fixed by post-SP4 update¥ Internet Information Server 4.0 HTML Administrator date issues; fixed by post-SP4 updateSP5 fixes¥ Problems in SP3 and post-SP3 fixes¥ Problems in SP4 and post-SP4¥ BIOS date value does not immediately update on Jan. 1, 2000Remaining issues¥ None currently identified; check individual product listings