A few months back, I offered some advice for tech pros who were taking on their first role as network administrator. A few pieces of advice garnered quite a few comments from TechRepublic members. The issues that drew the most arguments were:
- Labeling cable
- Policing policies
- Being flexible
- Documenting all actions
I feel strongly enough about the advice I provided to follow up with the reasoning behind my recommendations. Here's more support to bolster my original points.
Read Dray's original advice for novice net admins
- "Novice net admins: Sidestep problems with these simple rules"
- "Novice net admins: Get off to a good start with these pointers"
Label the cable
In the first article, I said network administrators need to label everything: "My advice is to label every port, every cable, and every terminal and keep a spreadsheet of who has what and where it is. You don't want to spend your valuable time tracking network problems caused by devices that are simply moved and not reconnected properly."
Several members took issue with my advice to label the cable itself, saying it was too much trouble to be worth doing. Let me explain my reasons for labeling both ends of a patch cable. Imagine this scene: There is a row of network ports on the wall next to a group of desks. The cables that are plugged into them snake off under the desks and disappear into a living hell of discarded shoes and dust bunnies. I can state from bitter experience that no matter how neatly and carefully you lay out your cables, after a few weeks of use, the scene under those desks will resemble an explosion in a badly lit spaghetti factory. The day will come when you'll need to trace a cable back to the socket, and it will be next to impossible without a cable tester.
You have all seen those diagrams that network trainers use to describe an Internet connection, where all the connections go into a cloud, denoted as "The Internet." Well, that cloud is in fact an illustration of themes under many thousands of desks all over the world. To be able to say that Cable Red 5 is plugged into socket 20/12/01 and into the PC that is giving trouble can save an awful lot of uncomfortable crawling about in the dust and fluff.
Policing the policies
I also related some anecdotes about how I'd been asked to load unlicensed software onto my networks. This raised the issue of system policies with members—a thorny issue every net admin must deal with.
Policies are put in place to ensure that security, license tracking, and software conflicts do not become a problem. On some occasions, people try to use their seniority to overrule a policy and insist on an administrator doing something in violation of it.
If this happens, it's important to document the request so that you cover yourself in the event of a witch-hunt to find the party responsible for any damage done when the policy was overruled. And above all, remember: No employer can make you do something that is illegal.
Some members expressed fears about persuading people to take ownership of system security policies. This should not be a problem if your communication is good. Talk to the people who will be affected by any policy. Explain how the policy will benefit them and also explain how it may have to be enforced for legal reasons.
Once the negotiations are finished, it's time to set up the physical policies—the restriction of system rights to prevent unauthorized access and installation of unlicensed software and to prevent data theft. When I'm asked to work on a system that is locked down, I understand that there are some things the network administrator wants me to do and other things that will be done by an authorized engineer. That's fine, so long as anything I need to have done to my machine is done in a timely and correct fashion. The response levels for requests should, of course, be agreed upon, along with the implementation of the policy.
Flexibility of approach
That leads to the next point of contention some members raised: Who retains ownership of IT policies? A few members implied that it sometimes suits people to override policies when the occasion requires it. When this happens, it's important to do your best for the user but also to follow up. I recommend contacting the person who asked for the policy override and request a written explanation of the need to circumvent the existing rules. Then, you might suggest implementing a change to the procedure to accommodate such requests in the future. This action may ultimately protect jobs in IT support, as there will always be a need for somebody to be at hand to maintain the service. And remember, no policy should be written in stone—there is always room for improvement.
Document, document, document
Network administrators often complain that they don't have time to document or log changes and updates to the network. Networks can jog along nicely for months without any major problems, and it's easy to take network knowledge for granted. But consider the time it will take to recover from a crisis if little or no documentation exists. When something does go wrong, it can be vital to have all the information about the setup at hand and available to anyone who might need it.
Consider the worst-case scenario: Your network administrator carries the map of the entire network in his or her head. What happens when that person is not around? An accident, illness, or extended holiday could render the admin unreachable during a major network crisis. If good documentation exists, the problem is reduced. With old or nonexistent documentation, it could take a long time to recover from an outage.
For that reason, network administrators should be allowed the time and resources to log all the configuration and equipment data of their networks and to be able to keep it up to date. Unfortunately, this is a lesson that many companies—and novice net admins—learn the hard way.
Am I right or am I right?
If you're an experienced admin, drop me a line to let me know if you agree or disagree with my approach, or post your opinions in the discussion below.