Familiarizing Yourself with an Existing Windows 2000 Network
Although having complete control over how a network is set up would be nice, inheriting an existing network from somebody is far more typical than building one from scratch.
Whenever you walk into a strange situation, you must first get a sense of what's on the network and how the individual pieces fit together to form a network. Only then should you start pondering the possibility that you may benefit from changes to the current status quo. This statement is especially true if the network that you inherit is working acceptably — in managing networks, "If it ain't broke, don't fix it" is surely enshrined somewhere near the top of the list of networking rules that you break only at your own risk!
You can take a few steps toward capturing the status quo.
Who's on first? What's on second?
First things first: With any network new to you, you need to know how it's addressed (which doesn't mean whether you should call it "Sir" or "Madam"). You need to understand what kinds of addresses are in use — for example, private IP addresses or public IP addresses allocated from a service provider or some other public pool.
You also need to understand whether any particular IP addresses denote certain network functions. For example, on one TCP/IP network, routers (also known as default gateways in TCP/IP terminology) often own the .1 address for any subnet Therefore, for the Class B Private IP network 172.16.0.0, the router interface for each subnet may be identified as 172.16.0.1, 172.16.1.1, 172.16.2.1 (assuming that this address uses a subnet mask of 255.255.255.0).
The important thing is to capture all network addresses in use and to do what you can to extract any underlying logic that determines how certain kinds of addresses were assigned in the past.
Documenting your circumstances
For all important network devices — and this category includes at least all servers, hubs, routers, and communications devices (such as modems, cable modems, and so forth) — you need to document their current settings and configurations so that you can check these settings if the devices have problems. If you're lucky, your predecessor's already compiled this information for you. In that case, all you must do is check that information against the machines that it purports to represent.
If you have no such records, you must build them. On Windows 2000 machines, you can use the System Information utility to take a complete snapshot of such machines; on other computers, you must rely on the utilities that they support to tell you about themselves or you must root this information out manually. This process involves some real work, but it's the only way to establish exactly what you're dealing with on the systems and components that make up your network. Think of it as your "shakedown cruise" as you familiarize yourself with your local networking environment.
Keeping an inventory of your systems
Especially concerning network servers, documenting which operating systems they're using, what applications and services they support, and how they're configured to support the various user communities in your networking neighborhood is important. This information is essential for many reasons but is absolutely crucial because it does the following:
- Outlines the kinds of things that your servers can do and, therefore, what its users expect them to do on an ongoing basis.
- Helps you analyze the kinds of workloads that individual servers are handling, based on the number and kinds of services that each server currently supports.
At the same time, you probably want to dig into each server's event logs — keeping a keen eye on the kinds and frequencies of errors that may be occurring. Similarly, you want to observe network traffic loads over time and do some performance baselining to try to get a sense of how heavily used your various servers are. Such observations help you identify which servers may be likely candidates for upgrades or replacements or that may benefit from reducing current processing loads.
Knowing your community
By examining the local and global groups within a domain that you manage, you can discover a great deal about the organization that such groups are designed to service. By examining the user rights and access privileges associated with such groups, you can also determine what kinds of information each group owns and controls and what kinds it's allowed to access at lower levels of privilege.
Mapping this information and identifying individuals who belong to such groups also gives you the chance to see how many job roles individuals typically fill and the chance to look for inconsistencies and inefficiencies. At this point in your survey, don't give in to the temptation to change things or clean them up — all you're doing right now is looking around to help you understand how the world as your users and organization know it operates.
Documenting file systems
For all your network servers, you want to capture information that describes their file systems. This information includes the following data:
- Snapshots of each server's partition table.
- For each logical disk volume, its size, drive letter, layout (RAID 0, RAID 1, RAID 5, and so on), and type (FAT, FAT32, NTFS, or other).
- A snapshot of the directory tree for each logical disk volume, which can also prove helpful.
Documenting your local topology
With a collection of network addresses in hand, you can usually recognize those devices that are "multihomed" (those with multiple interfaces and, therefore, multiple network addresses as well) to create a local map of how your network is laid out. This map also shows you the paths that traffic follows to route information from local users to the Internet or other external connections and vice versa. Build yourself a diagram of your network from this data and identify all routers, hubs, and multihomed servers, because they control how traffic moves around within your network.
Try to identify routing protocols and routing regions on your network as well, particularly important, high-traffic areas such as backbones and Internet connections. A good understanding of your network's layout helps you troubleshoot problems should they occur and helps you plan for growth and change.