What I lived for?

My English Blog for International

DAILY TASKS FOR IT SYSTEM &

NETWORK ADMINISTRATOR
Once you join a company to work as a system & network administrator,just
like me, it requires ongoing day-to-day maintenance and improvement. In
this document, Id like to share a dozen daily tasks that a successful system
administrator needs to perform to keep his system and network running
smoothly.
In

this
document:
Using your management toolkits
Fire
fightingend
user
support
issues
Servers
Troubleshooting
Performing regularly scheduled tape backups and verifying backups via
test
restores
Testing server and desktop virus protection and updating virus data
Verifying
free
disk
space
on
your
servers
Keeping
tabs
on
your
servers
with
Event
Viewer
Verifying that all servers, applications, and databases are up and functional
Verifying
LAN
and
WAN
connectivity
Adding
new
hardware
to
your Windows
server
Documenting
and
sharing
procedures
Keeping your users working and happy
At this point, your Server network is up and running: Your servers with multioperation system including windows series and Linux/UNIX are set up, the
applications have been installed, the users are happily working away, and
everythings going well. Youre the new hero around the office. Now what?
Well, your job isnt getting any easier. Day-to-day administration of
your system and network will be every bit as challenging as the initial setup,
but it will be just as much fun as well. This article will explore the daily tasks
every system administrator should perform to ensure that his or her network
stays up and purrs along efficiently. A good system administrator should
make it a goal to perform all of these tasks daily, but all of us in the reallife administration game know thats not always feasible. Just do your best,
and customize these tasks to meet the needs of your network.
This article includes a concise 12-step approach to the daily ins and outs

of System Administration. These are the daily dozen activities an

administrator can expect to perform. Undoubtedly, you will be able to add
your own daily activities to this list as you see fit.

STEP 1: THE MANAGEMENT TOOLKITS

Every System administrator has a number of tools he

or she uses each day to help keep the network
humming along. Most of these tools are supplied with
the operating system: User Manager for Domains,
Server Manager, Event Viewer, Performance Monitor,
and several others. But a few of these tools are
physical tools such as real hardware tools, CD-ROM
guides, books, even emergency telephone numbers.
All of these are discussed in this section. Everyone
has a different approach to running his or her
network, but at least several of these wide-ranging
tools are found in just about every admins list of
frequently called-upon utilities and bag of tips, tricks,
secrets,
and
general
know-how.
The first step is to gather all of your frequently used
programs into one place on your administrative
workstation. I have a folder on my Workstations
desktop called Toolkit,This folder contains all of the
programs and scripts I use on a daily basis while
maintaining my network. I always leave the Toolkit
window open, so these programs are within easy
reach throughout the day. Youd be surprised how
much time this saves over searching through the Start
menu.

System administrative
Such

as

Microsoft

tools
administrative

packects.I

have

download and installed on my computer thus I can

manager

the

windows

servers most

quickly

and conveniently.So if you have installed the Microsoft

windows series server,strongly recommand to find and
download the relative toolkit from Microsoft site.

Third-party

administration

tools

In addition to the tools Microsoft supplies with Windows

NT Server, administration utilities are available from

several third parties.One that I swear by is Hyena, from

Adkins Resource in Adkins, Texas . Hyena makes daily
administration a lot easier for myself and my partners at
work: It combines all the functionality of User Manager,
Server Manager, and Event Viewer into one application,
and it includes some Windows Explorer functions as well,
such as NTFS permissions management for local and
remote servers.

Real
I

hardware

carry

limited

set

of

tools
real

tools

including

two screwdrivers,a chip extractor and static energy

discharger wristband. Its safe to say that this type of
toolkit is a necessary and required fixture for any
System Administrator. I mean, any SA has to be at least
able to connect a cable or open a workstation! If youre
gonna earn the lofty salaries paid to SAs, you gotta at
least have the basics down.

Microsoft Knowladge Base and Internet,such as Google &

BBS.
These toolkit on internet almost can answer and resolve
all of your question and problem. Good to use them you
will get more benefits.

Some

scripts

written

by

yourself.

I have write some script files with commands used

frequently to manage and monitor the status of system
and network.

Emergency

Phone

List.

It is really very very important when you cannot resolve

a emergency problem,or need to call somebody others
or

supplier,it

I always

take

will

save

with a

name

many

times.

card with collection

of emergency phone list.

STEP 2: END USER SUPPORT

Every
seasoned System
Administrator
has
experienced this one: Youre at your desk, on the
verge of solving that server performance problem
thats been nagging you for weeks, when the VP of
Finance walks up and rather testily informs you that

she is unable to print. Read hold everything! Its a

