Identifying the Current System Implementation | MCSE: Windows Server 2003 Active Directory and Network Infrastructure Design Study Guide (70-297)

Most organizations will already have some type of network and administrative infrastructure in place. This could range from a simple peer-to-peer network where the users control their own resources, to a large multinational corporation that uses several different directory services. If you understand the current design, you will have an easier time making design decisions for the new Active Directory model.

You should also note any other projects that are currently in progress. It is rare that an organization can put everything on hold while a single project is put into place. Although it would be nice to have everything halted until Active Directory is in place and the network infrastructure is optimized, in reality we know that is not going to be the case. Make sure you investigate the changes that every project will bring and document the additional resources that will be required.

Determining Organizational Requirements

Businesses make decisions to implement a directory service and network infrastructure for many reasons. Those reasons could be as simple as a software requirement, or as complex as a need to restructure their organization s resources into one simple functional design. No matter the reason, a solid, stable infrastructure depends on a well thought out and documented design.

Several operating system and directory service vendors are on the market. Existing systems are usually put into place due to an organization s needs. Depending on the available software and hardware at the time of the installation, a company could have several vendors products in place. If you are lucky enough to be assessing an organization that designed their infrastructure from the ground up and used a systematic approach when they integrated any new technologies, your job will be much easier than if a hodge-podge approach was taken. More often than not, however, the hodge-podge approach is what you will find. Administrators are often under the gun to implement a process that allows the users to perform their jobs. At the same time, they are responsible for the usual day-to-day activities. Quick tests of the new applications needed for the process may be run, sometimes not, and then the new system is let loose. The users begin running the applications, and when problems occur, the troubleshooting process begins. This cycle continues until the process works within the environment.

Note

When reviewing the case studies that are presented during your exam, you will not find many questions, if any at all, that ask what type of administrative models are being used within the organization. The same is true with determining the current organizational requirements; few, if any, questions will be presented on the exam. However, you must be able to interpret the information that is presented so that you can make the correct design decisions.

Determining the Reason

The reasons for moving to, or implementing Active Directory, are varied. Some companies simply buy into the Microsoft hype and have decided that they need to join the crowd . Others need to implement Active Directory due to software requirements, such as Exchange Server 2003. Still others have decided that their current implementation of a directory service will no longer meet the needs of the organization and are adopting a single directory service design or restructuring their current implementation. You need to determine the most important reason.

Although there may be multiple reasons, the design needs to take into account the highest priority and build around it. When decisions need to be made, they should be based on the highest priority if there are any tradeoffs. The decision criteria will include domain restructuring, application support, planned obsolescence, and total cost of ownership.

Domain Restructuring

Domain restructuring is becoming a very common reason for developing a design. Numerous companies have Windows NT 4 in their organizations. Due to limitations within the Windows NT 4 domain capabilities, these companies have several domains built with trust relationships interconnecting them. Because Active Directory has the ability to support millions of objects and has more efficient administrative capabilities, the domain structure can be collapsed to allow objects from quite a few NT 4 domains to reside within a single Active Directory domain.

Application Support

Active Directory is an extendable database . An extendable database allows you to add objects and attributes to the default schema so that you can have a central repository for application support. Windows 2000 introduced this to the Microsoft networking environment, and software vendors started supporting this ability. Exchange Server 2003 is an application that takes advantage of the extensible nature of Active Directory. Thousands of additional attributes , which are the objects that define a class, and hundreds of classes are added to, or modified within, Active Directory to support Exchange Server 2003. Exchange then takes advantage of Active Directory as the directory service for which it uses to replicate information between Exchange servers and look up recipient and distribution list information.

If an organization is building its directory service infrastructure around the need to implement an application, the ramifications of throwing a design together may not be readily apparent. You will need to stress the importance of a careful design. The Domain Name System (DNS), Active Directory, and Organization names are extremely important and can cause problems in the future if they are not chosen correctly. For instance, if you have not registered your domain name with Internet Corporation for Assigned Names and Numbers (ICANN), and you want to use this name as your Internet presence, you will not be able to if someone has already laid claim to it. As the directory service expert, it will be your responsibility to educate the powers that be.

