A few months ago, I left a local hospital where I had served as
Network Administrator for about 4 years. Because I had spent a reasonably
extended period of time on the job there, I was fortunate to work with a good
team of network analysts and technicians.
A few months ago, I left a local hospital where I had served as Network Administrator for about 4 years. Because I had spent a reasonably extended period of time on the job there, I was fortunate to work with a good team of network analysts and technicians.
Through the normal course of daily network administration, I
took as many opportunities as possible to teach my network analysts/technicians
the various components and concepts of networking and how NT networks should be
supported and managed. While each technician brought a wealth of background in
computer hardware and software, they were relatively new to network
administration concepts. Through time and hands-on experience, they gained a
fairly solid grasp of intermediate NT administration such as TCP/IP
internetworking, name resolution, server management, and fault tolerance.
When I resigned from my position, the IT department found itself
in a technical quandary. Without a Network Administrator on staff, the job of
managing the 12 + NT Server 4 and 600 + workstation network fell squarely on the
shoulders of one of my previous LAN analysts that had no previous NT network
administration experience. I find myself still today directing him in the
various activities that should be part of his routine NT administration tasks. I
believe there are many readers of swynk.com that would consider themselves to be
in a similar situation. Because of this, I want to give those readers a good
outline of the activities that should be part of an administrators routine
maintenance and support of an NT network.
In this article, I will point out and discuss several of the
most important activities a new (or veteran) NT administrator should be involved
in on a routine basis. This listing is by no means all-inclusive, but rather my
own insight and perceptions that experience has taught me through good, and
not-so-good encounters with NT-related situations.
Let’s Get Started !
Monitor Event Viewer regularly: Some of the
most valuable information that can be provided is found within the NT Event
Viewer. Begin early to make a habit out of regularly spending time with this
utility. The System log will often give you advanced warning of
potential problems that lie ahead.
Not long ago, I was reviewing the System log at a clients site and noticed
several warnings that had been recorded. The messages referred to a SCSI
hard drive that continually failed to respond during write requests within
the default timeout period. Because I found this problem early, I was able
to work with the onsite support staff to get the mission critical data that
resided on that particular hard drive, safely moved to another drive before
a drive failure occurred.
The Application log will provide you with information that relates to
specific apps that reside on the NT Server. If you are running Exchange or
SQL Server, you can find application-generated information within the log.
This log is particularly useful for keeping tabs on DHCP, WINS, License
logging, and other core NT services that sometimes need maintenance
The Security log is useful for monitoring events such as
logon/logoff, printer access, along with file and folder access. Alot of the
events that will eventually show up in the Security log can only be gathered
once you enable auditing within User Manager for Domains. In addition,
BackOffice applications such as Exchange and SQL Server write
security-related information to this log.
Use Performance Monitor to gauge system performance: Another
great tool that comes with an NT installation is Performance Monitor. Just
as Event Viewer can provide you with a wealth of information about system
activities once they happen, Performance Monitor can provide
system-wide or component-specific performance info as it
I often advise other NT Administrators to use Performance Monitor
(perfmon.exe) to establish a working baseline for each of their critical NT
Servers and then use that baseline as a standard by which their servers
should be regularly measured. (For information on how to use Performance
Monitor to setup a server baseline, see the article “How
to Establish a performance baseline in NT Server 4.0”.
Once you have established a baseline for gauging server performance,
continue to monitor those key counters I highlight in the
previously-mentioned article. I recommend setting up a perfmon workspace
file with those counters and setting the Update Interval to 30 seconds. In
doing so, keep the perfmon session minimized so you can view it every few
days to see if any system components (processor, memory, disk, etc.) are
acting as a bottleneck to otherwise improved server performance.
Backup that server !: I know, I know, this one
is obvious, right? Well, most everyone would think so. I cannot begin to
calculate the number mission critical NT servers I have witnessed having no
backup routine at all. The majority of them were Primary Domain Controllers
(PDC) and housed other critical apps such as Exchange Server. Without a
regularly scheduled, routine verified, and thoroughly tested backup
procedure in place, all of my other recommendations are moot. As backup
hardware continues to become more affordable, the valid reasons for not
having a backup process dwindle significantly.
As of today, you can purchase an internal 4mm tape drive for around $450.
Add to that 14 tapes and you end up with a hardware investment of around
$1100. Considering the price of rebuilding an NT server, reconstructing (if
possible) the data that was lost, paying staff members salary/overtime that
would be needed to re-do work that was lost, $1100 is a relatively
inexpensive price to pay. Fortunately, Windows NT Server 4.0 ships with
Ntbackup is a sound backup software application that can serve basic backup
needs at no additional cost. While it can only be used to back up the local
machine (as opposed to backing up other servers across the network), it
nonetheless provides a safety net for your data and applications in the
event of a server failure.
Don’t forget the ERD: After you have
successfully implemented and tested a backup strategy, it’s time to consider
the NT registry and associated system files. Even if you are able to afford
the more expensive backup software products such as ArcServe 2000 or
BackupExec, an updated copy of the ERD is invaluable in the event of a
corrupted NTLDR or NTOSKRNL. In addition, creating the ERD is as simple as
To create (and update) the ERD, insert a formatted 1.44MB floppy disk into
the server floppy drive. From the Start menu, point to Run. When the dialog
box appears, type “c:winntsystem32rdisk.exe
/s” (without the quotation marks.) Follow the prompts and the disk
will be created. Using the /s switch forces a backup of the SAM database,
which is tremendously useful in the event the database becomes corrupted.
Once you have a copy of the ERD for each NT server you own, store them
offsite in a safe location. You will want to update the disk every month or
so, depending on the amount of user changes/modifications you make.
Keep an eye on DHCP, WINS, and DNS: These
three services are at the heart of many NT networks throughout the world.
While a discussion of each is beyond the scope of this article, a basic
understanding of what maintenance steps you need to take with each of them,
is not. While two of the three are relatively self sufficient in
administration, one of them is not.
In keeping with the “backup” theme of the past two items I
mentioned, it is important to know that you have a current backup of each of
the DHCP, WINS, and DNS databases. While each of them accomplishes backups
in different ways, it is necessary that you understand how each one operates
in relation to that backup function.
DHCP is the more tricky service of the group when it comes to backups. By
default, the DHCP database and checkpoint log are backed up when the service
is stopped. While this may not seem to pose a significant concern to many,
since server uptime is a priority for most organizations, it is therefore
not impossible to have a DHCP database backup that is 6, 9, or 12 months
old. Unless you reboot your NT server every night, you are not getting a
backup of the DHCP database. I recommend that you schedule (through a system
scheduler application, or the AT command scheduler) a batch file that stops
the DHCP Server service (net stop dhcpserver) and restarts it (net start
dhcpserver). I recommend scheduling the batch file to execute once per
WINS, unlike DHCP, is able to perform online backups of the WINS database (wins.mdb).
You do, however, need to open WINS Manager and setup the backup function to
occur on a regular basis. To do so, open WINS Manager and select the
Mappings menu. Click the Backup Database item in the drop down menu. From
there, you can select a drive (local or network) and directory that the
database backup will be stored in. Once you click OK, a backup takes place.
Once you have your initial WINS backup, from WINS Manager, select the Server
menu item and then click Configuration. When the configuration dialog box
opens, click on Advanced to open the bottom of the display. You can then
click the checkbox to enable WINS to backup on termination, and you can type
in a path for the database backups to be housed. A scheduled batch file
should also be incorporated to stop and start the WINS service so that the
backup occurs automatically (net stop wins and net start wins).
DNS is unique to the other 2 services mentioned in that it doesn’t really
use a database at all. The DNS service uses dns zone files to store records
(*.dns). These files can be backed up with most (if not all) NT backup
software. Because of this, there is no additional steps needed in relation
to backup, other than verification that the NT backup process is getting the
Be well read: Do yourself (and your career) a
favor, and stay abreast of the various things going on within the major NT
website resources that are available. There is a wealth of information that
can be learned simply by reading what other administrators have been faced
with, and how they wrangled a solution. Sites such as this (swynk.com) are
tremendous resources for the NT professional that is either supporting a
network, or aspiring to do so. In a future column, I’ll provide my listing
of the top Windows NT support resources on the web. Stay tuned.
I, like many others, began administering Windows NT just because
no one else was there to do it. I could write a book about the multitude of
mistakes I made early on in those types of situations. I ended up breaking alot
of things, but also learned how to repair alot of them as well. That is the
essence of learning. A 19th century philosopher once said “…a man does not
look to see if someone is hiding under the bed, unless he has once hidden there
himself…” The same holds true for networking professionals. “..a man
does not write NT support columns for new administrators unless he himself was a
new administrator once…”