fire! Next thing you know, youve spent an hour
removing and reinstalling the VPs print drivers,
undoing the damage her free online service software
did to the PCs network setup, and you cant even
remember your fantastic server performance solution.
These "fires" are frustrating sometimes, but its key
for System Administrators and engineers to remember
that the end users are our raison detre. They are our
customers: why we do what we do. Many of "them"
also approve our budget. Even if youre lucky enough
to be insulated from the end users by a first-tier help
desk, chances are that youll be called upon to provide
escalation
support
at
least
once
a
day.
Here are some techniques Ive learned that help me
dispatch fires as they come up and hopefully prevent
new
ones.
When a support issue comes up, whether its bad print
drivers or users unable to connect to the network
because of a server crash, always jot down a little
note to yourself before jumping up from your desk to
fight the fire. Five times out of six, before I started
doing this, Id forget what I was working on when I
got back to my desk after correcting the problem.

Remember

your

manners

Even if youre interrupted in the middle of a major

breakthrough by what you may consider a minor
problem, remember that your minor problem may be a
major one for the user. Think back to the days when you
were an end user, and how you felt if a technical support
person blew you off because they considered your
problem inconsequential. Nobody wants to be Dogbert
the mean network administrator, and in the real world,
brushing off end users problems can be severely career
limiting. Keep your role as "doctor" in mind, and solve
the problem quickly and professionally. Youll get back to
your breakthrough soon enough.

Educate

the

user

If possible, explain to the user the steps youre taking to

solve their problem. An educated user is a happy user.

Obviously some users will not be interested in this level

of detail, preferring to be notified "when the darn thing
works," but many users will appreciate this extra
information. The same goes for first-level tech support
people: If they learn how to solve the problem, chances
are they wont be escalating it to you next time. Also,
many help desk staffers are grateful for the chance to
observe more senior administrators. I started my IT
career on a help desk, and every chance I got, I went
into the server room and watched as the Windows NT
administrators solved a problem. This exposure proved
very valuable in later years.

Document

your

solutions

After fighting a fire, its always a good policy to write an

e-mail message or note to yourself explaining the
problem and the solution, so youll have that knowledge
available in case the problem crops up again. I cant
count the times Ive been trying to solve a nagging
support issue and got the feeling that I had dealt with
the

same

thing

several

months

before.

Had

documented the problem and resolution, I wouldnt have

had to reinvent the wheel. If your company has a help
desk application or a homegrown solutions database,
enter the situation so that the information will be
available next time. If the solution was particularly
interesting or you think the issue will come up again,
share the information with other members of your
group, so theyll be "in the know" if theyre tapped to
solve

the

problem

later.

Like it or not, end user support is a big aspect of any

System Administration career. If you have the right
attitude and follow the proper procedures, you can learn
a lot from those day-to-day fires.

STEP 3: SERVERS TROUBLESHOOTING

Another big part of any System Administrators job is

server troubleshooting. Despite what system would
have you believe, IT doesnt run trouble-free at all
times, and external influences as well as internal
software errors can cause problems with the system.

When these issues come up, its key to remember that

you, as the administrator, have many different tools at
your disposal. Ill touch on each of these briefly a little
later.
Right now, my coworkers and I are trying to narrow
down the software villain thats causing our 2000
server to crash every couple of weeks. A reality of
networking is that no matter how fault-tolerant you
make your server hardware, adding redundant power
supplies,
RAID
arrays,
load-balanced network
adapters, and so on, theres usually a software bug
that can bring all of that crashing down.
When this particular server dies, user impact is very
heavy, as the majority of users keep their data on this
box. Every two weeks or so, with no regularity or
predictability, the servers network response time will
begin to slow down, and soon it will quit servicing
network users entirely. Well run into the server room,
and the console is unresponsive. Theres nothing left
to do but perform a dirty reboot. When the server
comes back up, we immediately check the event logs
and the Compaq hardware logs for errors, and yes,
you guessed it: nothing. These are the server
problems that try administrators souls and sometimes
cause us to question our motives for going into such a
crazy business. Luckily, the problem-solving tools are
there. Here is how we are applying them on my
network.
Documentation
One of the first things to ask when a new server
problem crops up is whether anything changed on the
server
just
before
the
problem
began.
Windows Server can be a fickle system, and even the
most innocuous change has the potential to send it
into a tailspin, sometimes for unexplained reasons.
Keeping a detailed log of any and all changes to each
server on your network can save you countless hours
of troubleshooting. In my office, we have an Excel
spreadsheet with separate sheets for each server, and
we record the date, time, and nature of each change

to the server, from installing new software to

scheduled or unscheduled reboots, adding new drives
or other hardware, and so on. These logs have proved
very valuable in the past, when a change we made
one week caused problems the next. Unfortunately,
this technique hasnt helped us with the current
challenge, so we moved on to the process of
elimination.
Logical deduction and process of elimination
At first glance, my group thought the server might be
crashing because of a network problem. However, all
the servers reside on a relatively low-usage 100 Mbps
Ethernet segment, and none of the other boxes had
any problems servicing users: the Exchange server
and our main application server were humming along
just fine. Also, we werent seeing an excessive
number of collisions on that servers port on the
switch. Thus, a broadcast storm or other network
problem was eliminated. Since then, weve tried to
simplify the servers configuration as much as
possible: stopping and disabling nonessential thirdparty services weve added, moving print services off
to another server, and watching closely to see
whether these steps make any difference. Its been
less than two weeks since our last server crash, so the
jurys still out, but were hopeful that removing some
of the load from the server will solve our problem.
Then, well slowly begin adding the third-party
services back in and testing to see which of them
might have caused the crashes.
Microsoft
TechNet
I guess I cant mention this resource enough.
Microsoft TechNet and its online partner Support
Online are fantastic resources for Windows IT
professionals). Chances are if youre having a strange
problem with your server, someone else has had the
same problem and reported it to Microsoft. When
Microsoft identifies a problem, they issue a support
article on it, and thousands of those articles are