Planned Obsolescence

Many companies are faced with the inevitable loss of support for the legacy operating systems. As these older operating systems, such as NT 4, reach the end of their lifecycle, companies have to spend more money to keep support contracts on them. Microsoft does not release very many hotfixes or service packs for these older operating systems, which makes them subject to attacks that newer operating systems are protected from. As companies start to fear that they will no longer have support for their operating system, they are looking to upgrade to another operating system that will be supported for several more years .

Total Cost of Ownership

Total cost of ownership (TCO) is a marketing point that Microsoft likes to push, and rightfully so. TCO is based upon not only the tangible costs associated with purchasing the hardware and software, but also the intangible costs of supporting the hardware and software, such as the portion of the administrator s salary that is associated with controlling, troubleshooting, and supporting a system. If designed correctly, and administered efficiently , Active Directory can save a company s budget when it comes to efficient management and support. One example is its ability to collapse a multiple domain design into a single domain design that takes advantage of organizational units (OUs) to delegate administrative responsibilities. The administrators responsible for domains under the original domain structure can still have administrative control over the same resources as they did in the past; however, the entire structure is organized for more efficient control of the entire set of resources.

Another advantage is that Group Policies can be put into place that will control a user s environment. Standard line-of-business applications , which are applications used to support the business s day-to-day operations, can be rolled out to the users who need them when Group Policies are used to automatically distribute software. When an upgrade or patch becomes available, it can be rolled out in an automated fashion using group policies instead of visiting the client workstation to perform a manual install.

When designing for total cost of ownership, you need to consider where the organization wishes to concentrate their TCO efforts. Some organizations simply want to design a more efficient administrative structure. Others want to optimize their application rollout and support. Still others want to take advantage of both options.

Note	Chapter 5, Designing An Organizational Unit Structure For Administrative Purposes, and Chapter 6, Designing a Group Policy Infrastructure, are dedicated to the advantages and disadvantages of designing OUs for administrative purposes and Group Policy efficiency.

You will need to consider trade-offs during the design process, because the optimum levels of administrative delegation and efficient Group Policy application do not usually work out to be the same design.

Special Requirements

Special cases need to be considered when you are documenting the current organizational requirements, especially when a domain restructuring is in the works. Some cases involve domains that cannot be collapsed. For instance, several corporations may start their existence providing one type of service, and later expand to provide other services as well. For example, many insurance companies have started banking divisions. Due to government regulations, the two divisions of the organization have to remain separate.

These special requirements will already have an impact on the current infrastructure and will continue to affect the future implementation. Administrative, political, and geographic restrictions, legal regulations, and plans for growth are the primary implications when determining the special requirements.

Restrictions and Regulations

You may encounter administrative restrictions as you investigate the requirements. Some of the resources located in domains may reside there because of administrative restrictions. The organization may have segregated these resources so that they can only be administered by certain members of the administrative staff. However, make sure that the reason for the separation of administrative control truly justifies the need for an additional domain. Make note of the reasons for the multiple domains in your documentation. You may also want to check the regulations to make sure they have not changed since the original model was put in place. From an administrative viewpoint, it is easier to build a single domain model and use OUs to delegate administrative control.

Design Scenario ”Analyzing Organizational Requirements

RoboSystems designs and builds robotic arms that are used in manufacturing plants throughout the world. Recognized as one of the leaders in robotics , they have continued to grow during the past 10 years. Management is contemplating the acquisition of another company that has been a competitor for several years. This acquisition will allow RoboSystems to add some new products to their line and diversify their offerings. Talks between the two companies are still in the discovery stages, but the company wants to make sure that the new directory service will allow for growth of the company if the acquisition does take place.

Four administrators report to the manager of information technology and are responsible for all of RoboSystems current system implementations . Three of the administrators are located at the company headquarters, and one is located at the manufacturing facility. The administrators at the headquarters are responsible for maintaining all of the systems within the organization, and the remote administrator at the manufacturing facility is responsible for maintaining the systems that are located at his facility.

