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,

I d like to share a dozen daily tasks that a successful system administrator need
s to perform to keep his system and network running smoothly.
wristband. It s 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 you re gonna earn the lofty salaries pai
d 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 m
onitor 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 will save many times.
I always take with a name card with collection of emergency phone list.
STEP 2: Ewhat we do. Many of "them" also approve our budget. Even if you re lu
cky enough to be insulated from the end users by a first-tier help desk, chances
are that you ll be called upon to provide escalation support at least once a day.
Here are some techniques I ve learned that help me dispatch fires as they come
up and hopefully prevent new ones.
When a support issue comes up, whether it s bad print drivers or users unable
to connect to the network because of a server crash, always jot down a little no
te to yourself before jumping up from your desk to fight the fire. Five times ou
t of six, before I started doing this, I d forget what I was working on when I got
back to my desk after correcting the problem.
Remember your manners
Even if you re interrupted in the middle of a major breakthrough by what you m
ay 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 fel
t if a technical support person blew you off because they considered your proble
m inconsequential. Nobody wants to be Dogbert the mean network administrator, an
d in the real world, brushing off end users problems can be severely career limit
ing. Keep your role as "doctor" in mind, and solve the problem quickly and profe
ssionally. You ll get back to your breakthrough soon enough.
Educate the user
If possible, explain to the user the steps you re taking to solve their proble
m. 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 firstlevel tech support people: If they learn how to solve the problem, chances are t
hey won t be escalating it to you next time. Also, many help desk staffers are gra
teful for the chance to observe e proved very valuable in the past, when a chang
e we made one week caused problems the next. Unfortunately, this technique hasn t
helped us with the current challenge, so we moved on to the process of eliminati
on.
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 M
bps Ethernet segment, and none of the other boxes had any problems servicing use
rs: the Exchange server and our main application server were humming along just
fine. Also, we weren t seeing an excessive number of collisions on that server s por
t on the switch. Thus, a broadcast storm or other network problem was eliminated
. Since then, we ve tried to simplify the server s configuration as much as possible
: stopping and disabling nonessential third-party services we ve added, moving pri

nt services off to another server, and watching closely to see whether these ste
ps make any difference. It s been less than two weeks since our last server crash,
so the jury s still out, but we re hopeful that removing some of the load from the
server will solve our problem. Then, we ll slowly begin adding the third-party ser
vices back in and testing to see which of them might have caused the crashes.
Microsoft TechNet
I guess I can t mention this resource enough. Microsoft TechNet and its online
partner Support Online are fantastic resources for Windows IT professionals). C
hances are if you re having a strange problem with your server, someone else has h
ad the same problem and reported it to Microsoft. When Microsoft identifies a pr
oblem, they issue a support article on it, and thousands of those articles are g
athered together with white papers and other information on the TechNet CD each
month. The access to service packs, late-breaking technical information, and upg
rades can be priceless.
Ironically, one of TechNet s 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 Suppo
rt Online, the more specific your query, the better.
Support Online can be found at support.microsoft.com/support and offers acce
ss to the same Knowledge Base articles as a TechNet subscription does, but witho
ut many of TechNet s 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 it s a car club sharing informatio
n about how to go faster at the racetrack or computer types trying to solve a pr
oblem, private parties now have much more information at their fingertips than t
hey did just three or four years ago. Rather than waiting for a once-a-month use
r group meeting, Windows NT professionals have access to many ongoing support di
scussions, where they can bounce problems off other working admiy were working o
n before lunch suddenly becomes yesterday s version.
In my network, we generally restore a few files each week to a test server t
hat we ve set up. Once we re convinced that the backup is good, we can send a copy o
f it to our offsite storage facility. Offsite storage is very important to a suc
cessful network backup scheme, so don t give it short shrift when budgeting for ba
ckups.
STEP 5: VIRUS PROTECTION
Virus are one of the biggest headaches for System Administrators today. I kn
ow I ve lived through my share of virus outbreaks, some worse than others, but non
e pleasant. The company I work for now didn t even have a formal virus protection
plan until the CEO s PC got a virus via e-mail. He became understandably upset abo
ut this, and within two weeks, every desktop in the organization had some form o
f virus protection enabled, and the servers soon followed suit.
While installing virus protection was a very important step (you wouldn t beli
eve what we found and cleaned!), testing the protection programs and keeping dat
a 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. Th
is is best accomplished in a very controlled environment, such as a test server
that s 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 it s much better to be safe than sorry when you re dealing with li
ve production data.
Test documents infected with certain viruses can generally be found on the I
nternet, so that s a good place to start when you re looking to test your server s saf
ety net. Network Associates VirusScan product is a popular antivirus solution . O