gathered together with white papers and other

information on the TechNet CD each month. The
access to service packs, late-breaking technical
information, and upgrades can be priceless.
Ironically, one of TechNets strengths is also one of its
weaknesses. There is so much information that it can
take most of an afternoon to search through all the
articles that may come up on a search. When you are
using TechNet or Support Online, the more specific
your
query,
the
better.
Support
Online
can
be
found
at support.microsoft.com/supportand offers access to
the same Knowledge Base articles as a TechNet
subscription does, but without many of TechNets
other features .
Internet
support
groups
In my opinion, the best aspect of the Internet
revolution is the ability it has given private citizens to
gather together in clubs and user groups to share
information and solve problems quickly. Whether its a
car club sharing information about how to go faster at
the racetrack or computer types trying to solve a
problem, private parties now have much more
information at their fingertips than they did just three
or four years ago. Rather than waiting for a once-amonth user group meeting, Windows NT professionals
have access to many ongoing support discussions,
where they can bounce problems off other working
administrators. Often, they can get solutions in
minutes or hours instead of waiting days or weeks for
an answer from Microsoft or another vendor.
This ability to tap into the knowledge of hundreds or
thousands of other administrators and ask "Any of you
guys
ever
seen
this
one
before?"
has proved priceless on several occasions in my NT
administration career. Someone halfway across the
world may have solved the same problem youre
facing a month ago, or may be able to help you look
at the problem in another way that might propel you
toward
a
solution.

Internet support groups come in two flavors: e-mail

mailing lists and Web sitebased solutions databases.
Its worth any IT professionals time to join one of the
mailing lists and search these sites for answers.
Windows Server troubleshooting is definitely a
challenging aspect of any System Administrators daily
task list, but it can be made easier if you take
advantage of all the tools that are available.

STEP 4: TAPE BACKUPS

Backups as an essential element of any well-run

system. However, backups are only as good as the
media theyre recorded on. Even if your network has a
bulletproof backup plan in place, you must verify that
the proper files were actually backed up and make
sure the backups are "good", that the files will be
intact should you need to restore them.

Defining

backup

schedule

An important part of implementing any backup scheme

for your system is defining a schedule and sticking to it.
Depending on the size and complexity of your network,
and the volatility of your users data, you may need to
do nightly backups, or once a week might be sufficient.
Once you determine how often backups will be run, you
must ensure that this process happens each day or each
week.

Most

automatic

third-party
scheduling

backup

solutions

facility

built

have
in,

an
and

Windows native NTBACKUP program can be automated

using command scheduling utility. Once this task is
complete, backing up can become as easy as swapping a
few tapes daily. However, even this can have its pitfalls:
In my network, we rely on end users in field offices to
change tapes each day and send the old tape out for
offsite storage. On a couple of occasions, a user
assigned that task got busy and forgot to put the new
tape in after removing the old one. Luckily the server
didnt crash the day after one of these mishaps, as we
would have had severe "data exposure", but the

incidents made us nervous nonetheless back at the

home office.

Checking

backup

logs

Most backup utilities have logging built in that enables

administrators to see which files were backed up, if any
backups failed, and why they failed. Good network policy
dictates that the administrator checks these logs each
day to ensure that backups went the way they planned.
This has been a requirement in every network Ive
worked with and has saved my administrative bacon
more than once. If you determine that some files were
not backed up, it is sometimes possible to grab a quick
online backup, especially if the administrator gets into
the office earlier than the users.

Performing

test

restores

As I mentioned, backup sets are worthless unless the

data contained on them is intact. As such, its a very
good idea to restore some test data each day, to make
sure that the files were not corrupted during the backup
process. Its best to do this with test files that are
changed each day, but if you want to test-restore actual
user data, restore it to a test server rather than its
original location. Users have a funny way of getting
annoyed when the Excel spreadsheet they were working
on before lunch suddenly becomes yesterdays version.

In my network, we generally restore a few files

each week to a test server that weve set up. Once
were convinced that the backup is good, we can send
a copy of it to our offsite storage facility. Offsite
storage is very important to a successful network
backup scheme, so dont give it short shrift when
budgeting for backups.

STEP 5: VIRUS PROTECTION

Virus are one of the biggest headaches for System

Administrators today. I know Ive lived through my
share of virus outbreaks, some worse than others, but
none pleasant. The company I work for now didnt
even have a formal virus protection plan until the

CEOs PC got a virus via e-mail. He became