During the interview process, you discovered the following information from key stakeholders:

CEO We are currently in a growth mode and I am concerned about our ability to grow technologically. If our plans to acquire another company come to fruition, I want to be assured that we can support all of the processes and systems that would be needed for both entities to compete in the marketplace .

I am also expecting our company to become more competitive and am looking to lower our operating expenses. With the additional systems that we will need to support after the acquisition, we will need to support more while maintaining the same level of staffing.

Manager of Information Technology Our current network infrastructure is built on a combination of Windows NT 4 and Novell NetWare 4.11. Although we are pleased with Novell s NDS, we are looking to take advantage of applications that are only supported on a Windows-based server. Exchange Server 2003 is one of those applications. Due to Exchange s server requirements, we are looking to move to Active Directory and use Windows Server 2003 as our primary network operating system. Doing so will simplify our account management as well as allow us to concentrate on one operating system. This should reduce our administrative overhead and allow us to work more efficiently.

Question: What reasons do RoboSystems have for designing a new Active Directory and network infrastructure? Answer: Reduce the Total Cost of Ownership (TCO) and application support.
Question: What is the primary reason for the new design? Answer: Looking at the interview information from the CEO and the manager of information technology, we can determine some of the reasons for the new design. The CEO mentioned that the new system s administrative requirements should be less than the existing environment. This bit of information alone should tell you that they are looking to reduce the TCO. Of course, what CEO doesn t want to reduce the TCO of the company? The manager of IT also hints at reducing the TCO but also mentions that they want to consolidate their current systems into one directory service. Keep this in mind when reviewing the information later on, because reducing the TCO appears to be the highest priority at this point.

You will also encounter barriers that control organizations, mainly political and geographic. The political reasons affect multinational organizations more than they do domestic organizations. Although the domestic laws place some restrictions on the current designs, when political boundaries are crossed, specific laws cannot be broken. One in particular is the United States cryptographic export laws . These laws dictate how strong the cryptographic keys can be when used outside of the United States. For the most part, these laws have been rescinded and most countries are allowed to have access to the strong keys. However, there are still some countries that are not allowed to have access to these strong cryptographic keys. Although these laws affect applications and system connectivity more than anything else, there could be legal reasons why the company has created a division between business units and created extra domains to enforce those restrictions.

Note	For more information about which countries are restricted due to cryptographic export laws, see the information at http://www.rsasecurity.com/rsalabs/faq/6-5-1.html .

Privacy laws are starting to become prevalent in our society as people become increasingly concerned about their privacy and identity safekeeping. Directory services, by their nature, hold information about the users in the organization. This information can be accessed by administrators and, depending on the permissions that have been assigned, users. There may be reasons to completely separate the administrative control for privacy reasons. Whereas the United States is just now starting to identify privacy concerns, other nations have already adopted privacy rules. Most European countries have specific rules pertaining to the information that can be exported. You will find that the rules that govern the data that can be sent to Europe from the United States are much more lax than the rules for exporting data from Europe to the United States.

Plans for Growth

The goal for most organizations is to make a profit and grow. Most companies do not put reduction of size in their mission statement. Their projections usually state that they are trying to obtain a certain amount of growth; a 10-percent increase in revenue over the same quarter from last year, a 15-percent increase in profits though the end of the year, and so on. Most corporate entities measure their viability in how much the company has grown financially . The stockholders for the company require that the company is viable and growing.

Some of the more aggressive companies attempt to acquire other businesses or merge with other entities. If plans are in the works for an acquisition or merger, the design will need to take this expansion into consideration. All of the entities concerned need to be investigated so that you will know how the units will tie together and so you can plan for the combined infrastructure.

Administrative Control

One of the most important considerations when identifying the requirements of any organization is the administrative responsibilities. More than anything else, you need to know who is responsible for the resources within the organization. Without this information, you will not know why the current domain structure is built, nor will you have a basis for restructuring the resources into an efficient directory service infrastructure.

