The evil and traumatic side of Windows NT
(IDG) -- For IT professionals, there can be no ignoring the things that go bump in the night. And for those running Windows NT networks, there can be no ignoring the fact that their nights have been haunted by some particularly worrisome bumps.
In a recent forum on Network World Fusion, readers were asked to share their worst NT nightmares.
While some users report having had few or no problems with the often-maligned operating system, many others have nightmare stories that make them want to sleep by the lights of a brightly glowing Unix box. Some users, for example, report the mysterious disappearance of network resources or IP connections. Others relate scary episodes with Service Pack 2 and NT networking.
As the list grew long, one contributor felt compelled to keep a running tab of definitions for NT. The list included: Nice Try, Neat Toy, Not Today, Nearly There, Next Time (maybe), Nothing but Trouble, and NoT.
The conclusion? NT often resembles a string of Christmas lights stuffed into a shoe box - a knot with bright end points that requires a magician to unravel.
Microsoft has heard the complaints, no doubt. And with Windows 2000 - which Microsoft CEO Bill Gates calls the company's most important operating system ever - due to ship by year-end, the motivation for quelling users' discontent could not be more intense. But before that day arrives and fosters its own tales of NT good or evil, we thought it worth relaying some of the horror stories that have haunted current users.
Calling all subnets
Taed Nelson, network engineer for Vertical Networks in Sunnyvale, Calif., says NT taunted him for more than six months with a problem in Network Neighborhood, the network access mechanism in Windows. Blocks of subnets would randomly drop off Nelson's network. When the subnets disappeared, the servers on those subnets were unavailable to end users, effectively shutting down parts of his network. Even more perplexing was the mysterious reappearance of the subnets. For months, Nelson tracked the problem.
"The especially annoying part was that once people would report [the problem] and I would go to track it down, it would disappear before I got there," he says.
As frustrating as it was to have machines disappear, Nelson found it equally frustrating that he could ping the disappearing machines and see that they were actually healthy. He could also see other machines from the machines that had disappeared.
Nelson determined it was a routing problem associated with his use of Microsoft's Routing and Remote Access Service (RRAS), which allows an NT server to function as a router. He called Microsoft, but could not get the problem solved.
Eventually he turned to a tool in the NT resource kit called Browser Monitor, which revealed a pattern of the disappearing subnets. The problem was the master browser - the machine in a subnet randomly selected every 12 minutes to inventory the IP addresses and names of the other machines on the subnet.
When the master browser duty was assigned to the RRAS machine, the subnets would disappear. So Nelson turned off the browser service on the RRAS machine and his problem was solved.
To add to his frustration, however, Microsoft two months later issued an alert to the problem, an alert that came eight months late for Nelson.
Service Pack attack
A number of readers pointed to NT 4.0 Service Pack 2 as the source of many headaches. Administrator Michael Lane, who preferred not to name his company, related this story in our Fusion Forum.
One day, with an hour to kill before he left work, Lane says he decided to install Service Pack 2.
Unbeknownst at the time, Service Pack 2 had a bug that corrupted files. In fact, Service Pack 2 contained a rash of bugs that plagued NT systems. Although the bugs were eventually fixed in Service Pack 3, it wasn't soon enough for Lane.
After installing the software and rebooting, he got the nightmare of his life: the dreaded "blue screen of death." With no other options, Lane had to completely reinstall NT and re-create user accounts, shares, and permissions, because the small network he maintained had no backup at the time. He finally restored everything - 15 hours after he was supposed to have gone home.
It ain't all bad
Dennis Schiel is the chief technologist for Delta Corporate Services in Parsippany, N.J., a company that works with a number of large corporations. For his customers, NT is a sweet dream.
"If an NT server blue screens once a year, that should be a high number," he says. Schiel blames blue screens on one of three things: defective or questionable hardware, poorly written device drivers or a rare NT server code bug.
Schiel says most of the nightmares associated with NT are not about the operating system, but rather the Intel architecture.
"Intel architectures are not the most reliable hardware architectures around,"he says. "People were screaming at IBM that OS/2 was causing their systems to crash. It wasn't so much OS/2; it was the fact that you had to be very rigorous in specing out the [Intel] hardware it ran on and making sure everything was compatible.
"It's not just individually NT, or any operating system you choose, but all the parts working together," he adds.
But Schiel isn't crazy enough to say hardware is the root of all network problems. He did note some flaws and errors with NT, most notably NT 4.0 Service Pack 2. He says the Windows Internet Name Service (WINS) is another area in which users have had trouble.
"WINS is something that even the most diehard Microsoft person will tell you is a service that you have to be extremely careful with," Schiel says. "The problem is that WINS is not as scalable as some of the network people are trying to make it [out to be]. It is a problem in large networks."
Unfortunately, it is nearly impossible to network Windows machines without WINS.
But Schiel says he wouldn't call these examples nightmares. He says every operating system has its bumps, and those bumps - like WINS - are the things IT departments should spend the most time smoothing out.
"You will get different bumps if you try to deploy Linux in 400 locations," he says.
Can't WINS for losing
For Shell Services Inter-national in Houston, creating a WINS infrastructure on Microsoft's recommendation was the start of a two-and-a-half-year nightmare. Mark Adams, NT security specialist for the company, and Steve Nguyen, NT engineer consultant, began the ordeal with daily doses of trouble.
After expanding their architecture to nearly 70 WINS servers supporting 100,000 desktops around the world, users began to have trouble signing on to the network one day, but not the next. They would find resources one day, but not the next.
"The WINS infrastructure requires you to set up a replication hub between re-mote locations so it can exchange the database of resources," Ngu-yen says. "It replicates user IDs, domain names, resources that you share. For us, that replication mechanism does not work properly, so stuff never gets replicated and users don't have the resources they need."
For nearly eight months, users would call every day unable to even sign on. Or if they could, key resources would be missing. Each episode would take between 15 minutes and an hour to correct.
"We spent thousands of man hours tracking down the problem," Adams says. Microsoft came on-site more than 10 times to help fix the situation. Eventually, Microsoft engineers completely redesigned the WINS architecture, but that only reduced the problem from a daily one to a weekly one.
"We have to maintain WINS daily," Nguyen says. "And we have to check the database every other week and force replication instead of having it automated."
At times, Nguyen and Adams have to manually import databases to faltering WINS systems.
Nguyen is keeping his fingers crossed that Windows 2000 will solve the problem, but his current Windows desktops will still need WINS to talk to Windows 2000 servers.
When asked if he would scrap WINS, which is at the core of Windows networking, or limp along with his current problems, Nguyen laughs and says, "Do I have another choice?"
He may need to consult the U.S. Department of Justice for clarification on that question.
Nothing brings howls of complaints from end users faster than downed e-mail, and for Patricia Leeb-Hart, the howls came often. Currently the system administrator for a Fortune 500 company, Leeb-Hart's NT nightmare came in her previous job, where NT running Exchange Server caused e-mail service to be interrupted on a daily basis.
It was bad enough trying to fix the problem, but trying to do it with an e-mail starved, "Night of the Living Dead" mob outside her door was another matter.
Leeb-Hart's NT server maintained an IP connection with a Unix box she used as an SMTP gateway. But for no apparent reason, NT would drop the IP connection daily. While the connection was down, e-mail could not flow into or out of the company.
"I spent hours on the phone with Microsoft tech support, and it was never resolved," she says. Leeb-Hart came in to work early and stayed late in her attempt to solve the problem. She wiped the NT machine clean, reinstalled Exchange and restored all the mailboxes - but to no avail.
Finally, the company's Unix guru devised a script that would page him when the IP connection was dropped. He would relay the information to Leeb-Hart, who would then go down the hall and reboot the machine.
Leeb-Hart left that job without solving the problem. Now she maintains a Novell server running GroupWise, which has been up for about 200 days straight since she last took it down to install new software. But she does have three NT boxes in her NetWare infrastructure. One of those boxes, which functions as a backup domain controller, has a memory leak the firm has been unable to repair. Every six weeks or so, Leeb-Hart gets a call and has to go down the hall and reboot the machine.
For Leeb-Hart, it reeks of old, nightmarish times.
New and improved Back Orifice targets Windows NT
RELATED IDG.net STORIES:
LinuxWorld Expo and its attendees have a lot to say -- about Windows NT
Windows NT Server
|Back to the top||
© 2001 Cable News Network. All Rights Reserved.|
Terms under which this service is provided to you.
Read our privacy guidelines.