Use Microsoft's Y2K fixes to protect your NT network
Many small businesses aren't taking the Year 2000 (Y2K) problem seriously. Small businesses that do not update software regularly will encounter Y2K problems because of old releases. Three of my consulting clients run a Microsoft solution consisting of Office 97, Windows NT, Windows 95, Exchange Server, and Outlook. Two of the companies also run DOS-based applications critical to daily business operation. They do not realize that the small, vertical-market vendors who write and support DOS-based software are behind the Y2K curve. None of the businesses understand that BIOS chips will cause problems or that four-digit dates will be mandatory by the end of 1999. These businesses are unaware of the information available to help them diagnose Y2K problems and start upgrade planning. (For information about solving the Y2K problem in your organization, see Jane Morrill, "Year 2000 Mission Control, Part 1," September 1998.)
The Problem
The two main problems with the millennium are that the year contains three zeros and the year 2000 is a leap year. Many systems use two-digit date storage and cannot process the year 2000. Most systems do not recognize February 29, 2000, as a valid date. These problems occur in older operating systems (OSs), application software, and BIOS chips.
Your software and scripts must recognize the year 2000 as a leap year to be Y2K compliant. To determine leap years, use the following guidelines. Years that don't end in 00 and are divisible by 4 are leap years. Years that end in 00 are leap years only if they are divisible by 400. Many applications do not test for divisibility by 400 and therefore do not recognize the year 2000 as a leap year or February 29, 2000, as a valid date.
No Easy Answers
The Y2K problem is clearly defined, so you might wonder why it's so difficult to solve. No US or worldwide standards exist for Y2K compliance. Without such guidelines, hardware and software components do not need to pass a standard test to be Y2K certified. Vendors set their own criteria for Y2K compliance. Thus, Y2K-compliant products might not interact. In addition, user modifications to applications (e.g., scripts, macros, custom code) might cause compatibility problems.
Microsoft issued a statement of Y2K compliance on its Y2K Web site (http://www.microsoft.com/year2000). If your company's network runs on a Microsoft platform, this statement will interest you.
A Year 2000-compliant product from Microsoft will not produce errors processing date data in connection with the year change from December 31, 1999, to January 1, 2000, when used with accurate date data in accordance with its documentation and the recommendations and exceptions set forth in the Microsoft Year 2000 Product Guide, provided all other products (e.g., other software, firmware, and hardware) used with it properly exchange date data with the Microsoft product. A Year 2000-compliant product from Microsoft will recognize the Year 2000 as a leap year.
According to this statement, a Microsoft application is Y2K compliant if it recognizes 2000 as a valid leap year and February 29, 2000, as a valid date. In addition, the hardware and software that interact with the application must be Y2K compliant for the application to be considered compliant.
Microsoft has five categories of Y2K compliance: compliant, compliant with minor issues, not compliant, testing yet to be completed, and will not test. A compliant product fully meets Microsoft's compliance standard and might have a compliance patch or service pack. A compliant-with-minor-issues product meets Microsoft's compliance standard, except for minor date problems. A not-compliant product does not meet Microsoft's compliance standard. Microsoft is still evaluating testing yet-to-be-completed products. Microsoft does not plan to evaluate will-not-test products.
Table 1 lists Microsoft products that are Y2K compliant, compliant with minor issues, and not Y2K compliant. For a thorough explanation of compliance problems, review date-handling information by product name in Microsoft's Year 2000 Product Guide (http://www.microsoft.com/ ithome/topics/year2k/product/product.htm).
Table 2 lists common NT products and supported date ranges. Microsoft and other software vendors will need to deal with date problems until at least 2049. If your applications do not use four-digit years, they will not interact with Y2K-compliant products.
Date-handling problems are complex. For example, Exchange Server 5.5 supports a date range of January 1, 1970, to February 5, 2036. Exchange Server's database (which includes the Extensible Storage Engine--ESE--and the JET database engine) uses an internal date range of 1900 to 2156, and the Exchange Information Store (MDB) supports dates from 1601 to 60055. Some Internet standards support only two-digit year dates, so the MDB must perform the correct Y2K conversion (86 to 99 is 1986 to 1999; 00 to 50 is 2000 to 2050) and support a range of 1986 to 2050. The MDB stores certain dates internally as the number of seconds since January 1, 1986, for a range of 1986 to 2085.
To begin tackling the Y2K problem, open the Regional Settings applet in Control Panel. Set your NT servers and workstations to process four-digit years. My system incorrectly added one day to the current date, so verify the date and time when you make this change. (For more information about problems with four-digit dates, see Jane Morrill, "Year 2000 Mission Control, Part 2," October 1998.)
The Y2K problem is not easy to solve. However, you'll be a step ahead if you understand where the problems are. In the remainder of this article, I discuss Y2K problems with NT products.
Prev. page
[1]
2
next page 