Resources will include users, computers, shared folders, printers, domain controllers, sites, OUs, and any other physical or logical object that resides within Active Directory. You need to document what objects exist and who is responsible for each of them. In Chapter 5, we will present effective designs for administrative control. The more thorough you are at discovering and documenting information at this level, the more effective your final design will be.

One tool many administrators use when mapping the resource/administrative control is a table that outlines the resources, who is responsible for those resources, and the level of control they have over the resources. As seen in Table 2.1, when the table is created, you can easily view who is responsible for each resource. This table, usually created with a spreadsheet, will also come in handy later as you start the design of the new directory service. The information you gathered will become your documentation for designing domains and OUs.

Table 2.1: A Sample Administrative Control Table
Server	Service/Application	Administrator (DetroitAdmins have control over all servers)
LANBDC	Backup Domain Controller	No Local Administration
NetServices	DHCP/DNS/WINS	No Local Administration
LANFNP	File and Print Server	LansingAdmins
LANINTRAWEB	Intranet Web Server	LansingAdmins

In Chapter 1, Analyzing The Administrative Structure, we discussed the different types of administrative control: centralized, decentralized, and hybrid. Depending on the resources the administrative staff is responsible for and the level of control they have over those resources, you can decide what type of control the company uses. If administrators need complete autonomy over their own resources, chances are the organization employs a decentralized approach. If the administration is shared over all of the resources, a centralized model is probably being employed. However, if the company does have a hierarchy of administrative responsibilities where more than one group of administrators manage the resources, each with their own level of control, the company probably uses a hybrid approach. If you review the administrative requirements carefully , you should fully understand which model is being used.

Geographic Design

If an organization only has one location, the design should be simple, with no wide area network (WAN) links or a need for multiple sites or site links. More often than not, the company will have multiple locations with WAN links connecting them. You may even run into large multinational corporations that not only have multiple locations and several different types of communication links connecting them, but will also have time zone differences and geo-political boundaries.

Creating a map of the corporate anatomy will assist you when you are trying to visualize how the locations communicate. Make sure you include all of the different types of communication equipment as well as the speed of the links, their reliability, and the amount of traffic currently saturating the link. Using a program such as Visio, you can create network diagrams to include within your documentation. With these documents, you will then have information that details the current network topology. Figure 2.1 is an example of a Visio diagram that shows the connections among three offices.

Figure 2.1: A sample network diagram using Visio

Design Scenario ”Determining Administrative Needs

Looking at the administrative makeup of RoboSystems that was described in the Analyzing Organizational Requirements sidebar earlier in this chapter, we find that there are four administrators, one of whom is located at the manufacturing facility to support the remote systems. The other three administrators have control over the remote resources also. All three of the corporate administrators are members of a group named CorpAdmins, and the administrator from the manufacturing facility is a member of the group ManAdmins. After inventorying the systems in use, the following systems were identified:

Corporate Office resources:
- ACCTFP = File/Print Server
- CorpDNS = DNS Server
- CorpWINS = WINS Server
- CorpEX = Exchange 5.5
- CorpDC = NT 4 PDC
- CorpDC2 = NT 4 BDC
- CorpSQL = SQL 7 Server
Manufacturing Plant resources:
- ManDC = NT 4 BDC
- ManNRS = DNS/WINS Server
- ManEX = Exchange 5.5
- ManFP = File/Print Server

Question: From the information gathered about the administrative structure, determine what type of administrative model is in place. Answer: From what you have already read about the administrative models, you can determine that the current administrative model is a hybrid model.

Question: Build an administrative control table based on the information that was gathered. Answer: After reviewing the systems in place within RoboSystems, you have determined the following:

