Awareness
The scariest statement I've heard lately is, "We're running Windows NT; we don't have a problem." Such unwarranted optimism can cost you in lost business, angry customers, and potentially disastrous lawsuits. It can also bring your business to a grinding halt at 12 a.m. on January 1, 2000.
Is NT safe from the Y2K bug? Simply put--no. It's true that Microsoft designed NT with a built-in 4-digit date field, and primary vendors are busy releasing Y2K-compliant software updates and hardware. It's also true that NT, unconnected to other systems or networks; running on current, standard, brand-name equipment; and using only current, standard, brand-name applications, might be safe. However, the perfect NT scenario fits almost no one.
Nearly every business has cloned equipment, custom applications, modified applications, homegrown utilities, or old hardware; software that's one or more releases behind the current version; legacy systems from the 1970s and 1980s; heterogeneous networks with various switches, routers, or hubs; or business (and network) connections to some other company that does. NT won't protect you from problems on a system whose hardware or firmware can't handle century digits, it won't protect you from 2-digit year field problems on legacy systems you connect to, and it won't protect you from Y2K problems coming from other systems you connect to.
Inventory
To get a true picture of the extent of your Y2K problem, you need to take a detailed inventory of your hardware and software, including shrink-wrapped applications, proprietary utilities, and major systems. Most of the major NT systems management packages, including Microsoft's Systems Management Server (SMS), Tivoli Systems' Tivoli Enterprise, and HP's OpenView, inventory hardware and software. Computer Associates' Unicenter TNG inventories only software.
To inventory hardware, you need to know brand name, processor type and speed, internal and external peripherals and their attributes (such as brand, size, and speed), and licensing dates. You must track down and list network connections for every piece of computer hardware your company uses, whether you own, lease, or borrow that hardware. If some of your employees use their personal computers to interface with your system, you must also list those systems.
If you don't have a hardware inventory package, BindView's NETinventory inventories your hardware to the level of detail you specify. NETinventory can tell you everything you ever wanted to know about the nodes on your network--from machine, processor, and bus type to physical disk configuration and partition information, to BIOS information and Ethernet card manufacturer and configuration. If you can think of something you'd like to know about your hardware, NETinventory can probably give you that information.
To inventory software, you must know version numbers, licensing dates, expiration dates, and which PC is running which version of which product. You need to know which systems are running mission-critical applications and which systems contain inhouse utilities. You also need to know who made the most recent changes to your software and when--whether these changes were vendor patches or inhouse fixes.
You can use NETinventory for software inventory, too. It provides statistics such as product name, vendor name, version number, category, number of copies of the product, and serial numbers. NETinventory also reports on mystery software packages and tells you where they are so you can identify them. Some software packages call themselves inventory solutions when what they do is list where in a particular program certain date problems exist--these packages don't identify programs and program characteristics. Such solutions can be useful for assessment, but they aren't thorough enough for adequate inventorying.
Assessment
Now that you know exactly what your company hardware, software, and networks comprise (including all interfaces you have with other systems and networks, such as EDI handoffs or software upgrade interfaces), you must determine the extent of each component's exposure to the Millennium Bug. Take your hardware and software inventories in hand and prepare to check every item on those lists.
Testing hardware. Many systems administrators automatically react to Y2K as if it's a software problem that adjusting a few date fields and perhaps making a few calculations will take care of. However, on January 1, 2000, PCs or network hubs or disk drives could fail. The root causes of such hardware failures might be licenses that expire, a chip that equates the year 00 with the chip's origin date, an improperly cycled CMOS realtime clock (RTC) date, or incompatibilities between the system and BIOS dates. (Keep in mind that BIOS's in computers bought at the same time from the same manufacturer can handle dates differently.)
Begin the hardware testing process by checking the license expiration dates on all hardware and software agreements your company has. If any licenses expire before 2000, you must update them or replace the affected hardware or software with an updated version, because cycling the clock ahead to 2000 in the following tests I describe can take your system past any license expiration dates and bring it down. If your system is dead, you can't reset the date and restore from backup, so be sure to take a complete system backup before you test. Finally, if a system exhibits strange behavior during testing, set the date back to the current date before you reboot.
Two tests are available for use on your PCs to check the RTC (for step-by-step directions for conducting these tests, see the sidebar "Check the RTC," on page 129). The first test determines whether the clock will cycle properly to January 1, 2000, and the second test determines whether you can set the clock to 2000. Many PCs won't pass either test, because their CMOS century digits don't cycle properly.
Prev. page
1
[2]
3
next page 