nce you have the virus in hand, put the document on a disk, throw it in the serv
er 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 doesn t, perhaps you d b
etter look into updating your software s data files.
Updating data files
Viruses are constantly changing: It seems as though a new one is being writt
en and distributed nearly every week. Antivirus software vendors recognize this
and thus update their programs with new "data files" periodically. These files g
ive the antivirus software blueprints for the new viruses, so it is then able to
catch and clean them. The real challenge, from a network administrator s point of
view, is figuring out how to distribute these updated data files across the net
work. Even on a 20-userndows NT administrator to ensure these tasks are complete
d. If you take care in keeping your protection tools healthy, your network can r
emain 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 sor
ts of detrimental effects, ranging from poor performance due to lack of paging s
pace to services actually shutting down for lack of resources. Some products, li
ke Microsoft Exchange Server, will shut themselves down if disk space is getting
low, to prevent permanent damage to the application s database. Believe me, you d
on t want to find out about low disk space when you start getting calls because no
body in the enterprise can get into their e-mail.
In today s environment of cheap storage, there really is no excuse for allowin
g servers to run low on disk space. As long as you stay on top of the storage si
tuation, you will never be caught with your administrative pants down and end p
in a crisis situation.
Successful storage techniques
First, it s 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 gr
owth. This won t 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 i
nterest 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
. You ll likely pay less for the drives a year or two down the road than you d pay r
ight now.
Second, keep track of your server s disk space on at least a weekly basis. Thi
s can be done from the server console, via a batch file that connects network dr
ives and executes DIR commands, or from your desktop with a third-party utility
such as Hyena. At this point, it s not necessarily important to note which directo
ries are growing the fastest, although you ll want to map out your directories on
at least a monthly basis. More on that in Chapter 12.
Third, it s crucial that you have a plan to add more storage if and when you n
eed it. Don t 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. I
t s important to know just what will be involved before it s crunch time and your se
rver is working with less than 100 megabytes of free space while you try to figu
re out how to add another drive.
Secret: Don t forget that at the enterprise or near-enterprise server environm
ent, ordering a 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 o
n short notice. Thus, you are best advised to keep a supply of hard disks that a
re 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 fo

llow this procedure:

Go to each server s console.
Double-click My Computer, and then right-click the drive in question.
Click Properties, and then record the figures given in the server s Proper
ties sheet.
An alternative to this is to use a third-party utility. In the Hyena adminis
tration tool mentioned earlier, each server has a "Disk Space" object that can b
e double-clicked 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 t
ext 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 t
hat we inspect to get the actual free space readings. It s rather elegant, actuall
y, for a home-grown solution.
Whether you choose to use the built-in NT tools, adopt a third-party solutio
n, or "roll your own" free space utility, definitely keep an eye on your servers
disks, and don t let them fill up. In my career, I ve 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;
you ll be glad you did.
STEP 7: EVENT LOGS
When Microsoft designed Windows NT, they included a tool that is an essentia
l part of the operating system: event logging. This logging, together with the E
vent Viewer, which enables administrators to inspect the logs generated, can tel
l Windows NT professionals exactly what has taken place on their servers. This k
ind 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 explana
tion is often found in the event logs.
Event logging isn t limited to the operating system. Applications that are des
igned for Windows NT bring with them their own event sources and IDs. Also, secu
rity 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 ins
pection.
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:
Information. These events generally are recorded when a significant but
successful event happens on your Server; a service starts successfully, for exam
ple. You will see several of these events each time a server is booted, as the s
ervices start themselves up. Information events are marked in the Event Viewer w
ith a blue circle containing an "I".
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 p
oint inside.
Error. This indicates that a serious problem has occurred on the server
that could hamper its performance. Error events are most 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 re
d stop sign.
Success Audit. These auditing events are recorded in the Security log wh
en a successful security event takes place, such as a user logging on successful
ly or gaining access to a file or directory that is marked for auditing. The Suc
cess Audit s 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 i
n.
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 log
s to look for information on any possible problems.
One thing that s very important to remember about Event Viewer is that just be
cause a Warning or Error event doesn t sound too serious, or because you don t know
what it is, you shouldn t just clear the log and ignore the event. Sometimes these
"unknown" events can be precursors to a major system problem. If the error s cont
ent or cause isn t clear from the information in the event log, record the Event I
D and jump into TechNet or Support Online to query on that ID. Often, these conf
using events are caused by bugs in software or the operating system, and eight t
imes out of ten, I ve found a solution by searching TechNet and finding references
to service packs or hotfixes that correct these strange events. On another occa
sion, my cohorts and I couldn t identify the cause of a periodic serious error tha
t was recorded in our event logs. After searching TechNet, we were able to deter
mine 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 profes
sionals: The event logs are like a continuous record of your server s health, with
possible problems recorded in real time throughout the day. By making proper us
e of Event Viewer, you can prevent server and network problems from rearing thei
r ugly heads. Even if these challenges do get the best of your server, Event Vie
wer can assist you in diagnosing and correcting the problem.
STEP 8: VERIFICATION OF SERVERS AND APPLICATIONS
This task should be first and foremost on each System Administrator s morning
checklist. When you get into the office, take a few minutes to check out all the
servers, applications, and databases. If they re not working properly, it s a lot b
etter for you to find out about it before too many users get into the office tha
n for your phone to start ringing off the hook while you sit in clueless bliss d
rinking your coffee. Also, if your schedule allows it, try to get into the offic
e 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 lowe
r your stress level if one of your servers decides to go on vacation overnight.
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 h
ardware is on and the operating system (networking) is functional, they don t real
ly 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 servic
e has stopped, ain t nobody logging on from nowhere. Thus, it s a good idea to look
at the actual services on each server using Server Manager or your favorite thir
d-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 e
xplain to the boss why you didn t check to make sure the Exchange Information Stor
e was running on your Exchange server because your management tool said the mach
ine was up.
If you do discover a problem during your morning check, now s the time to fix
it, before many more users come into the office and start hammering on the syste
ms.