Server	Service/Application	Administrator
ACCTFP	File/Print Server	CorpAdmins
CorpDNS	DNS Server	CorpAdmins
CorpWINS	WINS Server	CorpAdmins
CorpEX	Exchange 5.5	CorpAdmins
CorpDC	NT 4 PDC	CorpAdmins
CorpDC2	NT 4 BDC	CorpAdmins
CorpSQL	SQL 7 Server	CorpAdmins
ManDC	NT 4 BDC	CorpAdmins/ManAdmins
ManNRS	DNS/WINS Server	CorpAdmins/ManAdmins
ManEX	Exchange 5.5	CorpAdmins/ManAdmins
ManFP	File/Print Server	CorpAdmins/ManAdmins

Later in this chapter, we discuss the network requirements and connection types that are used. Based on the geographic design of the network, you may end up having to use connection types that are less than optimal, but that is a trade-off that may be necessary to allow the administrative control of the resources within your organization.

Identifying the Current Software Requirements

By taking an inventory of the current software the company uses you will be able to determine what types of hardware, network, and name-resolution requirements the organization needs. You can use several methods to obtain this information, some of which are easier than others. Microsoft and other third-party companies have tools that allow you to determine what software is installed on computers within the organization. Microsoft s System s Management Server (SMS) has the ability to inventory the software installed on a client s workstation as well as the applications running on servers. Once the software is inventoried, reports can be prepared to detail the software in use. Novell has a product called ZENworks that can provide this same functionality. Other third-party companies ”such as Tivoli ”can also provide this for you.

One drawback of these products is that they must already exist on the network. Since many companies have not implemented one of these technologies, you will have to add it. It is rare that you will find a company that will allow you to introduce one of these products into their production environment. It is even rarer that you will be granted the budget to implement a technology that might not be used in the final rollout of the design.

Something that we will come back to time and again when we are explaining how to identify requirements is the interview process. Although prone to errors, mainly of omission, the interview process is your best tool to use when you are trying to determine what software is in place within the organization. If you are a member of the organization, you may be aware of the line of business applications that make up the business processes. However, if you are someone who is called in to assess the organization, you may not have this luxury. Sitting down with the stakeholders allows you to determine what software is in use. Even if you do have a list of the line of business applications, you should still perform interviews. You never know when you will come across a division that has implemented an application to assist them with a function, even though it was not implemented through the proper channels.

Software requirements will be based on the software issues that have dictated how the company has implemented the current design. Some software comes prepackaged, whereas other software is written in-house. You may also encounter protocol issues that may need to be addressed.

Software Issues

Software comes in two flavors: packaged and home-grown applications. Most companies will have a little of both. If a company is lucky, packaged applications that they purchase from a retail outlet will fulfill their requirements and they will not have to develop applications that are specific to their environment. Application suites, such as Microsoft Office, will play a prominent part in many organizations due to the fact that the service they provide is required by most organizations. They contain so many features that the company usually does not need any additional functionality. Other client applications used to access the server applications may only have a single function. Still other applications, such as Internet Explorer, may have a specific function they provide, such as gaining access to web pages, but they may also be used to access server-based applications that can generate and manipulate data on those servers.

Although most companies will be able to use packaged applications to some extent, some organizations will have specific requirements that packaged applications do not cover. These specialized applications are either written by in-house development staff, or contracted out for another company to develop. These applications will range from data analysis add-in macros for a spreadsheet to customer relations software. Each of the applications will have requirements for them to run.

These requirements will need to be documented along with the applications being used. These requirements will aid you when you are determining the hardware, network, and name resolution requirements. Certain applications will not need any special requirements for the network, whereas others will have specific needs. Some applications will require that a NetBIOS name resolution method be available, where others will rely on hostname resolution. Keep track of the application requirements because you will use them later when you are determining the services required and the hardware placement to make these applications work efficiently.

Protocol Requirements

If there are any software protocol requirements, make sure to note them. Most applications that have been developed for a Microsoft environment recently will take advantage of TCP/IP. Because TCP/IP has become the de-facto standard within most infrastructures , you should be familiar with the network services that need to be in place to support TCP/IP name resolution: Domain Name Service (DNS) and Windows Internet Name Service (WINS).

