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 server and disconnect its power source. Also put on some sort of static protection device; in our server room, there are several static control bracelets that can be connected to grounded server parts to prevent static buildup and possible damage 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. These so-called “hot pluggable, hot swappable” drives are invaluable in 7 × 24 operations. |
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 have 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 and install and configure the hardware, again according to the manufacturer’s specifications.
|
Note: Directions are typically provided on a disk by the manufacturer. This is a key step because you must effectively install new hardware manually under Windows NT Server 4.0 (which only has adequate hardware detection during its setup phase). Windows 95/98 of course have great real-time hardware detection, something you won’t see in Windows NT server until Windows 2000 Server. |
In many cases, you must reboot the server in order to get Windows NT to recognize and properly utilize the new device, and some device setup programs will even reboot the machine themselves after they’re done installing the peripheral. This is usually not the case with “hot-plug” hardware, but if you have a choice, take 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 up 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 chapter, documentation is very important for the success of any network. There is absolutely 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 health of the network. What if that person were hit by a truck? What would the rest of you do?
Documentation is one thing that’s a high priority at my workplace; we are encouraged, in fact required, to document new processes as they are developed and perfected. This isn’t just for others’ sake, either: Ever get a process down perfectly, only to forget it after a couple of months? Find yourself wishing you had written it down before? I sure have, many times over the years.
In my office, we have a procedures directory on the network that contains more 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 adapted 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 procedure, such as installing a new application or restoring a Microsoft Exchange mailbox 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 assumptions and correct them. Some of our procedures are so good that any end user could come into the server room and perform the task by following the step-by-step 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 upgrades, think a moment about procedures you use that may not be documented as well as they should be, and address those issues. Good documentation initially makes a Windows NT professional’s job much easier later on.
|
Secret: If you are a consultant, performing the documentation task is a great 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 your existing clients on additional work than it is to sell work to new clients. Second, the work is easy to perform. Third, if help you toward reaching your annual 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 users in the front of your mind at all times. After all, they are your customers, and 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 sometimes 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 Exchange 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 the company’s network is that it just works. Your users should feel the same way. To 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. For 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 event logs, response times were increasing slightly, and it was evident that something 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 situation, 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 gamble 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 server 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 minutes 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 notify 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-wide e-mail message advising the users that the server was having problems and might crash, and telling the users to save often. We got positive feedback about this 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 informing users that the Exchange server will be down for the weekend, the fact is that most people just don’t care. Keep your communications straightforward and to the 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 and ask for more information. For everyone else, a simple note saying “The Exchange 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 was 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 without 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 to have, though; the better informed your first-level support people are, the better the users’ impression will be of your department as a cohesive unit where groups communicate among one another.
Strive for 100 percent uptime
Continuous uptime may seem like an obvious goal for anyone who runs a computer system, but keeping it in your mind at all times is a real challenge. Now, everyone who’s worked with NT for any length of time knows that NT servers need reboots every so often, but a really good NT administrator should try to minimize this need. Keep your servers simple, assign them only the tasks you need them to perform, and don’t clog up the system with additional services or applications unless they’re absolutely essential. There’s a saying that a person’s body is his or her temple; make temples out of your production boxes. Have fun with your test servers, but when you have a spare moment, spend it working to make your Windows NT servers as fault-tolerant as they can be. As I mentioned earlier, many administrators don’t have a problem spending hundreds or thousands of dollars to make their hardware bulletproof. Put in the hours necessary to make your operating systems and software just as bulletproof.
Challenge yourself to work smarter each and every day. This might include reading trade journals such as InfoWorld, PC Week, and the like. You might read another chapter in this book 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 yourself so that you work smarter tomorrow than you did today!
Summary
Once your Windows NT Server network is set up, it requires ongoing day-to-day maintenance and improvement. As you can see, a Windows NT professional’s workday is a busy one. In this chapter, I shared a dozen daily tasks that a successful Windows NT administrator needs to perform to keep his or her network running smoothly:
 Using the Windows NT Server 4.0 toolkit and the Administrative Wizards
Fire Fighting: end user support issues
Troubleshooting
Performing regularly scheduled tape backups and verifying backups via test restores
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 NT server
Documenting and sharing procedures
Keeping your users working and happy
|
Page: 1, 2, 3, 4, 5, 6 |
|
|
|
|
|
Windows IT Pro
Register