understandably upset about this, and within two
weeks, every desktop in the organization had some
form of virus protection enabled, and the servers soon
followed
suit.
While installing virus protection was a very important
step (you wouldnt believe what we found and
cleaned!), testing the protection programs and
keeping data files up to date is an ongoing challenge.

Testing

your

antivirus

software

The best way to see if your network is protected is to try

and infect it. This is best accomplished in a very
controlled environment, such as a test server thats not
connected to the network. While this sort of precaution
is overkill for the vast majority of viruses out there,
there are some real nasties to be found in the wild, and
its much better to be safe than sorry when youre
dealing
Test

with

documents

live
infected

production
with

certain

viruses

data.
can

generally be found on the Internet, so thats a good

place to start when youre looking to test your servers
safety net. Network Associates VirusScan product is a
popular antivirus solution . Once you have the virus in
hand, put the document on a disk, throw it in the server
and open it, and see what happens. If your antivirus
program is doing its job, it should catch the critter and
clean the document. If it doesnt, perhaps youd better
look into updating your softwares data files.

Updating

data

files

Viruses are constantly changing: It seems as though a

new one is being written and distributed nearly every
week. Antivirus software vendors recognize this and thus
update their programs with new "data files" periodically.
These files give the antivirus software blueprints for the
new viruses, so it is then able to catch and clean them.
The real challenge, from a network administrators point
of view, is figuring out how to distribute these updated
data files across the network. Even on a 20-user
network, visiting each desk is time consuming. In a
3,000-user WAN-connected network, desktop visits are

an impossibility. Some vendors offer automatic, built-in

data file upgrades with their desktop virus protection
products, but you must update the files manually with
others.
Were working on this challenge at my workplace right
now. Weve come up with three solutions:
o

Visiting each desktop as new data files come out. This

is possible in our network, but we would really prefer
to avoid it.

Distributing the updates via a batch file sent through

e-mail.

The

users

run

this

batch

file,

and

it

automatically copies the new data files down from a

central network location. This is what weve been doing
for a few months: It works, but success depends on
the users remembering (or being willing) to run the
batch

file.

As

every System

administrator

knows,

depending on the users to take care of themselves isnt

always the wisest option: When that VPs computer
becomes infected with a new virus because they forgot
to run the batch file, itll be your hide, not theirs.
o

Configuring our network logon script to compare the

dates on the users virus data files to the latest ones
on the network, and copy down the latest files if the
users data is out of date. This is a better solution than
the one previously described, but it still has some
pitfalls. For instance, we have a number of users who
work from home offices with telephone lines running at
a maximum of 56Kbps. Considering the reality of
todays phone lines, this figure is closer to 4045Kbps.
When these users log on after a virus data file update,
they will have a pause in their logon script while the
data

files

download,

which

will

almost

certainly

generate a support call. Even so, we are leaning

toward this option; for our network, its the best
solution to the virus data file distribution challenge.
Your mileage may vary, as no two networks are the
same.
o

Centralizing

virus

protection

If most vital data in your organization is kept on the

network (and it should be!), then centralized virus

protection on your servers is the most effective way to
ensure that virus infections do not interrupt your
companys business operations. Be sure to install virus
protection software on all of your file and application
servers, your e-mail or groupware server, and your
Internet gateway, if possible, and keep all of these
locations updated with the latest data files. This sounds
fairly straightforward, but youd be surprised how
many networks Ive seen with last years virus data
protecting

the

servers.

Remember, your networks virus protection is only

effective if all workstations and servers have the
product installed, and if they are kept up to date with
the latest virus data files. Its your job as the Windows
NT administrator to ensure these tasks are completed.
If you take care in keeping your protection tools
healthy, your network can remain virus-free without
too much effort.

STEP 6: FREE DISK SPACE

In the world of Windows series Servers, few things

can choke a server faster than running out of free disk
space. Running low on free space can have all sorts of
detrimental effects, ranging from poor performance
due to lack of paging space to services actually
shutting down for lack of resources. Some products,
like Microsoft Exchange Server, will shut themselves
down if disk space is getting low, to prevent
permanent damage to the applications database.
Believe me, you dont want to find out about low disk
space when you start getting calls because nobody in
the
enterprise
can
get
into
their
e-mail.
In todays environment of cheap storage, there really
is no excuse for allowing servers to run low on disk
space. As long as you stay on top of the storage
situation, you will never be caught with your
administrative pants down and end p in a crisis
situation.

Successful

storage

techniques

First, its very important to "right-size" your drive arrays

when a new server is built. Determine approximately
how much space the server will need when the network
is fully functional, and then add fifty percent to account
for future growth. This wont keep you covered for long,
though: In a fast-moving business, it might be a good
idea to buy double the storage you think you need.
Temper this interest with financial sense, however:
Depending on your situation, it might be a better idea to
hold off on purchasing more drives until you actually
need them. Youll likely pay less for the drives a year or
two

down

the

road

than

youd

pay

right

now.

Second, keep track of your servers disk space on at