NWLink, Microsoft s implementation of Novell s IPX/SPX protocol, may be in place where a legacy Novell network is used. Some applications were written to take advantage of NWLink instead of TCP/IP. You may also run into applications that were written to run exclusively on a NetWare server. If this is the case, you will need to document your findings because this will pose an interesting problem for those companies that want to move to a single operating system on their network. Although Windows Server 2003 will support NWLink, you will need to determine if the application will run on a Microsoft operating system such as Windows Server 2003. You may also want to investigate the possibility of the vendor supporting a version of the application that will run on Windows Server 2003. Of course, if this is the case, the application may be very different from the NetWare version, and may require additional training, and thus more cost. If the application is not supported on a Windows Server 2003 system, you may be forced to maintain the other operating system within your design.

Note

Although Microsoft does not support NetBEUI on Windows Server 2003, you are able to add the NetBEUI protocol. Using a Windows XP installation, you can install NetBEUI from the Valueadd\MSFT\NET\NETBEUI folder. This solution is not supported by Microsoft, and the exam assumes that the NetBEUI protocol is not available for Windows Server 2003 systems.

Another protocol that may be in use on a legacy network is NetBEUI. This protocol is no longer supported by Windows Server 2003. Applications that require this protocol, of which there are very few, should be rewritten, or you should check for a newer version of the application that no longer uses NetBEUI. Again, if the application cannot be rewritten, a newer version cannot be found, and the business requires it, you will have to support another operating system within your design.

Do note that supporting multiple protocols can place additional overhead on your network. Although many companies have been maintaining multiple protocols for many years, it is more efficient to use a single protocol. And of course, the more efficient your network is, the more throughput you will be able to achieve.

Identifying the Current Hardware Requirements

Now that the logical requirements for the current network have been documented, you need to document the hardware requirements for the existing network. This will not simply be a document that details the hardware that is in place on the network and its capabilities; instead it will be an examination of the requirements that are necessary based on the software and the network requirements. Then, after you have documented the current hardware requirements, you will have a good idea of how much of an additional load the current infrastructure can take on. This will also be a vital resource to have when you are trying to convince the powers-that-be that you need additional resources to support the upcoming design.

When identifying the current hardware requirements, you will need to inventory the current hardware. This will include the server systems that are in place to support the organization as well as the network devices that are used to support the network infrastructure.

Identifying Hardware

Starting off, you will need to identify what hardware is in place and the capabilities of the hardware. Server, workstations, routers, switches, hubs, network throughput capabilities, WAN connectivity devices, and WAN throughput capabilities all need to be identified and documented. Again, you can use Visio to diagram what is being used within the organization.

After the hardware has been documented, you need to start testing the current load on the hardware. You can use several tools to see how many resources are being consumed on each of the devices. Within a Microsoft-based network, you can take advantage of several built-in tools to monitor your servers, workstations, and network capacity. You can use Performance Monitor in Windows NT, or Performance Logs and Alerts for Window 2000 and Windows Server 2003 to create log files that contain data about the current usage levels on your Windows-based systems. Other operating systems have utilities that you can use when you are trying to determine current usage levels. Novell NetWare has Monitor and some web-based monitoring tools that will help you document. Third-party companies also provide monitoring software that you can purchase and use to baseline the entire network. A baseline is the criteria for which future performance and troubleshooting is compared against. When the system is running optimally, use one of the monitoring tools to gather the current resource usage levels. These levels are then compared to performance levels when problems occur so that you can determine which of the resources may be causing the problem.

If the network is heterogeneous, you may want to purchase a third-party solution that can gather the data and store it in one central database. However, these programs are expensive. Your current budget may not have money allocated for this type of purchase. If you are lucky, however, using one of these tools will save time when you are trying to collect data from several different sources. If the current infrastructure is based on one operating system, take advantage of the built-in tools because you won t have to take a hit on your budget.

