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 attention.
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 happens.
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.
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 it gets.
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:\winnt\system32\rdisk.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 week.
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 *.dns files.
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..."