


Checking backup logs
Most backup utilities have logging built in that enables administrators to see which files were backed up, if any backups failed, and why they failed. Good network policy dictates that the administrator checks these logs each day to ensure that backups went the way they planned. This has been a requirement in every network Ive worked with and has saved my administrative bacon more than once. If you determine that some files were not backed up, it is sometimes possible to grab a quick online backup, especially if the administrator gets into the office earlier than the users.
Performing test restores
As I mentioned, backup sets are worthless unless the data contained on them is intact. As such, its a very good idea to restore some test data each day, to make sure that the files were not corrupted during the backup process. Its best to do this with test files that are changed each day, but if you want to test-restore actual user data, restore it to a test server rather than its original location. Users have a funny way of getting annoyed when the Excel spreadsheet they were working on before lunch suddenly becomes yesterdays version.
|
Secret: When performing a test restore, be sure not to select an option that is commonly presented on restore menus. This option is to restore the local Registry. Its an unwise move to say the least. Doing so would overwrite your production Registry with an aged Registry copy. That would of course cause problems on your network. |
In my network, we generally restore a few files each day to a test server that weve set up. Once were convinced that the backup is good, we can send a copy of it to our offsite storage facility. As discussed in Chapter 3, offsite storage is very important to a successful network backup scheme, so dont give it short shrift when budgeting for backups.
STEP 5: VIRUS PROTECTION
As I touched on in Chapter 3, viruses are one of the biggest headaches for Windows NT administrators today. I know Ive lived through my share of virus outbreaks, some worse than others, but none pleasant. The company I work for now didnt even have a formal virus protection plan until the CEOs PC got a virus via e-mail. He became understandably upset about this, and within two weeks, every desktop in the organization had some form of virus protection enabled, and the servers soon followed suit.
While installing virus protection was a very important step (you wouldnt believe what we found and cleaned!), testing the protection programs and keeping data files up to date is an ongoing challenge.
Testing your antivirus software
The best way to see if your network is protected is to try and infect it. This is best accomplished in a very controlled environment, such as a test server thats not connected to the network. While this sort of precaution is overkill for the vast majority of viruses out there, there are some real nasties to be found in the wild, and its much better to be safe than sorry when youre dealing with live production data.
Test documents infected with certain viruses can generally be found on the Internet, so thats a good place to start when youre looking to test your servers safety net. Network Associates VirusScan product is a popular antivirus solution (see Figure 11-9). Once you have the virus in hand, put the document on a disk, throw it in the server and open it, and see what happens. If your antivirus program is doing its job, it should catch the critter and clean the document. If it doesnt, perhaps youd better look into updating your softwares data files.
Updating data files
Viruses are constantly changing: It seems as though a new one is being written and distributed nearly every week. Antivirus software vendors recognize this and thus update their programs with new data files periodically. These files give the antivirus software blueprints for the new viruses, so it is then able to catch and clean them. The real challenge, from a network administrators point of view, is figuring out how to distribute these updated data files across the network. Even on a 20-user network, visiting each desk is time consuming. In a 3,000-user WAN-connected network, desktop visits are an impossibility. Some vendors offer automatic, built-in data file upgrades with their desktop virus protection products, but you must update the files manually with others.
Were working on this challenge at my workplace right now. Weve come up with three solutions:
- Visiting each desktop as new data files come out. This is possible in our network, but we would really prefer to avoid it.
- Distributing the updates via a batch file sent through e-mail. The users run this batch file, and it automatically copies the new data files down from a central network location. This is what weve been doing for a few months: It works, but success depends on the users remembering (or being willing) to run the batch file. As every Windows NT administrator knows, depending on the users to take care of themselves isnt always the wisest option: When that VPs computer becomes infected with a new virus because they forgot to run the batch file, itll be your hide, not theirs.
- Configuring our network logon script to compare the dates on the users virus data files to the latest ones on the network, and copy down the latest files if the users data is out of date. This is a better solution than the one previously described, but it still has some pitfalls. For instance, we have a number of users who work from home offices with telephone lines running at a maximum of 56Kbps. Considering the reality of todays phone lines, this figure is closer to 4045Kbps. When these users log on after a virus data file update, they will have a pause in their logon script while the data files download, which will almost certainly generate a support call. Even so, we are leaning toward this option; for our network, its the best solution to the virus data file distribution challenge. Your mileage may vary, as no two networks are the same.
Centralizing virus protection
If most vital data in your organization is kept on the network (and it should be!), then centralized virus protection on your servers is the most effective way to ensure that virus infections do not interrupt your companys business operations. Be sure to install virus protection software on all of your file and application servers, your e-mail or groupware server, and your Internet gateway, if possible, and keep all of these locations updated with the latest data files. This sounds fairly straightforward, but youd be surprised how many networks Ive seen with last years virus data protecting the servers.
Remember, your networks virus protection is only effective if all workstations and servers have the product installed, and if they are kept up to date with the latest virus data files. Its your job as the Windows NT administrator to ensure these tasks are completed. If you take care in keeping your protection tools healthy, your network can remain virus-free without too much effort.
STEP 6: FREE DISK SPACE
In the world of Windows NT Server 4.0, few things can choke a server faster than running out of free disk space. Running low on free space can have all sorts of detrimental effects, ranging from poor performance due to lack of paging space to services actually shutting down for lack of resources. Some products, like Microsoft Exchange Server, will shut themselves down if disk space is getting low, to prevent permanent damage to the applications database. Believe me, you dont want to find out about low disk space when you start getting calls because nobody in the enterprise can get into their e-mail.
In todays environment of cheap storage, there really is no excuse for allowing servers to run low on disk space. As long as you stay on top of the storage situation, you will never be caught with your administrative pants down and end up in a crisis situation.
Successful storage techniques
First, its very important to right-size your drive arrays when a new server is built. Determine approximately how much space the server will need when the network is fully functional, and then add fifty percent to account for future growth. This wont keep you covered for long, though: In a fast-moving business, it might be a good idea to buy double the storage you think you need. Temper this interest with financial sense, however: Depending on your situation, it might be a better idea to hold off on purchasing more drives until you actually need them. Youll likely pay less for the drives a year or two down the road than youd pay right now.
Second, keep track of your servers disk space on at least a weekly basis. This can be done from the server console, via a batch file that connects network drives and executes DIR commands, or from your desktop with a third-party utility such as Hyena. At this point, its not necessarily important to note which directories are growing the fastest, although youll want to map out your directories on at least a monthly basis. More on that in Chapter 12.
Third, its crucial that you have a plan to add more storage if and when you need it. Dont assume that adding extra hard drives to your existing setup will be easy: Depending on your hardware, you may not be able to accomplish this without destroying the drive partitions and restoring the entire server from backups. Its important to know just what will be involved before its crunch time and your server is working with less than 100 megabytes of free space while you try to figure out how to add another drive.
|
Secret: Dont forget that at the enterprise or near-enterprise server environment, ordering a hard disk means that you must order it from your original server manufacturer. With high-end Compaqs, Dells, and the like, it is simply not possible to trot down to your local clone computer shop and purchase appropriate drives on short notice. Thus, you are best advised to keep a supply of hard disks that are known to work on your server in the server room. Just in case! |
More detail on weekly disk space monitoring
As I mentioned, you have several ways to monitor your servers free disk space. The built-in way to do this, though not necessarily the most efficient, is to follow this procedure:
- Go to each servers console.
- Double-click My Computer, and then right-click the drive in question.
- Click Properties, and then record the figures given in the servers Properties sheet (see Figure 11-10).
An alternative to this is to use a third-party utility. In the Hyena administration tool mentioned earlier, each server has a Disk Space object that can be double-clicked and inspected, as seen in Figure 11-11.
At my office, one of my coworkers came up with a simple but effective way to monitor all of our servers disk space using a batch file. The process includes a FOR loop, which calls another batch file for each server listed in a specific text file. The second batch file then connects to the root of each drive on those servers and performs a DIR command, directing the output to another text file that we inspect to get the actual free space readings. Its rather elegant, actually, for a home-grown solution.
Whether you choose to use the built-in NT tools, adopt a third-party solution, or roll your own free space utility, definitely keep an eye on your servers disks, and dont let them fill up. In my career, Ive been through a couple of disk full situations, and neither of them was very pleasant. Luckily, this type of problem is easily avoided. Each week, spend a few minutes with your hard disks; youll be glad you did.
STEP 7: EVENT LOGS
When Microsoft designed Windows NT, they included a tool that is an essential part of the operating system: event logging. This logging, together with the Event Viewer (see Figure 11-12), which enables administrators to inspect the logs generated, can tell Windows NT professionals exactly what has taken place on their servers. This kind of detail can prove very valuable if the server starts having problems; more often than not, a server problem has a reasonable explanation, and that explanation is often found in the event logs.
|
Page: 1, 2, 3, 4, 5, 6 |
next page  |
|
|
|
|