No matter what tool you decide to use, make sure the data collection is valid. Running the monitoring tool on the same system that you are monitoring skews the results because the monitoring software consumes resources. The rule of thumb is to run the monitoring software on a monitoring system. This could be a workstation that creates the logs or sends the collected data to a database. This method allows the monitored system to still function close to normal, and the monitoring system can be dedicated to collecting data. Only the network counters would be adversely affected by the additional traffic flow of data collection.

Once you have collected it, you can review the performance data from these servers and create graphs. What you are looking for are the peak usage times. This indicates how much the server is being used and how much capacity remains. Later this information will come in handy when you are deciding which servers can handle service consolidation and which may need to be replaced because they are reaching capacity for the service they provide.

As with other sections in this chapter, we are going to recommend that the information you collect here be presented in a simple format. The servers that you baseline can be entered into a table that shows the maximum resource load that occurs. You can include the graphs that you generated from the performance baseline with this documentation to substantiate the data in the table.

At this point, you should also determine the capabilities of the hardware devices that make up the network infrastructure. Router, firewall, hub, switch, and any other network device capacities need to be determined. By reviewing the manufacturer s documentation you can determine what each device is capable of. You should also run tests against these devices if you have equipment that allows you to monitor their performance. Include your findings within the documentation.

Network Requirements

Just as with the hardware requirements for the existing system, you need to collect data about the existing network infrastructure. This information allows you to detect what is currently in use on the network and have a basis to judge whether or not future growth will be allowed without compromising the efficiency of the network.

The process of collecting the network requirements will require that you monitor what traffic is currently traversing the network. Understanding the current addressing requirements so that you understand how the systems are configured and which connection types are in use will aid in the future design and plan.

Network Monitoring

Tools available from several companies will allow you to capture data as it traverses the network. These tools allow you to see what type of data is being sent on the network and how much of the total capacity of the network the data is consuming. Microsoft bundles a version of their network monitoring tool, Network Monitor, with Windows Server 2003, but it does not capture all of the packets on the network. It is limited to only capturing packets that originate from or are received by the system that is running Network Monitor. The fully functioning version ships with Microsoft SMS. Using this tool, packets that are traversing the network can be captured for analysis.

When capturing packets, make sure you get a good representation of the work that is being performed. Collecting a sample of network traffic between the hours of 10 A.M. and 11 A.M. and expecting that to be completely representative of the workload for the entire organization is not a valid test. For several days, sample data at different times of the day. If there are multiple locations within the organization, sample data from all of the locations, on all of their network segments to get a true reading as to how the network is being used.

When you are collecting network data be sure to collect enough data to make an informed decision during the design process, but do not collect so much that you have too much data to parse through. While collecting everything that passes on the network might seem like the ideal, you could find yourself drowning in information. Determine what traffic you want to collect, identify the systems you want to monitor, and then capture the packets.

System Addressing

Each device on the network will need a unique network address. The assignment of these addresses can either be performed manually or via Dynamic Host Configuration Protocol (DHCP). If manual addressing is employed so that the systems have static addresses, make sure to note the address ranges used within each of the network segments. You will use this information later when you are optimizing the address assignment for the new design.

Most companies take advantage of the automatic assignment nature of DHCP. Like the UNIX bootstrap protocol (BOOTP), DHCP assigns addresses to the client systems, along with any configuration options. Using DHCP dramatically eases the administrative overhead involved with configuring the addressing for a computer system. DHCP client systems send a request for address assignment across the network and the DHCP server responds with configuration information. Once the DHCP client is configured, the DHCP server keeps track of the address assignment and makes sure that no other system receives an address from its database that is already leased to another system.

You need to document where the DHCP client systems are obtaining their IP addressing configuration from. Doing so allows you to determine how DHCP is administered and controlled. It also allows you to verify the amount of data that is being transmitted across the network on behalf of DHCP. Most companies have a decentralized DHCP environment. This method allows the DHCP servers to reside close to the clients that need the address assignment. Backup DHCP servers can reside across the WAN links in case of a failure of the local DHCP server. Document the location of each of the DHCP servers and the network segments for which they are responsible, along with the current address ranges within the scope and the configuration options that are handed out with the client lease.

