TechRepublic member REZUMA recently posed this question in the Technical Q&A:
"I have a new client who wants me to solve a few problems and also to do a report of things that could be improved. It is a Windows 2000/2003 network with several satellite offices, so I know that I need to check the router, Active Directory sites configuration, etc… I am wondering is there is a book or paper that gives you an organized step by step of things to do when auditing a network. I could work on my own protocol of auditing a network but I would prefer to see if somebody has already done this."
TechRepublic member steve.freke responded with a detailed recommendation for getting started with a network audit:
"I would use the OSI model. Define what it was layer 1 – that is, all the physical connectivity between the active devices on the network. This includes cable runs between server rooms and wiring closets. This step will take the longest and is the most often ignored because it is the most tedious.
"Move up to layer 2 – document collision domains, STP instances, etc. Move to layer 3 – document broadcast domains, subnets and routing instances, including which routing protocol is being used, interface IP addresses, etc.
"Once you have documented layers 1-3 and understand the network infrastructure, you can start looking at the client/server infrastructure. There are many tools available, but you probably won't have the budget to spend $10K on audit or packet analysis tools. You can manually get this info from examining the active equipment, ARP tables (cross referenced with forwarding tables), and the routing tables. DHCP scopes are also useful.
"Ensure that you have a complete picture of each layer before you look at the next. If you don't have an accurate picture of layer 1, any info you collect about layers 2-3 will be flawed. For example, I once discovered that a cable I thought ran the length of the building was actually two cables connected with an old bridge that was hidden in the ceiling and also happened to be an STP root bridge. Disconnect that and the network would stop.
"Be methodical and take the time that is necessary to complete the task. I once audited a 2,500 desktop site with 80 servers in a farm. Working by myself for 12 hours a day for 4 days of the week, it took me nearly 3 months because I could trust nothing the client said, since he had not conducted a reliable audit using a sound methodology. It turned out he had two STP instances running, which explained why his network stopped working when he disconnected an "unused" segment.
"Never trust what the client says – always confirm any information for yourself. If he was to be trusted, you wouldn't be needed in the first place. Collect your raw data and then use it to produce node lists and physical and logical diagrams."
The text of discussion posts from TechRepublic members has been slightly edited for spelling and clarity.