least a weekly basis. This can be done from the server
console, via a batch file that connects network drives
and executes DIR commands, or from your desktop with
a third-party utility such as Hyena. At this point, its not
necessarily important to note which directories are
growing the fastest, although youll want to map out
your directories on at least a monthly basis. More on
that

in

Chapter

12.

Third, its crucial that you have a plan to add more

storage if and when you need it. Dont assume that
adding extra hard drives to your existing setup will be
easy: Depending on your hardware, you may not be able
to accomplish this without destroying the drive partitions
and restoring the entire server from backups. Its
important to know just what will be involved before its
crunch time and your server is working with less than
100 megabytes of free space while you try to figure out
how to add another drive.

Secret: Dont forget that at the enterprise or nearenterprise serverenvironment,

ordering

hard

disk

means that you must order it from your original server

manufacturer. With high-end HP, Dells, and the like, it is
simply not possible to trot down to your local clone
computer shop and purchase appropriate drives on short
notice. Thus, you are best advised to keep a supply of
hard disks that are known to work on your server in the
server room. Just in case!

More

detail

on

weekly

disk

space

monitoring

As I mentioned, you have several ways to monitor your

servers free disk space. The built-in way to do this,
though not necessarily the most efficient, is to follow
this procedure:
o

Go to each servers console.

Double-click My Computer, and then right-click the

drive in question.

Click Properties, and then record the figures given in

the servers Properties sheet.

An alternative to this is to use a third-party utility. In

the Hyena administration tool mentioned earlier, each
server has a "Disk Space" object that can be doubleclicked
and
inspected.
At my office, one of my coworkers came up with a
simple but effective way to monitor all of our servers
disk space using a batch file. The process includes a
FOR loop, which calls another batch file for each
server listed in a specific text file. The second batch
file then connects to the root of each drive on those
servers and performs a DIR command, directing the
output to another text file that we inspect to get the
actual free space readings. Its rather elegant,
actually,
for
a
home-grown
solution.
Whether you choose to use the built-in NT tools,
adopt a third-party solution, or "roll your own" free
space utility, definitely keep an eye on your servers
disks, and dont let them fill up. In my career, Ive
been through a couple of "disk full" situations, and
neither of them was very pleasant. Luckily, this type
of problem is easily avoided. Each week, spend a few
minutes with your hard disks; youll be glad you did.
2. STEP

7:

EVENT

LOGS

When Microsoft designed Windows NT, they included a

tool that is an essential part of the operating system:
event logging. This logging, together with the Event
Viewer, which enables administrators to inspect the logs

generated, can tell Windows NT professionals exactly

what has taken place on their servers. This kind of detail
can prove very valuable if the server starts having
problems; more often than not, a server problem has a
reasonable explanation, and that explanation is often
found in the event logs.

Event logging isnt limited to the operating system.

Applications that are designed for Windows NT bring
with them their own event sources and IDs. Also,
security logging takes place when the server is a
domain controller or when you have specified that
certain actions, such as file accesses, be audited for
later
inspection.
Before I get too much farther into event logging, a
discussion of the types of events and their
characteristics
is
in
order.
Windows NT series Server events come in five flavors:
o

Information. These events generally are recorded

when a significant but successful event happens on
your Server; a service starts successfully, for example.
You will see several of these events each time a server
is

booted,

as

the

services

start

themselves

up.

Information events are marked in the Event Viewer

with a blue circle containing an "I".
o

Warning. These events are recorded when something

happens on the server that may not be significant now
but could spell trouble later. Low disk space is a good
example of a situation that could cause a Warning
event .Warning events are recognized because they
appear next to a yellow circle with an exclamation
point inside.

Error. This indicates that a serious problem has

occurred

on

performance.

the
Error

server

that

events

are

could
most

hamper

its

commonly

generated when services fail to start, but they can be

associated with such serious events as hard drive
failures in a RAID array, or worse. Error events are
marked with a red stop sign.

Success Audit. These auditing events are recorded in

the Security log when a successful security event takes
place, such as a user logging on successfully or gaining
access to a file or directory that is marked for auditing.
The Success Audits icon is a yellow key.

Failure Audits. These are generated when a user is

unable to log on, or when the user attempts to access
a file, directory, or privilege he or she does not have
access to. Failure audits are marked with a gray
padlock.

Windows NT series server events also contain several

attributes,
explained
in.
At my business, checking event logs is a weekly task,
unless something seems to be going wrong with one
of the servers. In that case, we go right to the logs to
look for information on any possible problems.
One thing thats very important to remember about
Event Viewer is that just because a Warning or Error
event doesnt sound too serious, or because you dont
know what it is, you shouldnt just clear the log and
ignore the event. Sometimes these "unknown" events
can be precursors to a major system problem. If the
errors content or cause isnt clear from the
information in the event log, record the Event ID and
jump into TechNet or Support Online to query on that
ID. Often, these confusing events are caused by bugs
in software or the operating system, and eight times
out of ten, Ive found a solution by searching TechNet
and finding references to service packs or hotfixes
that correct these strange events. On another
occasion, my cohorts and I couldnt identify the cause
of a periodic serious error that was recorded in our
event logs. After searching TechNet, we were able to
determine that is was a precursor to a major SCSI
device failure, and we were able to replace the failing
device before it took down the server.
In short, Event Viewer is a tremendously powerful tool
for Windows IT professionals: The event logs are like

