Home > Articles > Certification > Microsoft Certification

This chapter is from the book

Designing the Network Services Infrastructure to Meet Business and Technical Requirements

When all the required information has been gathered, you're ready to begin designing the network infrastructure. This includes designing how the various network services, such as WINS, DHCP, and DNS, will be used in the new infrastructure.

Creating the Conceptual Design of the DNS Infrastructure

When creating the conceptual design, consider things such as the DNS namespace, DNS server placement, as well as any interoperability issues.

DNS Namespace

One of the most important points when designing a DNS infrastructure is the DNS namespace that will be used. This is essentially the foundation of the Active Directory hierarchy. When the DNS name has been chosen, it should be registered on the Internet, regardless of whether the company has an Internet presence. That way, if the company decides to implement an Internet presence in the future, you won't have to reorganize the current Active Directory hierarchy.


The internal and external namespaces are frequently different, so you would not have to change the internal namespace when implementing an Internet presence or presences.

Server Placement

When you design a DNS infrastructure, you need to consider where on the network your DNS servers should be located. The main goal is to provide clients with optimal response time when resolving hostnames (of course, you also want to consider network traffic as well).

In a network that's routed, you have two options. Ideally, you want to be able to place a DNS server on each subnet. Or, if the subnets are connected via high-speed links, you can place all the DNS servers in a central location (which might be more ideal for administrators). However, in choosing the second option, the loss of a connection could mean that clients are temporarily without name resolution services.

If zones aren't integrated within Active Directory, secondary servers should be used for fault tolerance and increased availability. The primary DNS servers should ideally be located near those who are responsible for administering them. Consider placing the secondary servers on subnets that contain the most hosts or on those that generate the most name resolution traffic. For those subnets that generate a large amount of traffic, you might want to place both a primary and secondary server for load balancing purposes.

You also need to consider whether any remote sites are connected to the main sites via slow WAN connections. In these situations, caching-only servers are ideal. When the cache is built up, there will not be as much need to resolve queries over the WAN connection. The WAN link will also not be used for zone transfers (which can generate a large amount of network traffic) because the server does not store any zone information. On the other hand, if the remote location has enough clients, it would be prudent to have a domain controller placed locally, therefore using a full DNS implementation.

Interoperability Issues

When planning a DNS infrastructure, one of the important things to consider is that the version of DNS included with Windows Server 2003 will integrate with other DNS servers. In some cases, a network will already have a DNS implementation and you might be required to add a Windows Server 2003 DNS server to the infrastructure. Before you do, it's critical that you know how DNS will integrate with these existing versions. For example, if you were installing a Windows Server 2003 domain, how would an existing BIND DNS server function within the domain? Identifying any interoperability issues during the design phase can help ensure that any interoperability issues are corrected before the plan is rolled out.

You also need to consider the existing name service used for resolution. Many networks today still implement WINS servers to support legacy clients such as Windows NT 4.0 or clients that still use NetBIOS names. Because Active Directory requires the use of DNS, you must be aware how Windows Server 2003 DNS can integrate with WINS servers.

Many networks already have a DNS infrastructure in place. As the old saying goes, "If it ain't broke, don't fix it." So, many administrators may be reluctant to switch over to another DNS server when the infrastructure currently in place is fine. In such cases, you should be aware of how Windows Server 2003 DNS will interoperate with other versions of DNS.

Creating the Conceptual Design of the WINS Infrastructure

In a network environment that supports only Windows 2000, Windows XP, and Windows Server 2003 clients, WINS is not required because the primary namespace used is DNS. When NetBIOS over TCP/IP is enabled, traditional name resolution techniques are still used depending on the manner is which a request is made.

Pre–Windows 2000 clients require NetBIOS for such things as locating domain controllers. If any legacy clients such as Windows NT 4.0, Windows 95, and Windows 98 are on the network, WINS might be required for NetBIOS name resolution services. Otherwise, if all workstations can support DNS, WINS does not have to be implemented.

