Some of the main topics in this chapter are
Everyone has experienced a shortage of capacity at one time or another--a needed resource in short supply at a critical moment.
Imagine, for example, that you need to move some boxes from your office to a location in another city that is one day's drive away. You hire some movers and a truck to do the job. After they arrive, however, you discover that the truck they brought is too small in which to fit all the boxes--you will need to make two trips (consequently, the delivery will be late). Not to be undone by this turn of affairs, you hire another truck. Unfortunately, you have a new problem: The first truck is blocking the driveway, and the second truck cannot begin loading until the first one has left. The boxes finally arrive at their destination, and your unsympathetic boss asks, "Why didn't you just get the extra large instead of the large in the first place?"
Capacity planning is an important part of network management. It prevents your network from running over capacity, which can stall your mission- critical applications.
In a networked environment, many variables affect the applications' capability to complete the work. The network infrastructure needs to be adequate and well designed. Application software has to be configured appropriately for your environment. The hardware on which you run Windows NT Server can make a dramatic difference in performance. Capacity planning is the task of anticipating the interaction of these components so that critical resources are available when needed.
Capacity planning is meant to answer questions such as:
This chapter teaches you how to approximate the impact of adding specific Windows NT-based services to your network. You also learn how to use the Network Monitor tool to observe the actual impact of your changes.
Capacity planning is an ever-moving target. Just about the time you think you have a solution that meets your business needs, one of two things changes: the needs of the organization or the technology. To stay one step ahead, you need a methodology for estimating demand and a tool for detecting changes in network usage.
Planning for the introduction of new applications or services consists of the following steps:
2. Determine the demand for application services, such as Web servers, database servers, and other client/server applications.
3. Optimize the delivery of the preceding services (determine hardware requirements for servers, minimize network traffic, and maximize performance of critical applications).
4. Forecast demand for the network and servers, based on the needs analysis performed in steps 1 and 2.
5. Measure actual traffic generated by the applications and services identified in the analysis.
6. If necessary, restructure your environment.
7. When in production, monitor the network performance levels on an ongoing basis to identify changes in demand or performance problems.
This chapter provides background information that you need to optimize and estimate the network load of common Windows NT Server services. Applications (such as database servers and Web servers) have their own optimization and capacity planning parameters that you should probably consider while making your purchase decision. The process of optimizing these applications is the same as for the basic Windows NT Server network services: Capture the traffic in a test environment, change your configuration to optimize the application, and then capture the traffic again until the network performance is optimized. Many server-based applications have significant tuning and optimization configuration options that must be carefully explored and tested before you can project how the application will work in a production environment.
TIP: After you've estimated your network capacity requirements, make certain that you at least double your estimate! You need the excess capacity to handle peak demands and unanticipated changes to your environment.
The first step is to understand the applications that demand resources on the network. The following sections provide information on the basic Windows NT Server network services, how to optimize them, and the amount of traffic they generate.
Whenever a client logs on to a domain or connects to a Windows NT system, a user authentication takes place in which the user's identity is checked against a security database (locally or on a domain controller). This section details the types of user authentication that occur on Windows NT systems, and then covers the options you can configure that affect their performance.
A user connects to a server that is a member of a domain by using a domain account.
A user connects to a server that is a member of a domain by using an account from a trusted domain (this requires two pass-throughs: the first from the server to its domain controller, and the second from the domain controller to a domain controller in the trusted domain).
An authentication request fails at a BDC (Backup Domain Controller) because of a password mismatch (the BDC verifies the password with the PDC (Primary Domain Controller) before denying the request).
The Logon Process. In a single domain environment, the process of logging on to the domain consists of the following steps:
2. All available logon servers respond (if via broadcast), or the WINS server responds with a list of up to 25 logon servers (if via the WINS client).
3. The client sends a logon request to all identified logon servers.
4. The client selects the first response from the logon servers in Step 3, and continues the logon process with that server.
5. Logon scripts, user profiles, and system policies are processed at the client.
6. The client terminates its session with the server.
The domain model that you select has an impact on the performance of this process.
The Effect of Domain Design on Performance. In general, the number of domains required by an organization is determined by how the system is managed. Although operational considerations such as the location of domain controllers are affected by the network design and location of the systems, a domain is essentially an administrative unit of control--a group of systems that share a command account database. A domain can be as small as a single system or as large as one that spans the globe with thousands of user accounts. The number of domains that you need is determined by the number of separate account databases that are needed to achieve the desired security administration context.
In the single domain model, a single domain account database is used by all Windows NT systems in the network. A single group of administrators manages a single, shared account database. All users log on with accounts stored in a single account database.
In the master domain model, the domain database is partitioned into several separate account databases that can be managed independently of one another. A single domain database (the master domain) contains the user logon accounts for all users. Servers are grouped into resource domains, however, that can be administered by a different group of administrators than the ones in the master domain. Master domain user accounts can be authenticated by servers in the resource domains via pass-through authentication. Placement of Domain Controllers. In a LAN environment, one that has high-speed connections between all the systems, a single domain controller (the PDC) can satisfy all client logon requests and all pass-through authentication requests from member servers. At least one BDC is desirable for fault tolerance--users could still log on with domain accounts even if the PDC is down--and a large account database might require multiple domain controllers to handle the amount of authentication traffic. In addition, if there are slow links in the network, or if it's desirable to segment the logon traffic, a BDC should be placed on each remote network.
In an environment that has implemented the master domain model, all users log on with accounts from the master domain. In that respect, the need for domain controllers is the same as it is in a single domain environment. In addition, domain controllers are needed for the resource domains in all locations their accounts are referenced.
To see how pass-through authentication works in this environment, refer to Figure 40.1, where a trust relationship exists in which Domain1 trusts Domain2. A user sits down at computer A to log on with his account from Domain2. The following occurs:
2. System B cannot validate the request either, so it passes the request to a domain controller in Domain2, System C.
3. System C sends a response to System B, which responds to System A.
If a user logs on at System A by using an account from Domain 2, the logon request travels from System A to System B, across the slow link to System C and back again.
To avoid the pass-through authentication traffic crossing the slow links in your network, use a BDC for the master domain in each location. Domain Synchronization. If you have multiple domain controllers that are spread out over a Wide Area Network (WAN), the synchronization of the account database becomes a significant issue. In a Windows NT Server domain, the PDC maintains the master copy of the directory services database; each BDC has a copy. The Windows NT component responsible for keeping these copies of the database synchronized is the NetLogon service. When a domain synchronizes, the PDC sends out a message (called a pulse) to the BDCs to notify them that changes are waiting. The BDCs then connect to the PDC to get the changes.
Although the traffic generated by this process usually only consists of the changes to the database, a full synchronization can occur if the BDC is too far out of date, a new domain controller is installed, or the domain is synchronized in Server Manager. If the database is small, the amount of traffic is minimal. With thousands of user accounts, however, the traffic can easily turn into megabytes of data to transfer.
The key factors to consider when planning the domain synchronization process are:
Domain Controller Hardware Requirements. To handle logon authentication requests most efficiently, you should add enough memory to the domain controllers to accommodate the entire account database in RAM. If memory is a bottleneck, do not use the system as a file or application server; use it as a domain controller only.
The size of the account database depends on the number of user accounts, group accounts, and computer accounts in the domain. Table 40.1 shows the amount of space taken by each of these types of accounts in the database.
| Object | Space Used |
| User Account | 1024 bytes |
| Global Group Account | 512 bytes plus 12 bytes per user |
| Local Group Account | 512 bytes plus 36 bytes per user |
| Computer Account | 512 bytes |
Thus, an account database with 1,000 users and 1,000 computers has an account database size of a little over 1.5M.
The size of the Security Accounts Manager (SAM) database is limited by the maximum size of the Registry. The Registry can not exceed 80 percent of the PagedPoolSize (the paged pool is the set of memory pages used by the operating system components that can be paged to disk). Because the PagedPoolSize is limited to no more than 128M, the entire Registry, including the SAM database, cannot exceed 102M.
Microsoft's guidelines for the hardware configuration of domain controllers is listed in Table 40.2.
NOTE: Microsoft has tested SAM databases larger than 40M; with existing hardware, however, the amount of time needed to load the database into memory during startup is unacceptable in a production environment. Improvements in hardware performance might provide acceptable performance for such large databases in the future.To put this hardware limitation in perspective, Microsoft recommended a maximum size of the SAM database of 10M for Windows NT 3.1. The increase in the recommended maximum to 40M is purely due to the availability of new hardware.
Table 40.2 Microsoft's Recommended Hardware for Domain Controllers (all sizes in MB)
| Number of Users | SAM Size | Registry Size | PagedPool Size | CPU Needed* | Pagefile Size | RAM |
| 3000 | 5 | 25 (default) | 50 (default) | 486DX/33 | 32 | 16 |
| 7500 | 10 | 25 (default) | 50 (default) | 486DX/66 | 64 | 32 |
| 10,000 | 15 | 25 (default) | 50 (default) | Alpha | 96 | 48 |
| 15,000 | 20 | 30 | 75 | Alpha | 128 | 64 |
| 20,000 | 30 | 50 | 100 | Alpha | 256 | 128 |
| 30,000 | 45 | 75 | 128 | Alpha | 332 | 166 |
| 40,000 | 60 | 102 | 128 | SMP | 394 | 197 |
| 50,000 | 75 | 102 | 128 | SMP | 512 | 256 |
How many domain controllers are needed? Table 40.3 gives Microsoft's recommendations for a single domain. The table assumes that high-speed connections exist between the clients and the domain controllers.
Table 40.3 Recommended Number of Backup Domain Controllers
| Number of User Accounts | Number of BDCs |
| <2,000 | 1 |
| 5000 | 2 |
| 10,000 | 5 |
| 20,000 | 10 |
| 30,000 | 15 |
You should, however, seriously consider additional domain controllers. If your database is not large, the processing overhead of being a domain controller is not very much, so you can add the domain controller role to one or more file servers and gain additional fault tolerance on logon authentication (users can still log on if your other domain controllers are down). As the size of the account database increases beyond 1,000 users, however, performance becomes a major issue.
Another consideration is the physical topology of your network and its available capacity. If clients have to cross a slow link to log on, and that link is consumed by some other network task, user logons could fail. The solution is to locate a BDC on the other side of the link to service logon requests.
Configuring the NetLogon Service. To configure the behavior of the NetLogon service, you can change the Registry values for the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters
Several of the values might need to be adjusted for remote BDCs in a WAN environment. Options to configure include:
The Directory Replication service in Windows NT Server synchronizes directories and files among multiple Windows NT systems. You designate a system as the export server and then configure your other NT systems as import servers. The Directory Replication service then ensures that the directories on the export server match exactly with those on the import servers. As files are changed, added, or deleted from the export computer, they are changed, added, or deleted from all the import computers.
This service is extremely useful for maintaining certain kinds of read-only files that need to be accessed by a large number of systems. Directory Replication can be used to replicate logon scripts, mandatory user profiles, and other relatively small files that need wide distribution. Directory Replication is not designed, however, for distributing large numbers of files with ensured delivery; for that kind of job, you need a software distribution application such as the Systems Management Server that is part of Microsoft BackOffice.
The Registry parameters for the Directory Replication service are located in the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Replicator\Parameters
To control the amount of directory replication traffic, you can change the following values:
The Server service provides the Windows NT Server file and print services. To provide adequate file services performance, it is important to size the amount of RAM and disk space on the server.
The general rule of thumb on memory for Windows NT Server is this: The more the better! Windows NT uses all available RAM for applications and caching of the disks automatically. This is important for file servers because the bottleneck on file servers is typically the disk (and a lack of memory to cache disk requests).
The base operating system requires 16M of RAM. You need to add to that amount enough RAM to enable all applications executing on the server to be resident in RAM (that is, not paged to disk) and to enable all open data files to be present in the cache. The total memory required is the sum of the three: 16M + total data files opened by clients + total executables being run from the server. This amount enables most disk requests to be satisfied from pages of memory resident in RAM.
The disk space requirement for a file server consists of the applications that will be stored on the server plus a budgeted amount of space per user (again, you need to at least double your estimates!). The boot partition needs enough space for the operating system and a generous swap file (150M + RAM + 12M). If you have basic productivity applications stored on the server (250M), for example, and allow 10M of personal storage for your 200 users (2 GB), you should estimate space for the server at 4.5 GB for data (2.25 GBx2).
The memory and disk performance counters need to be monitored closely on file servers because changes in user habits can quickly change the demands on the server.
The Browser service enables a Windows NT system to maintain a list of available servers on the network and provide the list to clients when needed. Every workgroup on every subnet has a system playing the role of master browser for that subnet. In a domain, a master browser resides on each subnet, with the PDC as the domain master browser responsible for maintaining a domain-wide list.
The browsing process takes place on every installed protocol. Servers announce themselves on every protocol, and clients request browse lists on every protocol. A major savings in the overhead for browsing can be realized, therefore, if you limit the number of protocols being used on the network.
Another process that produces network traffic is the election process. If a master browser is no longer available, an election takes place to determine a new master browser. By configuring a system on each subnet to be the preferred master browser, you can reduce the traffic generated by elections.
You can also configure servers so that they do not announce themselves on the network. To turn off these announcements, enter the following command at the command prompt on the server:
net config server /hidden:yes
Two services available on Windows NT Server that support TCP/IP environments are the Dynamic Host Configuration Protocol (DHCP) Server service and the Windows Internet Naming Service (WINS) Server service. The configuration of these services can significantly impact network traffic.
Dynamic Host Configuration Protocol. The Dynamic Host Configuration Protocol (DHCP) is a mechanism by which network clients using the TCP/IP protocol can get an IP address from a server dynamically instead of having a user-configured address. An administrator configures the DHCP server with a set of valid IP addresses, along with a lease length. Clients can then lease addresses from the server. After the client's lease expires, the address can be returned to the pool and leased to another client.
The process of leasing an address from a DHCP server consists of these major steps:
2. The DHCP server offers the client an address.
3. The client accepts the offer.
4. The DHCP server acknowledges the transaction and specifies a lease length for the address.
DHCP configuration issues include:
Windows Internet Naming Service. The Windows Internet Naming Service (WINS) provides IP address to NetBIOS name resolution. WINS maintains a dynamic database of IP addresses and their associated NetBIOS name registrations. Rather than using LMHOSTS files, clients can query a WINS server for IP addresses. This feature enables clients to log on to a Windows NT domain even if there is no domain controller on the local subnet. The client queries the WINS server for the addresses of domain controllers and logs on by using directed datagrams.
A WINS Proxy Agent is a system that monitors network traffic for non-WINS client address resolution broadcasts. When a non-WINS client makes such a broadcast, the WINS Proxy Agent queries the WINS server and then responds to the original broadcast with the requested host IP address.
WINS configuration issues include:
Table 40.4 is a summary of the configuration options to review for each Windows NT Server network service. Table 40.5 shows the approximate amount of traffic generated by various network functions. The numbers given for number of frames and number of bytes are just examples captured on a specific network; the numbers vary depending on your network media and server configuration.
After you have optimized these services, you can predict the incremental impact of adding clients or services to the network. You can gather performance statistics such as these by using Network Monitor and Performance Monitor.
| Service | Configurations to Review |
| Domain Synchronization | Modify the Registry settings on the BDCs for the following values: ReplicationGovernor, Pulse, PulseMaximum, and PulseConcurrency. Review domain model for possible changes to domains and trust relationships. Monitor synchronization of remote BDCs to ensure they're complete within the desired time frame without excessive bandwidth utilization. |
| Logon | Use WINS for resolution of address for domain controllers. Limit the number of network protocols installed. Ensure that all domain controllers have adequate RAM and CPU for the size of the directory services database. If domain controllers are functioning as other kinds of servers (file servers, application servers), monitor performance to ensure that spikes in demand for other services do not affect logon availability. Move applications to another server if necessary. Ensure that all clients have a high-speed network connection to a domain controller in their domain and all trusted domains. |
| Pass-Through Authentication | Minimize the number of domains if possible. Minimize the number of loaded network protocols. Minimize the number of trusts active on the network. Ensure that pass-through authentication does not have to go through slow links; position BDCs of trusted domains on each network where the accounts have to be referenced. |
| Directory Replication | Modify the Registry settings for the Interval and GuardTime values to accomplish
the desired frequency of replication. Restrict replication to a small number of read-only files. Place other files in a shared location on a server. |
| WINS | Make certain that each client and server is registered in WINS to minimize broadcasts
for IP address to NetBIOS name resolution. Locate WINS servers so that each client has a high-speed network connection available to their primary WINS server (that is, minimize WINS queries across slow links). Adjust the replication of the WINS database between Push and/or Pull partners. Use WINS proxy agents where appropriate. |
| DHCP | For ease of administration use DHCP to lease addresses instead of manually assigning
them. Make certain that no DHCP scopes overlap. Configure as many TCP/IP configuration options as possible with DHCP. Set the longest practical lease length on each network to minimize renewal traffic. |
| Browser | Limit the number of workgroups on the network. Limit the number of network protocols installed. Configure the following Browser Registry values: MasterPeriodicity and BackupPeriodicity. Configure a system to be a preferred master browser on each subnet where no NT domain controllers exist. Configure systems that have minimal resources so that they do not maintain a list of servers MaintainServerList=no. Disable the server announcements on systems that do not need to appear in the browse list. Monitor the browse servers by using the Browser Monitor utility in the Windows NT Resource Kit. |
| Service | Description | Frames | Bytes | Frequency |
| DHCP | Acquire IP Address | 4 | 1,368 | Once per client |
| Renew IP Address lease | 2 | 684 | Every startup and at 1/2 Lease Life | |
| WINS | Registration | 2 | 214 | Once per service or application at startup |
| Renewal | 2 | 214 | Once per service or application every 1/2 TTL | |
| Resolution | 2 | 196 | Varying frequencies | |
| Logon Validation | Preparation | 15 | 2,000 | Once per user logon |
| Validation sequence | 4 | 760 | Once per user logon | |
| Session breakdown | 5 | 360 | Once per user logon | |
| Scripts, policies, profiles | varies | Once per user logon | ||
| Browser | Host Announcement | 1 | 243 | Once per `server' computer every 12 minutes |
| Local Master Announcement | 1 | 250 | After each Announcement Request or Election | |
| Workgroup Announcement | 1 | 250 | Every 15 minutes | |
| Elections | many | 235 | After each computer capable of becoming the master browser initializes | |
| Finding a backup browser | 2 | 450 | Once per browsing computer at initial browse attempt | |
| File Sessions | Address resolution | 2 | 120 | At each attempt to communicate with another TCP/IP host (when aged from ARP cache) |
| TCP Session | 3 | 180 | Once per first connection to each target TCP host | |
| NetBIOS Session | 2 | 186 | Once per first NetBIOS connection to a target computer | |
| SMB Protocol Negotiation | 2 | 350 | Once per first SMB connection to a target computer | |
| Connection Sequence | 2 | 350 | Once per network resource access | |
| Session Disconnection | 5 | 360 | Once per final connection to TCP host has been disconnected | |
| Directory Services Database Synchronization | Finding the PDC | 4 | 545 | Once per BDC bootup |
| Establish session | 11 | 1,200 | Every synchronization event | |
| Establish secure channel | 8 | 1,550 | Every synchronization event | |
| Verify the databases | 6 | 1,350 | Every synchronization event | |
| PDC Update notice | 1 | 400 | Every synchronization event | |
| Establishing a Trust Relationship | 100 | 15,000 | Once per each trus trelationship created | |
| Importing Trusted Accounts | 100 | 24,000 bytes of traffic for 11 trusted accounts | Each attempt to import a trusted account into a trusting domain | |
| Pass-Through Authentication | 20 | 3,700 | Once for the first attempt to access a resource on a trusting computer, or logon to a trusted domain from a trusting computer | |
| Directory Replication | Announcement | 1 | 340 | Once per importing domain or server for every update of the export tree |
| Establish session | 9 | 1,300 | Once from each import server every update event | |
| Verify directory | 22 | 3,700 | Once from each import server every update event | |
| Update directory | varies | Once from each import server every update event | ||
| WINS Replication | Database verification | 12 | 900 | Once per update request to each replication partner |
| Database update | 14 | 2,100 varies | Once per update request to each replication partner |
After you have identified the services that need to be delivered, the next step is to measure and analyze the actual activity on the network. Two tools that provide the information you need are Performance Monitor and Network Monitor.
Performance Monitor can give you some basic statistical information on overall network traffic, including the percent of network utilization and the number of broadcasts and multicasts.
The Network Segment object and its counters become available to measure after you install Network Monitor Agent, as shown in Figure 40.2. If your system has multiple network interfaces, each interface appears as a separate instance and can be monitored separately. The counters that you can monitor include:
After you install Network Monitor Agent, the Network Segment object becomes available to monitor.
These counters provide overall indicators of the volume of traffic on your network. The % Network utilization tells you what percentage of the bandwidth of the physical network is in use, and the Total bytes received/sec tells you the throughput.
NOTE: To install Network Monitor Agent and make these counters available, open Control Panel, Network, and then choose the Services tab. Choose Add and then choose Network Monitor Agent from the list of possible components.
It is a good idea to watch the utilization of your network on an ongoing basis to detect changes in network traffic. To capture the data that you need for basic trend analysis, use the logging capabilities of Performance Monitor to create a log of network demand and save it to disk. Log the activity at various times of the day to get a picture of the peaks and valleys in network demand. For more information on how to log activity on remote systems, see the section titled "Monitoring Performance on a Remote Computer" in Chapter 38, "Monitoring NT Server."
The data that you log can be exported from Performance Monitor and then imported into a spreadsheet or database program for further analysis. An effective graph of the increase in network activity is useful when you need to convince your manager to buy new network hardware.
TIP: An effective and inexpensive way to display the network activity on all your networks without any dedicated hardware is to install Network Monitor Agent (which comes with Windows NT) on a system on each network. You can then use the Performance Monitor to display the activity on each network by adding counters to your chart or report for each computer.
To minimize the performance drain on the system running Performance Monitor, use the Report view, add as few counters as possible, and increase the update interval (every 20 seconds would be reasonable).
The other tool that you can use to provide information on network activity is Network Monitor, a software-based network traffic and protocol analysis tool included in Microsoft Systems Management Server and Microsoft BackOffice. A version of Network Monitor is included with Windows NT Server 4; however, it has limited capabilities. It does not capture all network traffic. It can only be used to capture the activity to and from a particular server. Although this chapter describes the more powerful SMS Network Monitor tool's capabilities, the steps to capture and view network traffic are the same for both. By using Network Monitor, you can:
In addition to using Network Monitor to analyze network traffic for capacity planning impacts, there are two other good reasons to get to know this tool:
NOTE: A version of Network Monitor is included with Windows NT Server 4; however, it has limited capabilities. This version does not capture all the network traffic and can only be used to capture the activity to and from a particular server.
For more information on how to use Network Monitor, see the "Using Network Monitor" section, later in this chapter.
This is how the Network Monitor window looks after capturing data.
TIP: A good way to observe the actual behavior of your servers and clients is to set some representative systems on an isolated test network that emulates your production environment. You can then use Network Monitor to capture and analyze the network traffic. The limited number of frames generated on a small test network makes it easier to isolate and measure changes in traffic in your test configurations. Often, you discover traffic that you need to eliminate, such as client broadcasts to resolve IP addresses. You can then extrapolate your experience in the test environment to the larger number of clients and servers on the production network.
After capturing network traffic and statistics on a test network, the next step is to optimize traffic for the various services present on your test network. You are looking for traffic that can be reduced or enhanced by changing the configuration of either the physical network or the software components involved.
The contents of the network trace provide information on how the software components are working. Are servers announcing themselves correctly to enable browsing? Are clients that need addresses from a DHCP server able to locate a server? How are IP addresses being resolved for host names? Looking at the individual frames in the network trace provides this information.
The first thing to determine is whether your test environment met all your production requirements. Questions to ask include:
At this point, you need to ask, "What can I change that will make a difference in performance?" A number of potential strategies for optimizing the basic NT network services were listed in Table 40.4. In addition to these Windows NT optimization issues, you should consider the physical layout of the network--whether it matches the capacity and speed requirements of your applications. In particular, at this stage, you need to consider the impact of subdividing the network or addition of other kinds of network devices to determine if they will enhance network performance enough to justify the cost.
Some additional strategies that could be used to address various performance problems include:
If the network configuration needs to be modified to support your new applications, now is the time to test the new configuration to see the impact made by the changes.
After your applications are in production, you need to evaluate the network performance on a regular basis to determine how the demand for network services has changed. The Performance Monitor and Network Monitor are again the best tools for the job. To support your ongoing network analysis, you should:
Network Monitor consists of two components that can be installed on the same system or on two different systems:
To capture all the frames on the network, the network interface has to support a promiscuous mode. A list of supported network cards is available on Microsoft TechNet or on Microsoft's Web site.
To install Network Monitor Agent on a Windows NT System:
2. Choose Add Software.
3. Select Network Monitor Agent from the list of available components and
choose OK.
After closing Control Panel, a prompt appears for you to restart the computer. Network Monitor Agent is now installed as part of the network components on the system. After restarting the system, you're ready to install the Network Monitor user interface on the system that displays the network data.
NOTE: Certain versions of Network Monitor work on Windows for Workgroups and Windows 95 clients. These are found on the Systems Management Server CD in the NETMON directory.
To install the Network Monitor tool:
2. Locate the SMSSETUP directory on the CD. It's either SMSSETUP off the root directory (SMS CD) or the \SMS12\SMSSETUP directory (BackOffice CD).
3. Run Setup.
4. When prompted for which components of SMS to install, select Admin Tools.
5. Choose Custom. Remove all the suggested components (such as the SMS Administrator) from the list except for the Intel Network Monitor. Choose OK.
After setup completes, you're ready to run Network Monitor from the Systems Management Server program group.
After you start Network Monitor, it displays the Capture window, which reflects the contents of Network Monitor Agent's capture buffer. At this point, no data is being captured. To start capturing data, choose Capture, Start (or press F10). The Network Monitor application then instructs Network Monitor Agent to begin capturing network frames. As data is captured, activity appears in the Capture window showing statistics on the network activity (see Figure 40.4).
The Network Monitor window here is shown after a capture.
While the capture is running, each frame on the network is copied into a capture buffer on the system running Network Monitor Agent. When the buffer is full, the capture stops automatically. To change the size of the buffer from the default size of 1M, choose Capture, Buffer Settings and then type a new size. Be careful not to set the buffer size larger than the amount of physical RAM on the system, or else network frames can be dropped while the contents of memory is paged out to disk.
Before you can look at the actual data, though, you have to stop the capture. To stop the capture process, choose Capture, Stop.
TIP: You might find that Network Monitor cannot capture all the frames on your network (indicated by the number of Frames Dropped), depending on the capabilities of your network card and other activity on your system. To minimize the number of dropped frames, choose Capture, Dedicated Capture Mode. Network Monitor runs minimized with little screen update.If frames are being dropped even when using Dedicated Capture Mode, consider running Network Monitor at a higher priority with the start command or upgrade your network adapter. To start Network Monitor at the highest possible priority, enter the following at a command prompt:
start /realtime netmon
Running Network Monitor at the real-time priority negatively affects performance of other tasks on the system, so you don't want to use this technique on a server. Instead, use an idle client system to perform the network capture.
Understanding the Display. The Capture window in Network Monitor is divided into four areas, or panes, displaying statistical information about the captured traffic. These four areas are (clockwise from upper left):
TIP: Double-clicking a column heading in the Station Statistics or Session Statistics pane sorts the display in descending order. To see which network address sent the most bytes on the network during the capture, for example, double-click the heading of the Bytes Sent column in the Station Statistics pane.
Resolving Hardware Addresses to Computer Names. The network addresses displayed in the Capture window are the hardware addresses (or MAC or NIC addresses) of the network interfaces. Network Monitor can search the frames in the capture for any frames that include computer names, and then display the name rather than the hardware address. To do this, choose Capture, Find All Names. Network Monitor adds any names that it finds to an address database. You can display or edit the names in the database by choosing Capture, Addresses.
TIP: If you already have a database of hardware addresses for your network, you can load these addresses into Network Monitor's database by choosing the Load button in the Addresses dialog box.
Saving the Captured Data to Disk. To save your captured data for later analysis, choose File, Save As. Capture files, which have a .CAP extension by default, are binary files that contain the frames from the capture.
Another way to save the capture is to choose File, Print and then choose the File option to put the captured data in a text file (see Figure 40.5).
The Print dialog box has the Advanced options displayed.
After you've finished capturing data, you can view the contents of the frames by choosing Capture, Display Captured Data (or pressing F10, or clicking the toolbar button that looks like a pair of glasses). The Capture window displays a list of the captured frames, showing the source and destination addresses, the protocol used, and a description of the frame contents.
To get more details about a particular frame, double-click the frame in the list. The window splits into three panes (see Figure 40.6). The Detail pane parses the frame into its component parts, and the Hex pane shows each byte in hexadecimal notation.
The display of captured data shows the Summary, Detail, and Hex panes.
When you capture data in Network Monitor, every frame is captured by default, regardless of whether it's relevant to what you're testing. You can have Network Monitor sift through the frames and limit what is displayed by using a filter. Filters can be applied after you capture the data, or you can define them before you perform the capture to reduce the amount of data collected. In Figure 40.7, only frames that are broadcasts for one of the listed protocols appear after the filter is applied.
To create a filter, choose Display, Filter (or press F8). The Display Filter dialog box appears (refer to Figure 40.7). You can filter the data by specifying the addresses, protocols, or any data contained within the frame. To add an expression to the filter, choose Expression. The Expression dialog box appears, enabling you to choose the specific criteria for the filter (see Figure 40.8).
Filters can be saved to disk and then loaded when needed from the Display Filter dialog box. Filters have a .DF extension by default.
TIP: If you're viewing the captured data with a filter applied, you have a new option available in the Save As dialog box: the Filtered option. If you enable this check box, only the frames displayed are saved to disk; all other frames are ignored.
If you have a specific focus for your capture, such as the conversation between two systems or the traffic generated by a specific application, you can create a filter and then use the filter to capture only the data that you want instead of all the network frames. Using a filter this way can dramatically cut down on the size of the buffer needed by Network Monitor, especially on busy networks.
A filter enables you to limit your view of the capture to the frames that you specify.
The Expression dialog box enables you to select the network frames you want to display, based on the destination address, protocol used, or other information contained within the frame.
You create a filter for the capture process in the same way that you create a display filter. Choose Capture, Filter and then create the expressions that you need to select the type of frames to capture.
To capture the network activity on a remote network, you must first install Network Monitor Agent on a system on that network. On Windows NT systems, Network Monitor Agent is installed as a service set to start manually. Before you can capture data on the remote system, you must make certain that this service is started. You have three options for starting the service:
After the service has been started, you're ready to connect to the agent from Network Monitor. Choose Capture, Networks to display a list of network interfaces on this system. To specify a different system to perform the capture, select REMOTE from the list, and then choose Connect. The Connect to Network Monitoring Agent dialog box appears (see Figure 40.9). Type the agent's computer name and an update frequency, and then choose Connect. You're now ready to start capturing data on that remote computer.
The Connect To Network Monitoring Agent dialog box enables you to capture activity on remote networks by connecting to a Network Monitor Agent on that network.
No visible sign that a capture is running appears on the capturing computer. The summary information is sent from the agent to the system running Network Monitor at whatever update frequency is specified. Upon exiting Network Monitor, the session with the agent is disconnected and the data in the capture is discarded, so be certain to save the capture to a file before exiting if you want to keep it.
© Copyright, Macmillan Computer Publishing. All rights reserved.