a continuous record of your servers health, with

possible problems recorded in real time throughout
the day. By making proper use of Event Viewer, you
can prevent server and network problems from
rearing their ugly heads. Even if these challenges do
get the best of your server, Event Viewer can assist
you in diagnosing and correcting the problem.
o

STEP

8:

VERIFICATION

OF

SERVERS

AND

APPLICATIONS

This task should be first and foremost on each System

Administrators morning checklist. When you get into
the office, take a few minutes to check out all the
servers, applications, and databases. If theyre not
working properly, its a lot better for you to find out
about it before too many users get into the office than
for your phone to start ringing off the hook while you
sit in clueless bliss drinking your coffee. Also, if your
schedule allows it, try to get into the office at least a
half hour before the majority of the users. This way, if
there is a problem, you have a little cushion of time to
try to fix it. Even in 7 24 shops, most people still
work 8 to 5, so getting in at 7:30 or earlier will help
lower your stress level if one of your servers decides
to go on vacation overnight.
o

First:

Check

on

the

servers

and

services

Many server hardware products come with Simple

Network Management Protocol (SNMP)based remote
management tools that can tell you at a glance which
boxes are running and which are not. Although these
tools are good for ensuring that the hardware is on and
the operating system (networking) is functional, they
dont really tell you anything about the services on the
server. It is certainly possible for a Primary Domain
Controller to be up and running, but if the Netlogon
service has stopped, aint nobody logging on from
nowhere. Thus, its a good idea to look at the actual
services on each server using Server Manager or your
favorite third-party utility . This process takes a little
while, but it definitely pays for itself in the long run. For

instance, someday it could save you from having to

explain to the boss why you didnt check to make sure
the Exchange Information Store was running on your
Exchange server because your management tool said
the

machine

was

up.

If you do discover a problem during your morning check,

nows the time to fix it, before many more users come
into the office and start hammering on the systems.
o

Second:

Check

applications

and

databases

After youre convinced that your servers are up and

healthy and the services are running, the next step is to
actually log onto each application and do some test
operations to make sure the apps themselves are
working properly. This operation doesnt have to be
elaborate; a simple test query or two will do, but every
Windows NT administrator should at least have the
access and the know-how to log on and test each
application on his or her servers. At my office, we have
four main applications that reside on our NT servers, and
we try to test them out each morning as soon as we get
in. If we find something wrong and it looks like the
server itself is up and running, we can report the
problem

to

the

appropriate

applications

group

for

resolution.
o

STEP

9:

VERIFICATION

OF

LAN

AND

WAN

CONNECTIVITY.
Once youre satisfied that your servers and applications
are running and ready for the users, the next step in
a System administrators daily checklist is to make sure
everybody on the network is talking. This can be
accomplished in a couple of ways, depending on the size
of your network and the tools at your disposal. If you
use an SNMP network management system like HP
OpenView,

Tivoli

NetView,

or

Computer

Associates

Unicenter TNG, your SNMP console will tell you in an

instant whether network links are up or down. However,
if youre in a smaller organization that didnt budget for
these rather expensive tools, you can still easily verify
whether your network is intact each day. Its a fairly

simple task to write a batch file that uses the TCP/IP

ping utility to attempt to reach all servers and network
devices on your LAN and WAN and then write its results
to a text file thats available for your inspection. If youre
still using IPX exclusively and do not have TCP/IP
running on your networks, you can write a routine that
connects to remote machines via RPC calls, such as
attempting to map a drive on the remote machine.

A TCP/IP ping batch file might look something like

this:
REM Testing network connectivity on LAN and WAN
ping server1 > conntest.txt
ping server2 > conntest.txt
ping wan1server2 > conntest.txt
ping wan2server1 > conntest.txt
end

Once you have your text file available, you can inspect
it and look for ping timeouts and excessive
turnaround times that might indicate a problem with
your network. In fact, its a good idea to automate
this process with command so that you can schedule
the connectivity test batch file to run a few minutes
before you get into the office. That way, the results
will be available when you arrive, and you can take
action
if
necessary.
This method is the way we monitor connectivity at my
office, and while its not as fancy as some of the
network management tools, it is effective and gives
us what we need and enables us to make sure our
users in faraway branch offices stay as connected as
the folks in the home office.
Secret: If you need a slightly more sophisticated
approach than the "home grown" variety displayed
previously, you should consider Ping Plotter, a lowcost shareware application from Richard Ness at
Nessoft (www.nessoft.com). Not only does this
application test ping connectivity, but it also enables
you to observe ping performance across several WAN

hops. The hop path is even mapped for you! MCSE

