Introduction

Published: March 31, 2005

This blueprint discusses in detail the design considerations for basic network services in an enterprise environment, specifically:

Domain Name System (DNS)

Dynamic Host Configuration Protocol (DHCP)

Windows Internet Name Service (WINS)

In an information technology (IT) environment, users need to make use of resources such as file and print services, authentication services, e-mail and messaging services, and access to enterprise applications. In addition, for the resources of one computer or device to access another, they need to be able to identify and reference each other. The network services defined and discussed in this blueprint are considered essential because they provide the mechanisms that such resources rely on for their functionality.

Windows Server System Reference Architecture (WSSRA) is an integrated set of service solutions providing architectural guidance for different enterprise scenarios. As the design process is explained in this blueprint, a number of design options will be discussed and their advantages and disadvantages laid out. At the end of each section, wherever applicable, a “Recommendation for Best Practice” section has been added to provide the best starting point for your design. This section is designed to help you choose the best option for each of the design choices if there were no limitations. However, it is possible that, due to your specific project requirements, you will rule out this guidance.

Specific implementation details are provided in the Network Services Planning Guide and the Network Services Build Guide of this documentation.

On This Page
Who Should Read This BlueprintWho Should Read This Blueprint
Knowledge PrerequisitesKnowledge Prerequisites
Business NeedBusiness Need
ReferencesReferences

Who Should Read This Blueprint

This blueprint is intended for IT professionals with responsibilities for design and deployment of network services in enterprise environments. The reader of this blueprint should have an understanding of the technical details provided in this service-level guidance. However, it is not necessary for a service-level expert to understand the enterprise-level discussions and decisions presented in this blueprint.

Knowledge Prerequisites

The reader of this blueprint should have a basic understanding of the following technologies:

TCP/IP

DHCP

DNS

WINS

Microsoft Active Directory directory service

In addition, the reader of this blueprint should have read the “Deploying Network Services” book, which is part of the Windows Server 2003 Deployment Kit available at:

go.microsoft.com/fwlink/?LinkId=15305

Business Need

IT networks in today's organizations have multitudes of computing devices, from high-end servers to personal computers, that need to communicate with each other over the local area network (LAN). To do so, each device needs to have an identity in the form of either a logical device name (chosen by the organization) or an address that uniquely identifies the device and its location on the network.

For smaller networks (those with up to 500 devices) it is possible to maintain and distribute names and addresses manually, but as networks grow in size and complexity the maintenance of an effective name resolution service becomes more and more time consuming and resource-intensive. Larger networks require some form of automation and centralized management for the allocation and reclamation of addresses. In addition, each device on the network needs to resolve the mapping between names and addresses, which has become especially true since the global adoption of the TCP/IP protocol as the default standard for networking in enterprise environments. All hosts and devices using TCP/IP as their networking protocol require unique IP addresses in order to function properly. These addresses must be unique for each device on the network, and must be grouped together to form addressable networks and sub-networks. To maximize the benefits of TCP/IP while limiting the impact of its weaknesses, a management mechanism is required to enable the appropriate allocation of IP addresses to devices. To maximize usage of the limited number of IP addresses available, the reclamation of unused IP addresses and overall management of the available IP address space is also required.

With the widespread adoption of directory services that provide simplified access to enterprise resources, name resolution has now become a key network service. Directory services need a reliable and efficient name resolution system so that users, client operating systems, and servers can locate resources using names rather than addresses. These functions need to be performed without compromising the security of the network or the services the network provides.

As enterprises move to the deployment of IP version 6 (IPv6) name resolution, where the number of digits in the address may be as many as 48, effective name resolution becomes more important because even technical support staff will face difficulties remembering such IP addresses. Thus, it is essential to automate the process of configuring and maintaining the name resolution system as much as possible. In enterprise networks, any failures in the name resolution system will have an immediate and potentially devastating effect on the operation of the network and therefore the services provided to customers, costs, and profitability of the organization.

The required mechanisms may be grouped into three categories:

Name resolution services, such as DNS, to manage the mappings between host names and IP addresses.

Address allocation services, such as DHCP, to overcome limitations on the number of addresses that can be managed.

Name resolution mechanisms, such as WINS, to handle integration with NetBIOS environments.

This blueprint introduces these mechanisms and describes how they can be used in a number of logical and physical configurations. While DNS and DHCP are likely required in enterprise organizations, alternatives do exist. Therefore, this blueprint explains the decision steps for arriving at a suitable logical and physical design and discusses alternatives to DNS and DHCP, where applicable. Decision steps for the integration of NetBIOS network elements into an IP network are also provided, including alternatives such as network migration.

References

For in-depth information on DNS, DHCP, and WINS, refer to the Microsoft Windows Server 2003 Resource Kit at the following URL:

http://www.microsoft.com/windowsserver2003/techinfo/reskit/resourcekit.mspx 

For updated technical information on DNS, DHCP, and WINS, refer to technical articles available from "Support Center Windows Server 2003" at the following URL:

support.microsoft.com/default.aspx?scid=fh;EN-US;winsvr2003

For additional information, refer to the following resources:

Microsoft Windows Server 2003 Resource Kit. Redmond, Washington: Microsoft Corporation.

Microsoft Windows Server 2003 Deployment Kit. Redmond, Washington: Microsoft Corporation.

Microsoft Windows 2000 Server Resource Kit. Redmond, Washington: Microsoft Corporation.

Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference. Lee, T., Davies, J. 2000. Redmond, Washington: Microsoft Press.

DNS on Windows 2000. Larson, M. and C. Liu. 2001. Sebastopol, California: O'Reilly and Associates, Inc.

Windows 2000 DNS Server. Wong, W. 2000. Berkeley, California: Osborne/McGraw-Hill.

DNS and BIND, Fourth Edition. Albitz, P., Loukides, M. and C. Liu. 1998. Sebastopol, California: O'Reilly and Associates, Inc.

Internetworking with TCP/IP, Vol. 1, Third Edition. Comer, D. 1995. Englewood Cliffs, New Jersey: Prentice Hall.


**
**