Enterprise Software

Novice net admins: Get off to a good start with these pointers

It may be a time for tremendous growth and learning, but your first job as a net admin is rife with opportunity for mistakes. Experienced hand Jeff Dray offers advice to help you avoid some of the pitfalls he learned about the hard way.

As a new network administrator, you may find that you’re up to your neck in responsibility for mission-critical operations. At least, that’s what happened to me. In my first job as a net admin, I had to hit the ground running, and I gave new meaning to the expression “on-the-job training.”

I made a lot of mistakes but tried to learn a lesson from every one. Now I want to share the wisdom I gained from my many missteps by offering tips and tricks for novice net admins. I hope you can sidestep a few problems by using these simple rules:
  • Label everything.
  • Back up everything and advise others to do so.
  • Plan, plan, and plan some more.
  • Communicate the need for downtime.
  • Discuss users’ requirements.
  • Use all available resources to learn new skills and techniques.
  • Test everything and question everything.

Second of two parts
This article focuses on the final three rules. I discussed the first four in my previous article.

Rule five: Discuss users' requirements
Learning to communicate with end users can be troublesome for some net admins. To get your relationship with users off on the right foot, I advise that you sit down with them and ask what it is they want from the network. I’d explain the advantages of using the network, draw pictures to show how it works, and make the policy on backups crystal clear.

You’ll also want to set up a process for service requests. I recommend that you invest in a system for logging them. Although it can seem cumbersome or unnecessary to insist upon e-mail requests for items like toner, software upgrades, and new keyboards, that documentation will help you—and your supervisor—analyze how your days are spent. Written requests that have been logged correctly provide a history that, when analyzed, can point to problems such as vital end-user training or troublesome policies.

In addition, I'd tell your users when you are available for support and when you will be performing vital but routine maintenance. This will help manage users’ expectations for how quickly you’ll respond to requests for more trivial jobs. By restricting your work schedule, you’ll ensure that none but the most urgent task can break into the time you’ve allocated for regular maintenance.

Rule six: Use all available resources to learn new skills and techniques
I suggest that you take advantage of every opportunity to attend courses and join discussion groups and that you sign up online for any resource you can find. At the time of my first net admin experience, Internet access wasn’t as widespread as it is now, so my sources of information were extremely limited.

For those of you who are privileged to be a fledgling net admin these days, I suggest that you look to discussion groups and online help to get quick answers. The chances are that plenty of people have seen the problem before and will know the answer. Failing that, they will be able to advise you on the best place to look for the answer. It can’t all be found in a book, and you can’t be expected to know everything.

I have also learned to push for all the training courses my employer will allow so I can bridge my knowledge gaps. If you’re nervous about asking for training funds, remember that the company is saving a lot of money by paying you the salary of a novice net admin. This is your chance to learn the job, so take every opportunity to build your own knowledge.

Another way to get on-the-job training is to build relationships with vendors and learn from their expertise. In addition, trade shows can be useful sources of information and contacts. Just beware the salesperson who is looking to fill that order book before the end of the day.

Rule seven: Test everything and question everything
Perhaps the most important piece of advice I have for inexperienced network administrators is this: Test everything before loading it to the live system.

The most valuable tool you can have is a miniature network, which can consist of a couple of spare outdated PCs. Try out any major upgrades or alterations on this system before committing to rolling them out on the live network. This can save you a great deal of trouble later. This piece of advice saved me once when my director asked for a modem to be fitted to the server so that he could get access to his work from home. He brought me an internal modem that he had acquired from somewhere. The driver disk was handwritten and aroused my suspicions. I installed it on my test network; I wanted to see how the Modem Sharing option worked before committing myself to bringing the server down, and it was a good thing I did.

The PC failed even to boot with the modem installed. Had I fitted this to the server without checking, the downtime would have been far longer than I had promised—something that wouldn't go down too well with the boss. I bought another modem with the correct driver for NT4 and took the bill to the manager. He was shocked that the component, which he had acquired from a source he trusted, was defective. He was even more shocked when the modem I bought was a good deal cheaper. It was a valuable lesson, and from then on it was agreed that he would do the scientific research and I would do the “techie” stuff—an arrangement that made life a good deal more comfortable for all of us.

On another occasion, I was asked to load a suspicious piece of software. The managing director handed me a CD and said, "Load this so that all the staff can use it."

"What is it?" I asked.

"Never mind about that, it’s something scientific that the researchers need to have access to."

Having been burned before, I decided to start by running it on the test LAN. The first thing that came up was a warning that the software was for stand-alone systems only. There was a note that it could be upgraded to a network version and quoted a Web address for a schedule of license pricing. I nearly fell off my chair when I saw how much a license for 18 users would cost.

I went back to the managing director and asked for the license certificate. I wasn’t surprised to learn that there wasn’t one. At that point I had three choices; I could:
  • Load the software to each workstation individually without a license.
  • Load it on the managing director’s machine and pretend he did it himself.
  • Refuse to do either and risk my job.

I explained the situation to the managing director, outlining the options and the possible outcomes. The question of networking the software was easy to resolve, as the version we had was a stand-alone version. I was solemnly assured that he did own the license for it.

In the end, I was able to convince the managing director that none of the other staff really wanted or needed the software, so we decided to install it on only his personal workstation. After successfully navigating the waters of software licensing, I still decided to do a test installation of the software on the LAN. I’m glad I did, because the test resulted in my having to reload the OS entirely. So when performing the live install I was able to select the options more carefully to avoid disaster on his workstation.

Final thoughts
No matter what the situation, becoming an experienced network administrator has a tough learning curve. On my first assignment, I was learning the craft of a net admin while the rest of the company was learning to work with a network. I hope it made their lives easier. They were accustomed to using paper and pen until a few weeks before my arrival, and when I left, they were publishing their findings electronically.

It wasn't always a smooth ride, but if they learned as much as I did, they should be satisfied. I guess that's the key to it all—as a net admin, you never stop learning.

Recently, I was supporting a doctor with a connectivity problem, and he remarked that the process I used to discover the cause of the problem was similar to the one he used to discover the cause of a patient's Illness: questions, diagnosis, and treatment. Although, he added, the human body is far more complicated. My counter to this was, for me, surprisingly swift: "Yes,” I said, “but the advantage with the human body is that they don't release a new version of it every six months."
0 comments

Editor's Picks