I could easily turn this into a bit of specialized material for Jeff Foxworthy
but, somehow, I don't think the staying power is there for a stand-up routine.
No, this article is meant to spark the imagination a bit, to help fill in the
blanks when you find yourself asking what the Unix guys are all upset about
when they see a Windows server coming into the shop. This first article will
form the basis of a regular column in which we'll explore and grow your administrative
toolbox with reasonable approaches to solving common problems in Windows servers.
In order to qualify the complaints your Unix peers make, you need to be able
to tell the serious contenders from the mouthpieces. Platform arguments are
often filled with comments that in conversations about people would not be tolerated.
The flavor of commentary is distinctly bigoted in taste. And, similar to social
commentary, large, generalized assumptions abound. How is an innocent NT/2000
administrator supposed to tell who has the real low-down without dipping his
or her toes deeply into the Unix/Linux world? After all, attempting to deal
with complex, service oriented systems is very much like attempting to sip from
a firehose; a dip into the Solaris world isn't a very practical idea without
making a firm commitment to learning the system.
So, to help you sort the complaints of the knowledgeable from the <AOL>Me
too!</AOL> crowd, here are a few valid points that you may hear…and,
in some later articles, a couple hints for things you can do to make your NT
based systems measure up (almost?) to the expectations of the masters of Unix.
- Windows machines are not secure out of the box
- Windows systems do not have the same reliability as Unix boxes
- Windows systems are 'shallow' systems
- I can't remotely manage a Windows system
- Windows NT administrators are not competent at Mission Essential systems
You'll notice that one of those complaints is directed at the people running
the systems, not the systems themselves. It's a pointed and, generally, accurate
comment with a simple cure. Education is the only remedy and continuing to shelve
your irritation with this article may be your first step in making that comment
as untrue as any racial slur you've ever heard. The next step is to find an
open minded individual who isn't phased by the idea of spending a little time
giving you an up close examination of true Mission Essential requirements and
the systems that meet the definition (and, no, Siebel is NOT a good example
of a Mission Essential design).
When you're exploring these comments from those Unix admins, bear in mind that
they've got some experience in their own environments that taught them about
essential services the hard way. Most have run SendMail (for SMTP mail delivery
system) or BIND (for Domain Name Services) at one time or another and have probably
been stung at least once by flakey behavior or security exploits made possible
by these two representative, essential services. These folks have been taught
in what Benjamin Franklin referred to as a "…dear school."
Just like the ignorance we all came to the computing profession with, security
out of the box for a Windows system is, at worst, a temporary condition over
which you have an amazing amount of control. No, you'll never achieve the 100%
secure benchmark with any system unless you yank the Ethernet cable from the
back. But, you can easily reach the magic 80% protection level in just a few
basic steps. That leaves you plenty of time to work on the next 20% of the possible
exploits a percent at a time. And, of course, we can all invade that last area
of exposure by continuing to lean on Microsoft to adhere to some secure coding
standards at the most basic of levels (there really is no excuse for buffer
overflows with the options offered through most C++ compilers to prevent these
kinds of failures). I highly recommend to any Windows Administrator an afternoon
or two spent at http://www.microsoft.com/security. There are so many free tools,
checklists, and pieces of valuable configuration advice available there. When
you're done exercising your systems with the information at that site, you still
won't be a qualified security analyst, but you will have achieved a level of
security that the Unix folks will respect.
Reliability is a strange conversation to have when it comes to computers. We
tend to work this problem anecdotally and only produce data to protect our claims
of experience. That's normal, but not very scientific. I can tell that, in general,
Windows systems that fail (requiring frequent reboots) are victims of poor configuration,
performance tuning or poor quality services software. That last piece is a vital
consideration, as not all developers and not all programs, resultantly, are created
equal. In a later article, we'll talk about the required disciplines, both actions
and thought, required to maintain system integrity and reliability…despite
the best efforts of your development staff.
Now, what the heck are these folks talking about when they say that Windows
systems are shallow? Try this picture on for size. It should help you understand
more easily.
In the Windows environment, the majority of design attention has been given
to developing a standardized interface with few alternatives (for consistency)
in which to present a series of jobs and functions in a linear fashion. Creating
automated functions to do the jobs you need done on a Windows system is generally
not possible unless you also install some other tool for automation. Attempting
to use the command prompt for this purpose is, also, very frustrating because
there is little depth to this shell!!
A shell is nothing other than an operating environment. Unix admins typically
have a wide choice of shells from which to work. Take a look at a Linux distribution
once. There are graphic shells (GUIs) like KDE and GNU for standard point and
click operating. But unlike Windows systems (well, if you only look at the 'skin'
of a Windows system), the real power lies within command line shells (Bourne
and Bash, to name just a couple). These shells allow strong editing, real time
system monitoring and logging and great flexibility through command chaining.
Imagine being able to drop to the command prompt and, say, ping all devices
within a particular IP subnet, identify what each device is and then send the
information to a logging system that would then begin to monitor each of those
devices you identified as critical. Unix systems support this approach by allowing
you to chain together a series of commands whose outputs are fed to other commands
until there is a real piece of work being performed. It's almost like writing
code. Writing code just happens to be something that nearly every Unix administrator
can do and it's also something that very few Windows administrators even attempt.
Yet writing some basic code with a few simple tools and languages is exactly
what you'll need to do in order to make Windows behave as if it has some administrative
sophistication.
Windows command line shells just don't do this cleanly and are best regarded
as batch processing interfaces. But, again, don't worry. There are at least
a couple cures! There will be lots of opportunities and examples provided as
we write this column in the future.
Remote administration of Windows systems has indeed been a very large monster
to deal with until recently. Unix systems are almost unbounded in the many ways
you can remotely contact and perform services on a wide number of systems. Windows
systems are very poor if you approach this with an eye for directly interacting
with the system. With the recent inclusion of Terminal Services in Windows 2000
Server products, interacting directly with a desktop shell is now possible.
Still, you are somewhat limited in your abilities if you think that virtual
desktop is all the power you need to administer that server. Again, scripting
languages are your major tool for expanding the depth of even this remote management
tool.
|