You also need to look at the physical network. If there is a single subnet with a small number of clients, WINS might not be necessary and you can rely on LMHOSTS files or broadcasts for name resolution. However, if there are a large number of hosts on the subnet or if there are multiple subnets, WINS should be implemented. In terms of the number of clients, the performance of a physical network can suffer if broadcasts are relied on for name resolution. Implementing WINS can reduce the number of broadcasts on a subnet. Also, because routers do not forward broadcasts between subnets, WINS should be used to facilitate network access between different subnets. WINS servers on different subnets can be configured for replication so that clients on one subnet can resolve the names of clients on other subnets.

A single WINS server is capable of handling a large number of requests. The number of WINS servers you implement on a network is dependent on several things, such as the hardware installed on the WINS server, whether or not the network is routed, as well as the number of clients on each subnet. When determining the number of WINS servers required, keep the following points in mind:

  • The number of NetBIOS names typically registered by a WINS client

  • The frequency of name registrations and releases due to workstations being rebooted

  • The speed and availability of the physical links connecting the various networks

A single WINS server is capable of handling approximately 10,000 clients; of course, this is dependent on the amount of NetBIOS traffic that is generated. It is always recommended that two WINS servers be configured for fault tolerance. So, when you're planning the number of WINS servers, a good guideline is to install two WINS servers for every 10,000 WINS clients. You can then configure the two WINS servers as replication partners.

When implementing multiple WINS servers, you also need to decide where they should be located. The speed and available bandwidth of the existing network connections have a major effect on where WINS servers are placed.

Creating the Conceptual Design of the DHCP Infrastructure

Certain factors will affect your DHCP implementation. When designing a DHCP infrastructure, you need to consider the following points:

  • The number of DHCP servers

  • The placement of DHCP servers

  • DHCP in a routed network

Number of DHCP Servers

There really is no limit to the number of clients that a single DHCP server can service. Therefore, the main factors that will influence the number of servers you implement will be the existing network infrastructure and the server hardware. If your network consists of a single subnet, a single DHCP server is sufficient, although you might choose to implement more than one for a high level of availability. Implementing a single DHCP server creates a single point of failure, although clients can use APIPA in the event that the DHCP server is unavailable. You can also use the Alternate Configuration option, and manually specify the IP address parameters that a client should use if a DHCP server is not available.

In terms of the network infrastructure, if the network consists of multiple subnets, routers can be configured to forward DHCP broadcasts between subnets. Or you might choose to place DHCP servers on each of the subnets. Another option is to configure a DHCP relay agent on those subnets that do not host DHCP servers (see Figure 3.4). The DHCP relay agent can forward IP address requests to DHCP servers on other subnets on behalf of clients.

Figure 3.4Figure 3.4 Enabling the DHCP relay agent.

In any case, before you implement any DHCP servers on the network, consider the following points:

  • DHCP servers should be configured with fast disk subsystems and as much RAM as possible. If your DHCP server lacks the hardware (and depending on the number of clients), you might need to implement more than one DHCP server to improve response time for clients.

  • Implementing a single DHCP server creates a single point of failure.

  • If there are multiple subnets, you can extend the functionality of a DHCP server across subnets using the DHCP relay agent. Other solutions include placing a DHCP server on each subnet or enabling forwarding of DHCP requests via the routers.

Consider the speed of the links connecting various networks and segments. If a DHCP server is on the far side of a slow WAN link or a dial-up connection, you might choose to place DHCP servers on either side for increased performance. Because DHCP servers do not share any information, there would be no increase in network traffic. Network traffic on the slow link would actually be reduced because clients can obtain leases locally as opposed to using a remote DHCP server.

Placement of DHCP Servers

When it comes time to determine where on the network DHCP servers should be placed, keep in mind that your overall goals are to provide high levels of client performance and server availability. Placement of the DHCP servers depends on the routing configuration, how the network is configured, and the hardware installed on the DHCP servers.