consultant-types typically use this tool for testing
telco/WAN performance. That is to say that Ping
Plotter enables you to test the links and down the
food chain on your WAN. This ultimately enables you
to answer your questions regarding the subscribed
bandwidth the telco sold you and the performance
that you are actually enjoying. Important questions
indeed to get answers to, might I say, on a daily
basis.
Tool like Ping Plotter are also great for keeping a
green machine awake. Here is what I mean: Perhaps
youve installed Windows NT Server on a truly lowcost workstation. But try as you might, you cant
disable the sleep function at the workstations BIOS
level (its happened to me). To keep the workstation
from "sleeping" and crashing Windows NT Server, you
can use Ping Plotter to maintain a constant activity
level that prevents, shall I say, napping. Problem
solved.
Whatever your preferred pinging method is, the
bottom line is that you are trying to verify
connectivity. On your bad NT days, that becomes an
end in itself. Otherwise, this step should just be
second nature. And you can always count on your end
users to be your connectivity eyes and ears. If they
cant connect, youll know.

STEP 10: NEW HARDWARE

As flaky as it is sometimes, the Plug and Play feature of

Windows series is nice to have. Nothing beats buying a
Plug and Playcompliant peripheral, throwing it into your
PC, and having the operating system detect and set up
the new hardware. Easy as pie, as long as you buy
compliant hardware.

So how the heck do you add new hardware to a

Windows NT series Server? Its actually easier than it

seems. When you buy a new piece of hardware for

your server, it will come with a Setup disk or CD-ROM
that contains drivers for the device. However, using
the distribution software in the box should always be
your second step; the first step is to check the
hardware vendors Web site. Ninety percent of the
time, the drivers on the Web are newer than those in
the box, and with very few exceptions, you always
want to use the latest driver.
o

Preparing

for

installation

Before you set about installing your new hard drive,

network adapter, or whatever, you should take stock of
the resources currently in use on the system.You can do
this by running Windows NT Diagnostics, the NT version
of

Microsofts

good

ol

DOS

MSD

program.

NT

Diagnostics will enable you to inspect and print out the

list of resources in use on your server, including interrupt
request lines (IRQs), memory addresses, I/O ports, and
direct memory access ( DMA) channels. This way, you
can determine where the new hardware will fit in.
Note: In most cases, a devices driver setup program
will determine and assign free system resources, so the
preceding step is only necessary when the setup
program will prompt you to choose resource information.
o

Installing

the

hardware

Unless you are installing a "hot-pluggable" device as

described in the text that follows, the first step in any
hardware installation is to power down the server and
disconnect its power source. Also put on some sort of
static protection device; in our server room, there are
several static control bracelets that can be connected to
grounded server parts to prevent static buildup and
possible

damage

to

sensitive

components.

Once you have opened up the server and identified

where the new device will go, install and connect it
according to the manufacturers directions.

Secret: Some servers even allow you to add or

replace hard drives while the server is up and
running, with no interrruption of service to the end

users. These so-called "hot pluggable, hot swappable"

drives are invaluable in 7 24 operations.
o

Installing

and

configuring

drivers

After the new hardware is in place, close the server back

up and power it on. Take care to properly close all
access panels on the computer; some servers have
safety switches that prevent them from powering up
unless

all

of

these

panels

are

in

place.

After the operating system comes up, run the hardware

driver setup program and install and configure the
hardware,

again

according

to

the

manufacturers

specifications.

In many cases, you must reboot the server in order to

get Windows NT to recognize and properly utilize the
new device, and some device setup programs will
even reboot the machine themselves after theyre
done installing the peripheral. This is usually not the
case with "hot-plug" hardware, but if you have a
choice, take care to perform these hardware
operations after hours, or schedule a bit of downtime,
even if youre not sure whether youll need it.
When all of these operations are complete, your new
hardware should be set up and ready for you and your
users to use!
o

STEP

11:

DOCUMENTATION

AND

SHARING

PROCEDURES

While its not as "active" a task as some of the others

mentioned in this chapter, documentation is very
important for the success of any network. There is
absolutely no sense in one person being proficient at a
network administration or process while his or her
coworkers are in the dark. In my mind, this is actually
a dangerous situation, especially if the task in
question is vital to the health of the network. What if
that person were hit by a truck? What would the rest
of you do?

Documentation is one thing thats a high priority at

my workplace; we are encouraged, in fact required, to
document new processes as they are developed and
perfected. This isnt just for others sake, either: Ever
get a process down perfectly, only to forget it after a
couple of months? Find yourself wishing you had
written it down before? I sure have, many times over
the years.
In my office, we have a procedures directory on the
network that contains more than 100 documents.
Some are out of date now, but we keep them around
anyway; some of the tasks detailed could crop up
again, or the techniques could be adapted for our
current network. In addition, we train each other on
new procedures as they are written and do "beta
testing." When one of us creates a new procedure,
such as installing a new application or restoring a
Microsoft Exchange mailbox from backups, he will
document it thoroughly. The next step is to have
another administrator do the "monkey test," where we
just follow the procedure step by step, making sure to
leave our outside knowledge at the computer room
door. When all we have to go on is the procedure
before us, its easy to identify holes or assumptions
and correct them. Some of our procedures are so
good that any end user could come into the server
room and perform the task by following the step-bystep procedure document. Yikes: Thats not very good
for job security!
If you ever have a bit of downtime between fighting
fires and the endless upgrades, think a moment about
procedures you use that may not be documented as
well as they should be, and address those issues.
Good documentation initially makes a Windows NT
professionals job much easier later on.
Secret: If you are a consultant, performing the
documentation task is a great way to find and bill
additional hours. Such additional work is great for
three reasons. First, it requires virtually no marketing

