Beruflich Dokumente
Kultur Dokumente
Once
, it
I d
s to
In this document:
Using your management toolkits
Fire fighting end user support issues
Servers Troubleshooting
Performing regularly scheduled tape backups and verifying backups via test rest
ores
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 multi-op
eration system including windows series and Linux/UNIX are set up, the applicati
ons have been installed, the users are happily working away, and everything s goin
g well. You re the new hero around the office. Now what?
Well, your job isn t 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 b
e just as much fun as well. This article will explore the daily tasks every syst
em administrator should perform to ensure that his or her network stays up and p
urrs along efficiently. A good system administrator should make it a goal to per
form all of these tasks daily, but all of us in the real-life administration gam
e know that s 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 in s and out s of Syst
em Administration. These are the daily dozen activities an administrator can exp
ect to perform. Undoubtedly, you will be able to add your own daily activities t
o 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 o
perating system: User Manager for Domains, Server Manager, Event Viewer, Perform
ance Monitor, and several others. But a few of these tools are physical tools su
ch as real hardware tools, CD-ROM guides, books, even emergency telephone number
s. 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 admin s list of frequently called-upon utilities an
d bag of tips, tricks, secrets, and general know-how.
The first step is to gather all of your frequently used programs into one pl
ace on your administrative workstation. I have a folder on my Workstation s deskto
p called Toolkit ,This folder contains all of the programs and scripts I use on a d
aily basis while maintaining my network. I always leave the Toolkit window open,
so these programs are within easy reach throughout the day. You d be surprised ho
w much time this saves over searching through the Start menu.
System administrative tools
Such as Microsoft administrative packects.I have download and installed on m
y computer thus I can manager the windows servers most quickly and conveniently.
So if you have installed the Microsoft windows series server,strongly recommand
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 more senior administrators. I started my IT care
er on a help desk, and every chance I got, I went into the server room and watch
ed as the Windows NT administrators solved a problem. This exposure proved very
valuable in later years.
Document your solutions
After fighting a fire, it s always a good policy to write an e-mail message or
note to yourself explaining the problem and the solution, so you ll have that kno
wledge available in case the problem crops up again. I can t count the times I ve be
en trying to solve a nagging support issue and got the feeling that I had dealt
with the same thing several months before. Had I documented the problem and reso
lution, I wouldn t 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 intere
sting or you think the issue will come up again, share the information with othe
r members of your group, so they ll be "in the know" if they re tapped to solve the
problem later.
Like it or not, end user support is a big aspect of any System Administratio
n career. If you have the right attitude and follow the proper procedures, you c
an learn a lot from those day-to-day fires.
STEP 3: SERVERS TROUBLESHOOTING
Another big part of any System Administrator s job is server troubleshooting.
Despite what system would have you believe, IT doesn t run trouble-free at all tim
es, and external influences as well as internal software errors can cause proble
ms with the system. When these issues come up, it s key to remember that you, as t
he administrator, have many different tools at your disposal. I ll touch on each o
f these briefly a little later.
Right now, my coworkers and I are trying to narrow down the software villain
that s causing our 2000 server to crash every couple of weeks. A reality of netw
orking is that no matter how fault-tolerant you make your server hardware, addin
g redundant power supplies, RAID arrays, load-balanced network adapters, and so
on, there s 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 server s network response time will begin to slow down, an
d soon it will quit servicing network users entirely. We ll run into the server ro
om, and the console is unresponsive. There s nothing left to do but perform a dirt
y 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 ar
e the server problems that try administrators souls and sometimes cause us to que
stion our motives for going into such a crazy business. Luckily, the problem-sol
ving 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 ca
n be a fickle system, and even the most innocuous change has the potential to se
nd 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 ho
urs 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 va
luable in the past, when a change we made one week caused problems the next. Unf
ortunately, this technique hasn t helped us with the current challenge, so we move
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-user network, visiting each desk is time consuming. In a 3,00
0-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.
We re working on this challenge at my workplace right now. We ve come up with th
ree solutions:
Visiting each desktop as new data files come out. This is possible in ou
r 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 we ve been doing for a few months: It work
s, but success depends on the users remembering (or being willing) to run the ba
tch file. As every System administrator knows, depending on the users to take ca
re of themselves isn t always the wisest option: When that VP s computer becomes inf
ected with a new virus because they forgot to run the batch file, it ll be your hi
de, not theirs.
Configuring our network logon script to compare the dates on the users vi
rus 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 previou
sly 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 5
6Kbps. Considering the reality of today s phone lines, this figure is closer to 40 4
5Kbps. 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 cer
tainly generate a support call. Even so, we are leaning toward this option; for
our network, it s the best solution to the virus data file distribution challenge.
Your mileage may vary, as no two networks are the same.
Centralizing virus protection
If most vital data in your organization is kept on the network (and it s
hould be!), then centralized virus protection on your servers is the most effect
ive way to ensure that virus infections do not interrupt your company s business o
perations. 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 you d be surprised how many networks I ve
seen with last year s virus data protecting the servers.
Remember, your network s virus protection is only effective if all worksta
tions and servers have the product installed, and if they are kept up to date wi
th the latest virus data files. It s your job as the Windows NT administrator to e
nsure these tasks are completed. If you take care in keeping your protection too
ls 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 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.
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!