If you're implementing a single DHCP server, it should be placed on the subnet that contains the highest number of clients. All other subnets will have a DHCP relay agent installed or the routers will be configured to forward DHCP broadcasts. Also keep in mind that with a single-server implementation, the network connections should be high speed and the server should be configured with the appropriate hardware.

There are a number of reasons why you might choose to use multiple DHCP servers. Some obvious reasons are high availability and redundancy. When you're determining where to place the DHCP servers, remember that they should be located on the subnets that contain the most clients. Also assess the connections between networks: If certain subnets or segments are connected with slow WAN links, such as a dial-up connection, a DHCP server should be placed at these locations so that clients do not have to use the slow connection when attempting to lease or renew an IP address. Having clients obtain IP addresses across slow unreliable links creates another point of failure if the link becomes unavailable.

Routed Networks

Networks can be subdivided into smaller networks known as subnets. Those subnets are connected using routers. To reduce network traffic, most routers do not forward broadcasts from one subnet to another. This poses a problem with DHCP because clients initially send out a broadcast when leasing an IP address—the client does not yet have an IP address. One solution to this problem is to use DHCP relay agents.

A relay agent is responsible for relaying DHCP messages between DHCP clients and DHCP servers that are located on different subnets. If routers are RFC 1542–compliant, they can forward the DHCP-related messages between subnets. If not, a computer running Windows Server 2003 (Windows NT 4.0 and Windows 2000 as well) can be configured as a relay agent by installing the DHCP relay agent component. Configuring a DHCP relay agent is done through the Routing and Remote Access console.

Centralized Versus Decentralized

Another aspect you need to consider when planning for DHCP is whether you will implement a centralized or a decentralized model in a subnetted environment. For example, you could choose to have all the DHCP servers in a single location servicing requests from clients on different subnets. Or you might choose to place the DHCP servers on each of the different subnets instead. Before you make your decision, you should be aware of the advantages and disadvantages associated with each option.

A decentralized approach would result in DHCP servers being placed in each of the different subnets. Doing so offers the following advantages and disadvantages:

  • Local administrators can administer their own DHCP servers and configure them in a way that meets their own needs.

  • Clients do not have to rely on WAN links to obtain an IP address.

  • Placing a DHCP server at each location will obviously result in an increase in cost due to the fact that multiple servers are required.

A centralized approach would result in all DHCP servers being located in a specific location. This approach offers the following advantages and disadvantages:

  • Administration of DHCP might be simpler because there will be fewer servers and having them in a single location where technical support is on-hand makes problems easier to troubleshoot.

  • If fewer DHCP servers are required, the cost associated with implementing DHCP will obviously be reduced.

  • Clients in remote sites might have to rely on WAN links to obtain an IP address. That means if the WAN link is down, clients will not be able to contact a DHCP server. This creates a single point of failure.

  • Administration could be more difficult because it is hard for an administrator to know the configuration requirements of a remote site.

Creating the Conceptual Design of the Remote Access Infrastructure

When creating the conceptual design for remote access, you need to determine the remote access method. Windows Server 2003 supports two different remote access methods, dial-up and VPN. You need to evaluate the advantages and disadvantages of each remote access method to determine which one best suits your needs.

With a dial-up solution, remote access clients connect to a remote access server using a telephone line. The remote access server requires at least one modem or multi-port adapter as well as a telephone line or another form of connectivity. If the remote access clients require access to resources on the private network, the remote access server must also be configured with a LAN connection. The remote access client simply requires a modem and telephone connection.

The second option for remote access connectivity is to implement a VPN remote access solution. To provide users with remote access via the Internet, the remote access VPN server is normally configured with a permanent Internet connection. Again, if users require access to the private network, the server must also have a LAN connection. The VPN client must have a modem or network adapter as well as Internet connectivity using the phone line or another WAN connectivity method. A VPN solution also requires the use of a tunneling protocol. The remote access client and the remote access server must be configured to use PPTP or L2TP (keeping in mind that the client and the server must be configured to use the same tunneling protocol).

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020