FEATURES

Y2K and Microsoft

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.

NT 4.0 Problems
NT has four currently known Y2K-related problems. First, User Manager does not recognize the date February 29, 2000. User Manager and User Manager for Domains reject this date as invalid. For more information about this problem, see the Microsoft Support Online article "User Manager Does Not Recognize February 2000 As a Leap Year" (http://support.microsoft.com/support/kb/articles/q175/0/93.asp).

Second, Control Panel's Date/Time applet might increase the displayed date by 1 day. The system date is correct, but the displayed date is wrong. Microsoft documented this problem in its Support Online article "After Changing the Time, Windows NT May Skip a Day." This article is no longer available on Microsoft's Web site.

Third, custom date properties assume the year 19xx when you input a two-digit year. For example, the year 01 (2001) appears as 1901. For more information about this problem, see the Microsoft Support Online article "Shell Doc Property Dialog Custom Date Incorrect After Year 2000" (http://support.microsoft.com/ support/kb/articles/q183/1/25.asp).

Fourth, NT's Find Files feature does not recognize years greater than 1999. The Start, Find, Files or Folders, Date Modified tab has two date entry fields that show non-numeric data if you input a year greater than 1999. For more information about this problem, see the Microsoft Support Online article "Find Files Displays Garbled Date If Year Is 2000 or Greater" (http://support.microsoft.com/ support/kb/articles/q183/1/23.asp).

Service Pack 3 (SP3) hotfixes y2kfixi.exe and y2kfixa.exe correct these four problems. You can download the hotfixes from Microsoft's Windows NT Server Web site (http://www.microsoft.com/ntserver). Click Downloads in the left-hand menu, and scroll down to Service Packs and Updates. You can also find these files at ftp://ftp.microsoft.com/ bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/y2k-fix. Service Pack 4 (SP4) includes a hotfix for these problems.

IE 3.x Problems
Internet Explorer (IE) 3.x has two Y2K problems. The first problem involves cookies. If a Web site uses a cookie with a two-digit year of 00, IE recognizes the cookie as expired. Cookies with other two-digit expiration dates or with four-digit dates work correctly. The second IE problem involves HTTP headers. If a Web server communicates a two-digit year of 00 in its HTTP 1.0 header, IE recognizes pages on that site as expired and does not cache them locally. HTTP 1.1 headers containing other two-digit years or containing four-digit years work correctly. Microsoft provides a hotfix for this problem on its Internet Explorer Web site (http://www.microsoft.com/ie). Scroll down to New Patch Readies Internet Explorer 3.02 for Year 2000.

IE 4.0 Problems
IE 4.0 has only one known Y2K problem. Microsoft Wallet does not recognize credit card expiration dates beyond 1999. (Other Web-based products, such as Microsoft Site Server, also use the Wallet.) IE 4.0 Service Pack 1 (SP1) has a hotfix for this problem. You can download the hotfix from Microsoft's Internet Explorer Web site (http://www.microsoft.com/ie). Scroll down to Patch Now Available for First Internet Explorer Service Pack to download SP1 and the latest patch (English version only; other languages available third quarter 1998).

Outlook 97 (8.0x) Problems
Outlook 8.0x uses a two-digit date window that spans from 30 years before the current date to 70 years after the current date. You must obtain the file outllib.dll (version 8.03.4919) to handle two-digit dates that span the century boundary. For more information about this problem, see the Microsoft Support Online article "OL97: Year 2000 Compliance for Outlook 97" (http://support.microsoft.com/ support/kb/articles/q181/3/51.asp). Outlook 98 (version 8.5.5104.6) includes a fix for this problem.

SQL Server 6.5 Problems
SQL Server 6.5 has several Y2K problems. First, the EXPIREDATE clause for DUMP DATABASE does not properly handle dates after 1999. Second, SQL Executive does not recognize 2000 as a leap year. SQL Server 6.5 SP2 fixes this bug. Third, Task Manager's user interface does not recognize 2000 as a leap year. To avoid this problem, execute the stored procedure rather than the user interface to schedule the task. SQL Server 6.5 Service Pack 5 (SP5) fixes these problems.

SMS 1.2 BIOS Problems
Systems Management Server (SMS) physically inventories systems. For SMS to execute properly, the dates that the BIOS sets must be correct. As many as 47 percent of systems shipped in 1997 and 79 percent of all pre-1998 PCs fail the BIOS Y2K test. BIOS clocks have three common Y2K bugs. First, when the clock rolls from 1999 to 2000, the system clock resets to 1980. You can set the system clock to the correct year-2000 date, but the problem will recur in 2100. BIOS clocks might not recognize 2000 as a leap year or February 29, 2000, as a valid date.

Vendors use a variety of motherboards and change components based on price, availability, and functionality. Thus, you might have BIOS problems with only certain machines. To be safe, you need to verify BIOS Y2K date compatibility on every system you support. Many shareware and low-cost utilities are available for this purpose. Hardware vendors sometimes provide inexpensive BIOS updates for their systems.

Protect Yourself
Y2K problems are as important to small businesses as they are to large corporations. Protect yourself now to prevent problems in the millennium. Upgrade your software to Y2K-compliant versions before the end of 1998. If you run software that does not have an upgraded version, call your vendor monthly to find out if and when the company will release a Y2K-compliant version. Test your software for Y2K compliance before you need to reference 2000 as a valid date. Make sure your systems' BIOSs will function properly on January 1, 2000. Finally, check Microsoft's Web site monthly to learn about new Y2K problems.