Fast & Simple Network Mapping

Your boss comes to you on Monday morning with a new assignment. Your company, a multinational conglomerate, has finished acquiring a small financial services company in the area named TMI Financial. You are tasked with determining how to best integrate their IT systems with your own. This sounds like a pretty typical project for you until you learn that you have:

No budget. Nothing except your time, and you have little to spare from other projects.

No time. This should have been complete weeks ago.

No existing documentation. TMI had no dedicated IT staff.

No support. You are the scope of resources.

Luckily, the expectation is pretty basic. You need to provide a basic map and listing of their systems, including client, server, and network infrastructure. The recommendation you need to deliver is whether it is OK to connect the networks right now or whether some work must be done on TMI’s end before bridging the two. Once the networks are connected, TMI will be integrated with and managed by existing systems.

Approaching this challenge, or one like it, is less difficult than it seems. The key is to use exactly the right approach to the problem that

Task-Specific Network Mapping

In previous posts I’ve espoused the benefits of network maps. In fact, on looking back, I’ve been a bit repetitive about how critical having an accurate and thorough network map is. If you are not yet convinced, please take a look at those posts.

One important thing has been missing: specific instructions on how to create a network map. I’ve alluded to tools and techniques over and over but without diving into details about what tools are out there. The truth is that for many of your network mapping requirements you don’t need any tools at all.

How is that possible? Well, the key to a good network map is simple. You must gather the right amount of data using the least amount of effort that will enable you to make business and technology decisions. Often that data can be gathered without the assistance of new tools. Knowing when to use built-in tools, when to acquire new tools, and what to look for in new tools makes the entire process easier and faster.

I’ve also previously stated that not all network maps are created equally. Some are fast, inexpensive, and result in a reasonable representation of the network. But fast and inexpensive means there may be downsides like incomplete switch-port mapping. There are more expensive, elaborate, and time-consuming tools that will do this. But not every environment or situation needs this level of detail. You might not care about switch mapping for the task at hand. In the TMI example you could gather the data but it would make no difference in your findings. So there’s no benefit to doing it, and it might slow you down.

Deciding What Data to Gather

Choosing the right tool for the job can be more important than the actual buttons-and-clicks of the operational task. To choose the right tool you first need to know what data to gather. This is based on your goals, approaches, and requirements.

In the case of the TMI acquisition you need to determine whether the networks can be connected as-is. You know there are a few factors that go into this determination. You want to:

  • Identify computer and server naming conflicts
  • Identify IP addressing conflicts
  • Identify domain name and NetBIOS name conflicts

A large company might have a much larger list of factors. But for a small company like TMI that’s really about it. You don’t need an extravagant list of hosts, network ports, cabling, link speeds, wireless encryption protocols, etc. to make your determination. You need to know if the connection will break things, and these are things that will break.

Gathering the Data

I’m a big fan of doing the easy things first, of bringing strength against weakness. In this case, the easiest question to answer is the domain names. Simply sitting down at any current TMI user’s computer and looking at their current logon name will tell you whether they’re using local or domain logon, and if domain what the name is. For Windows XP, just tap ctrl alt del and you’ll see something like this:

Figure 1 - MAIN is the domain name.

When you see no domain name or a reference to a workgroup, you’ll see something similar to Figure 2. This example is from Windows 7 under Computer Properties.

Figure 2 - This system isn’t joined to a domain.

Either way, workgroup or domain, you’ve likely got everything you need to answer that question. If there is no domain name because users login to their local computers, there is no domain name conflict. If they do login to a domain, you must determine whether that same name is in use in your company. Using the same name would be a conflict and must be resolved before integration.

Now it is time to build a list of servers and computers. The critical task is gathering this data from every system connected to the TMI network:

  • Computer name
  • IP address

I could argue that gathering other configuration components like default gateway, Internet firewall, etc. are very important. But they don’t answer the questions that you are responsible for. So don’t get them yet.

Ideally you want a report that looks something like this one:

Figure 3 - A brief report that has everything you need for your task.

How do you create these reports? First you enumerate the network hosts using the fastest method you can come up with.

Enumerating Network Hosts

If your primary task is to list IP addresses and corresponding computer names you have lots of options. The most direct method is to walk to each computer and record the information in a spreadsheet. That might seem odd for a technologist to recommend, but if there are 5-10 computers to inventory, this is actually the shortest way.

For something more complex you want to check the network using some type of automation. First plug your laptop into the network and see if you are assigned a DHCP address. Write down your IP address, subnet mask, default gateway, and DNS server. Most times on small networks the default gateway is the DNS server and the switch or router. That makes your task far easier.

I’m using Windows 7 as my operating system so I can use the Network Map feature that’s built in to it. Under Control Panel I click Network Map and get a diagram like Figure 4, which shows part of my home network:

Figure 4 - A very basic and very fast network map.

A more detailed description of my network is available with just a few clicks. By choosing Click here to see all other devices and then using Details view I can display the network map shown in Figure 5.

Figure 5 - It looks like we’re done!

This is as close as you will get to a network map with built-in Windows tools. While it isn’t nearly complete, it is enough for you to complete your assigned task. You can determine from this whether the IP addressing scheme is compatible with your network, whether the computer naming scheme will cause conflict, and whether any domain conflicts exist.

On the other hand, you probably need a more detailed and consistent network mapping approach for most scenarios. While this is as far as you can get with a single Windows tool, you may want to cobble together a solution from PowerShell scripts, command-line loops, and so on. But creating your own network mapping tool probably isn’t a good idea. When your needs surpass the built-in Windows tools, you should consider adding a network mapping tool that meets those needs.

Limitations and Tool Selection

When it comes to rapid initial network mapping and basic environmental assessment the built-in Windows tools options that are available to you right now may meet your immediate needs. But in many cases you simply need more information than you can gather this way. The common tipping points that lead to using a tool are usually within these categories:

  • Remote site that is difficult or infeasible to travel to
  • Networks with hundreds of hosts, even if they’re in the same place
  • Complex network systems
  • Secure networks where you do not have access to some resources
  • Multiple segmented networks where data must be gathered separately and then aggregated for holistic analysis

When you encounter any of these situations you will probably need a tool. To decide what kind of tool to use there are a few guidelines to consider.

What data do you need the tool to gather? Using an enterprise-scale tool to gather IP addresses across a router is probably not as efficient as using a free or low-cost host-based tool.

How fast do you need this? Host-based network mapping tools are generally fast because they use simple methods and gather limited data. If that data meets your needs, you can stop there. If you’re not on a time limit, a larger tool deployed across the network can take days or even weeks to fully deploy and map the network. On the other hand, this tool will provide more data than you can imagine.

What’s your budget? The general rule in network mapping tools is that you get what you pay for. The more expensive the tool, the more robust and comprehensive data you will receive.

How secure is your network? Simple tools gather less information but in a fast and minimally intrusive method. The methods, like ping sweeps and ARP broadcasts, sometimes trigger network intrusion systems. Deployment-scale tools often either avoid security triggers or even alert the security systems to their presence to avoid false alarms.


There are numerous ways to build and maintain a network map. All of the approaches have some value and provide at least a little insight into what’s happening. Using the technique described here to leverage built-in Windows tools may help with short-term needs in small networks like TMI. But to be honest, most of the time your needs will exceed these built-in tools before you even have a chance to use them. It is a better investment of your time to select and learn more about a set of dedicated network mapping tools that work for your environment.