to get. Its easier to sell your existing clients on

additional work than it is to sell work to new clients.
Second, the work is easy to perform. Third, if help you
toward reaching your annual billable hour goal. Be
sure to use Visio or some other networking
diagramming tool as part of your network
documentation approach.

STEP 12: WORKING AND HAPPY USERS

This last topic is more a philosophical discussion than

a technical one. As a Windows NT professional, it is
imperative that you keep the needs of your users in
the front of your mind at all times. After all, they are
your customers, and despite what your org chart
might say, you work for them. After you break out of
the front-line support game and earn a position back
in the server room, its sometimes easy to put these
thoughts aside, crucial as they may be. Ive worked in
shops that cover both ends of the spectrum: From a
place that would drop the Exchange server in the
middle of the day if they deemed it necessary, to my
current employer, where one of the IT departments
primary goals is to remain invisible, to make sure the
users dont even know were there. I prefer the latter,
even if it means quite a bit of after-hours and
weekend work. The users main impression of the
companys network is that it just works. Your users
should feel the same way. To that end, here are some
helpful tips Ive picked up over the years.
o

Protect

the

users

If you have a choice, choose the action that will impact

the users least. For example, a few months back we
noticed that one of our servers was starting to go
downhill; unexplained Server service warning events
were showing up in the event logs, response times were
increasing slightly, and it was evident that something
was wrong. At this point, it was a judgment call for my
group: Do we leave the server up in the expectation that

it will make it to the end of the day, or do we reboot it

now, in the middle of the afternoon? As we evaluated
the situation, we noted that the problem likely would not
cause any data loss, and we took into account that this
was one of the busiest days of the month. We decided to
gamble and leave the server up until the end of the
business day, and it coasted along fine. Decisions like
these are tough, because you obviously dont want the
server to come crashing down if you can help it, but we
decided that the minimum user impact would be to leave
the server up. It was a decision between 10 minutes
ofguaranteed downtime for a reboot, or 10 minutes
of possible downtime if the server crashed later and had
to be rebooted. We did, however, take steps to notify all
affected groups about the situation, which brings me to
my next point.
o

Keep

the

users

informed

In my experience, users have an easier time accepting a

service interruption if they know its coming. In the
preceding example, my group sent out a company-wide
e-mail message advising the users that the server was
having problems and might crash, and telling the users
to save often. We got positive feedback about this
approach; even though the users werent happy that the
server might die in the middle of the day, they
appreciated the warning. Had the machine crashed, they
would have lost a lot less work than if they hadnt had
any

warning.

End users do like to know the basic reasons for

downtime, but its also a good practice to keep technical
jargon out of end user communications. While you may
think its neato to explain the intricacies of ESEUTIL in
an e-mail message informing users that the Exchange
server will be down for the weekend, the fact is that
most people just dont care. Keep your communications
straightforward and to the point, and your message will
come across loud and clear. If an end user really is
interested in what youre doing with the Exchange box,
he or she will reply and ask for more information. For
everyone else, a simple note saying "The Exchange

server

will

be

down

this

weekend

for

database

maintenance" will suffice.

o

Keep

the

help

desk

informed

When I worked on an enterprise help desk, it always

seemed as if we were the last to know about vital
information that would affect the users. Half the time,
we gathered this information from the users themselves
as they called, which was terribly frustrating and
embarrassing. Like every other tech support veteran I
know, I swore up and down that once I got to the back
of the shop, Id make help desk communications a
priority so that my first-level support would never be
without the proper information. Have I made good on
this

promise?

Mostly,

although

Im

still

not

as

communicative to our help desk as Id like to be. Its a

good goal to have, though; the better informed your
first-level support people are, the better the users
impression will be of your department as a cohesive unit
where groups communicate among one another.
o

Strive

for

100

percent

uptime

Continuous uptime may seem like an obvious goal for

anyone who runs a computer system, but keeping it in
your mind at all times is a real challenge. Now, everyone
whos worked with NT for any length of time knows that
NT servers need reboots every so often, but a really
good NT administrator should try to minimize this need.
Keep your servers simple, assign them only the tasks
you need them to perform, and dont clog up the system
with additional services or applications unless theyre
absolutely essential. Theres a saying that a persons
body is his or her temple; make temples out of your
production boxes. Have fun with your test servers, but
when you have a spare moment, spend it working to
make your Windows NT servers as fault-tolerant as they
can be. As I mentioned earlier, many administrators
dont have a problem spending hundreds or thousands
of dollars to make their hardware bulletproof. Put in the
hours necessary to make your operating systems and
software just as bulletproof.