Second: Check applications and databases

After you re convinced that your servers are up and healthy and the services a
re running, the next step is to actually log onto each application and do some t
est operations to make sure the apps themselves are working properly. This opera
tion doesn t have to be elaborate; a simple test query or two will do, but every W
indows 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 m
ain 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 ap
plications group for resolution.
STEP 9: VERIFICATION OF LAN AND WAN CONNECTIVITY.
Once you re satisfied that your servers and applications are running and ready
for the users, the next step in a System administrator s daily checklist is to ma
ke sure everybody on the network is talking. This can be accomplished in a coupl
e 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 inst
ant whether network links are up or down. However, if you re in a smaller organiza
tion that didn t budget for these rather expensive tools, you can still easily ver
ify whether your network is intact each day. It s 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 t
hat s available for your inspection. If you re still using IPX exclusively and do no
t 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, it s 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 yo
u 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 it s no
t 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 st
ay as connected as the folks in the home office.
Secret: If you need a slightly more sophisticated approach than the "home gr
own" variety displayed previously, you should consider Ping Plotter, a low-cost
shareware application from Richard Ness at Nessoft (www.nessoft.com). Not only d
oes 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! M
CSE 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 regardi
ng 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. Her
e is what I mean: Perhaps you ve installed Windows NT Server on a truly low-cost w
orkstation. But try as you might, you can t disable the sleep function at the work
station s BIOS level (it s 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 t
rying 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 can t connect, you ll
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 Play compliant peripheral, throwing
it into your PC, and having the operating system detect and set up the new hardw
are. 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? It s ac
tually easier than it seems. When you buy a new piece of hardware for your serve
r, 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 seco
nd step; the first step is to check the hardware vendor s Web site. Ninety percent
of the time, the drivers on the Web are newer than those in the box, and with v
ery few exceptions, you always want to use the latest driver.
Preparing for installation
Before you set about installing your new hard drive, network adapter, or wha
tever, 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 Microsoft s 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 w
ay, you can determine where the new hardware will fit in.
Note: In most cases, a device s driver setup program will determine and assign
free system resources, so the preceding step is only necessary when the setup p
rogram will prompt you to choose resource information.
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 s
erver and disconnect its power source. Also put on some sort of static protectio
n device; in our server room, there are several static control bracelets that ca
n be connected to grounded server parts to prevent static buildup and possible d
amage 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 manufacturer s 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. The
se so-called "hot pluggable, hot swappable" drives are invaluable in 7 24 operat
ions.
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 ha
ve 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 a
nd install and configure the hardware, again according to the manufacturer s speci
fications.

In many cases, you must reboot the server in order to get Windows NT to reco
gnize and properly utilize the new device, and some device setup programs will e
ven reboot the machine themselves after they re done installing the peripheral. Th
is is usually not the case with "hot-plug" hardware, but if you have a choice, t
ake care to perform these hardware operations after hours, or schedule a bit of
downtime, even if you re not sure whether you ll need it.
When all of these operations are complete, your new hardware should be set u
p and ready for you and your users to use!
STEP 11: DOCUMENTATION AND SHARING PROCEDURES
While it s not as "active" a task as some of the others mentioned in this chap
ter, documentation is very important for the success of any network. There is ab
solutely 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 healt
h of the network. What if that person were hit by a truck? What would the rest o
f you do?
Documentation is one thing that s a high priority at my
uraged, in fact required, to document new processes as they
rfected. This isn t just for others sake, either: Ever get
, only to forget it after a couple of months? Find yourself
ten it down before? I sure have, many times over the years.

workplace; we are enco

are developed and pe
a process down perfectly
wishing you had writ

In my office, we have a procedures directory on the network that contains mo

re 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 adap
ted 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 procedur
e, such as installing a new application or restoring a Microsoft Exchange mailbo
x 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, it s easy to identify holes or a
ssumptions and correct them. Some of our procedures are so good that any end use
r could come into the server room and perform the task by following the step-bystep procedure document. Yikes: That s not very good for job security!
If you ever have a bit of downtime between fighting fires and the endless up
grades, think a moment about procedures you use that may not be documented as we
ll as they should be, and address those issues. Good documentation initially mak
es a Windows NT professional s job much easier later on.
Secret: If you are a consultant, performing the documentation task is a grea
t way to find and bill additional hours. Such additional work is great for three
reasons. First, it requires virtually no marketing to get. It s easier to sell yo
ur existing clients on additional work than it is to sell work to new clients. S
econd, the work is easy to perform. Third, if help you toward reaching your annu
al 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 user
s in the front of your mind at all times. After all, they are your customers, an
d 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, it s s

ometimes easy to put these thoughts aside, crucial as they may be. I ve worked in
shops that cover both ends of the spectrum: From a place that would drop the Exc
hange server in the middle of the day if they deemed it necessary, to my current
employer, where one of the IT department s primary goals is to remain invisible,
to make sure the users don t even know we re there. I prefer the latter, even if it
means quite a bit of after-hours and weekend work. The users main impression of t
he company s network is that it just works. Your users should feel the same way. T
o that end, here are some helpful tips I ve picked up over the years.
Protect the users
If you have a choice, choose the action that will impact the users least. Fo
r 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 ev
ent logs, response times were increasing slightly, and it was evident that somet
hing 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 situati
on, 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 g
amble 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 don t want the s
erver 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 minute
s of guaranteed 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 not
ify all affected groups about the situation, which brings me to my next point.
Keep the users informed
In my experience, users have an easier time accepting a service interruption
if they know it s coming. In the preceding example, my group sent out a company-w
ide e-mail message advising the users that the server was having problems and mi
ght crash, and telling the users to save often. We got positive feedback about t
his approach; even though the users weren t 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 hadn t had any warning.
End users do like to know the basic reasons for downtime, but it s also a good
practice to keep technical jargon out of end user communications. While you may
think it s neato to explain the intricacies of ESEUTIL in an e-mail message infor
ming users that the Exchange server will be down for the weekend, the fact is th
at most people just don t care. Keep your communications straightforward and to th
e point, and your message will come across loud and clear. If an end user really
is interested in what you re doing with the Exchange box, he or she will reply an
d ask for more information. For everyone else, a simple note saying "The Exchang
e server will be down this weekend for database maintenance" will suffice.
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 w
as 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, I d make help
desk communications a priority so that my first-level support would never be wi
thout the proper information. Have I made good on this promise? Mostly, although
I m still not as communicative to our help desk as I d like to be. It s a good goal t
o have, though; the better informed your first-level support people are, the bet
ter the users impression will be of your department as a cohesive unit where grou
ps communicate among one another.
Strive for 100 percent uptime
Continuous uptime may seem like an obvious goal for anyone who runs a comput
er system, but keeping it in your mind at all times is a real challenge. Now, ev
eryone who s worked with NT for any length of time knows that NT servers need rebo
ots every so often, but a really good NT administrator should try to minimize th
is need. Keep your servers simple, assign them only the tasks you need them to p

erform, and don t clog up the system with additional services or applications unle
ss they re absolutely essential. There s a saying that a person s body is his or her t
emple; make temples out of your production boxes. Have fun with your test server
s, but when you have a spare moment, spend it working to make your Windows NT se
rvers as fault-tolerant as they can be. As I mentioned earlier, many administrat
ors don t have a problem spending hundreds or thousands of dollars to make their h
ardware bulletproof. Put in the hours necessary to make your operating systems a
nd software just as bulletproof.
Challenge yourself to work smarter each and every day. This might include re
ading trade journals such as InfoWorld, PC Week, and the like. You might read an
other article just for the heck of it. Consider taking an in-classroom or online
course. But each and every day, be sure to make a capital investment in yoursel
f so that you work smarter tomorrow than you did today!