The evil and traumatic side of Windows NT
July 15, 1999
Web posted at: 10:47 a.m. EDT (1447 GMT)
by JOHN FONTANA
From...
(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.
Screaming IP
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. |