NetWare may introduce additional addressing concerns if the IPX/SPX protocol is used instead of TCP/IP. Until NetWare 5 was introduced, IPX/SPX was the default protocol within a NetWare environment. Many network administrators kept this protocol in place due to its installation and the efficient manner in which it ran. Some administrators would use IPX/SPX on their internal network as a security barrier . By having the internal network run a protocol different than TCP/IP, which was used within the perimeter network, they gained another layer of security. Moving these servers to a TCP/IP environment may take additional planning and time.

Connection Types

Several different options are available that allow companies to connect their offices together. Depending on how much a company is willing to pay, they can use high-speed connections between the sites. Table 2.2 lists some of the popular connection types .

Table 2.2: Connection Type Table
Connection Type	Speed of Link
Modem	Up to 56Kbps
Integrated Services Digital Network (ISDN)	64Kbps “2048Mbps
Digital Subscriber Line (DSL) ”ISDN-based Digital Subscriber Line (IDSL), Asymmetric Digital Subscriber Line (ADSL), Symmetric Digital Subscriber Line(SDSL)	144Kbps “1.544Mbps
T-Carrier ”Fractional	Available in 64Kbps increments
T-Carrier ”T1	1.544Mbps
T-Carrier ”T2	6.312Mbps
T-Carrier ”T3	44.736Mbps
T-Carrier ”T4	274.176Mbps
E-Carrier ”E1	2.048Mbps
E-Carrier ”E2	8.448Mbps
E-Carrier ”E3	34.368Mbps
E-Carrier ”E4	139.264Mbps
X.25	9600bps “2Mbps
Frame Relay	56Kbps “1.544Mbps
Asynchronous Transfer Mode (ATM)	25Mbps “622Mbps

You will notice that some nondomestic connection types are listed in the table. Whenever you are working on an international level, you will have to make decisions about what type of connections you will use. Although there are high-speed connections throughout the world, many locations do not support them. Thus, you may be restricted to using a modem to connect systems.

Note	Within Chapter 9 Designing the Network Infrastructure, we look at the types of links that we can use for primary and backup connections when the connections are not reliable.

Virtual Private Network

One of the more popular methods of connecting clients to the internal network or connecting sites is to use a Virtual Private Network (VPN). A VPN is a method of encrypting the packets sent across a nonsecure network so that the two systems can have a secure method of communication. Because it is so easy to gain access to the Internet, the Internet is being used as an extension of an organization s network. The problem with using the Internet in this manner is its inherent lack of security. VPNs are used to authenticate and encrypt the traffic between the two sites. Two main VPN types are available within Microsoft networks: Point-To-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol (L2TP). PPTP can be used with nearly all Microsoft operating systems, whereas L2TP is available for Windows 2000 and later operating systems. Windows NT 4 supports L2TP with the addition of the Windows NT L2TP/IPec software available for download from Microsoft's website.

Documenting Your Findings

The data that you gather needs to be documented so that you can read through it and disseminate the valid information. These documents can take on many styles depending on the company that is performing the initial investigation of the network. Some companies simply jot the information that they find onto a piece of paper and then review the notes later when they are compiling the data. Other companies take a methodical approach and have forms for every part of the investigative process. One such form is the Connection Type form. Figure 2.2 shows an example of what this form may look like.

Figure 2.2: A sample Connection Type form

Another form that can be used is the Subnet Allocation form. This form allows you to detail the addressing requirements for the subnets and specify how the addressing is applied ”manually or through DHCP. Look at Figure 2.3 to see the data that is collected on this form.

Figure 2.3: A sample Subnet Allocation form

As mentioned earlier, a map of the network layout is imperative. This map should include all of the sites within the organization, the subnets within those sites, the network devices, and enough information about the subnet so that you can cross-reference the addressing to the Subnet Allocation form. Using Visio, you can effortlessly create a network map. Look back at Figure 2.1 to review what this document may look like.