- Designing the Active Directory Infrastructure to Meet Business and Technical Requirements
- Designing the Network Services Infrastructure to Meet Business and Technical Requirements
- Analyzing the Effect of the Infrastructure Design on the Existing Technical Environment
- Exam Prep Questions
- Need to Know More?
This chapter is from the book
This chapter is from the book
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.
NOTE
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.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).