Core Network Planning

Applies To: Windows Server 2008 R2

Before you deploy a core network, you must plan the following items.

  • Planning subnets

  • Planning basic configuration of all servers

  • Planning the deployment of AD-DNS-01

  • Planning domain access

  • Planning the deployment of WINS-01

  • Planning the deployment of DHCP-01

  • Planning the deployment of NPS-01

The following sections provide more detail on each of these items.

Planning subnets

In Transmission Control Protocol/Internet Protocol (TCP/IP) networking, routers are used to interconnect the hardware and software used on different physical network segments called subnets. Routers are also used to forward IP packets between each of the subnets. Determine the physical layout of your network, including the number of routers and subnets you need, before proceeding with the instructions in this guide.

In addition, to configure the servers on your network with static IP addresses, you must determine the IP address range that you want to use for the subnet where your core network servers are located. In this guide, the private IP address range 192.168.0.1 - 192.168.0.254 is used as an example, but you can use any private IP address range.

The following recognized private IP address ranges are specified by Internet Request for Comments (RFC) 1918:

  • 10.0.0.0 – 10.255.255.255

  • 172.16.0.0 – 172.31.255.255

  • 192.168.0.0 – 192.168.255.255

When you use the private IP address ranges as specified in RFC 1918, you cannot connect directly to the Internet using a private IP address because requests going to or from these addresses are automatically discarded by Internet service provider (ISP) routers. To add Internet connectivity to your core network later, you must contract with an ISP to obtain a public IP address.

Important

When using private IP addresses, you must use some type of proxy or network address translation (NAT) server to convert the private IP address ranges on your local network to a public IP address that can be routed.

For more information, see Planning the deployment of DHCP-01.

Planning basic configuration of all servers

For each server in the core network, you must change the password for the Administrator account on the local computer, rename the computer, and assign and configure a static IP address for the local computer.

Planning the Administrator account password

For security reasons, it is important to create a password for the Administrator account and to use a strong password. In addition, it is recommended that you use a different Administrator account password for each server on your network.

The following is an example of a strong password.

Configuration item: Example value:

Administrator password

Example: J*p2leO4$F

Note
Strong passwords contain a minimum of 7 characters that consist of each of the following: uppercase letters (A, B, C, lowercase letters (d, e, f), numerals (0, 1, 2, 3), and keyboard symbols (' ~ ! @ # $ % | /).

Planning naming conventions for computers and devices

For consistency across your network, it is generally a good idea to use consistent names for servers, printers, and other devices. Computer names can be used to help users and administrators easily identify the purpose and location of the server, printer, or other device. For example, if you have three DNS servers, one in San Francisco, one in Los Angeles, and one in Chicago, you might use the naming convention server function-location-number:

  • DNS-SF-01. This name represents the DNS server in San Francisco. If additional DNS servers are added in San Francisco, the numeric value in the name can be incremented, as in DNS-SF-02 and DNS-SF-03.

  • DNS-LA-01. This name represents the DNS server in Los Angeles.

  • DNS-CH-01. This name represents the DNS server in Chicago.

Choose a naming convention before you install your core network using this guide.

Planning static IP addresses

Before configuring each computer with a static IP address, you must plan your subnets and IP address ranges. In addition, you must determine the IP addresses of your DNS and WINS servers. If you plan to install a router that provides access to other networks, such as additional subnets or the Internet, you must know the IP address of the router, also called a default gateway, for static IP address configuration.

The following table provides example values for static IP address configuration.

Configuration items: Example values:

IP address

192.168.0.3

Subnet mask

255.255.255.0

Default gateway

192.168.0.10

Preferred DNS server

192.168.0.1

Alternate DNS server

192.168.0.7

Preferred WINS server

192.168.0.2

Alternate WINS server

192.168.0.8

For more information, see Planning the deployment of DHCP-01.

Planning the deployment of AD-DNS-01

Following are key planning steps before installing Active Directory Domain Services (AD DS) and DNS on AD-DNS-01.

Planning the name of the forest root domain

A first step in the AD DS design process is to determine how many forests your organization requires. A forest is the top-level AD DS container, and consists of one or more domains that share a common schema and global catalog. An organization can have multiple forests, but for most organizations, a single forest design is the preferred model and the simplest to administer.

When you create the first domain controller in your organization, you are creating the first domain (also called the forest root domain) and the first forest. Before you take this action using this guide, however, you must determine the best domain name for your organization. In most cases, the organization name is used as the domain name, and in many cases this domain name is registered. If you are planning to deploy Web servers for your customers or partners, choose a domain name and ensure that the domain name is not already in use.

Planning the forest functional level

While installing AD DS, you must choose the forest functional level that you want to use. Domain and forest functionality, introduced in Windows Server 2003 Active Directory, provides a way to enable domain- or forest-wide Active Directory features within your network environment. Different levels of domain functionality and forest functionality are available, depending on your environment.

Forest functionality enables features across all the domains in your forest. The following forest functional levels are available:

  • Windows 2000. This forest functional level supports Windows NT 4.0, Windows 2000, and Windows Server 2003 domain controllers.

  • Windows Server 2003. This forest functional level supports only Windows Server 2003 domain controllers and domain controllers that are running later versions of the Windows Server operating system.

  • Windows Server 2008. This forest functional level supports only domain controllers that are running Windows Server 2008 and later versions of the Windows Server operating system.

  • Windows Server 2008 R2. This forest functional level supports Windows Server 2008 R2 domain controllers and domain controllers that are running later versions of the Windows Server operating system.

If you are deploying a new domain in a new forest and all of your domain controllers will be running Windows Server 2008 R2, it is recommended that you configure AD DS with the Windows Server 2008 R2 forest functional level during AD DS installation.

Important

After the forest functional level has been raised, domain controllers running earlier operating systems cannot be introduced into the forest. For example, if you raise the forest functional level to Windows Server 2008 R2, domain controllers running Windows Server 2003 or Windows Server 2008 cannot be added to the forest.

Example configuration items for AD DS are provided in the following table.

Configuration items: Example values:

Full DNS name

Examples:

  • example.com

  • corp.example.com

Forest functional level:

Windows 2000

The Windows 2000 forest functional level provides all AD DS features that are available in Windows 2000 Server. If you have domain controllers running later versions of the Windows Server operating system, some advanced features will not be available on those domain controllers while this forest is at the Windows 2000 functional level.

Windows Server 2003

The Windows Server 2003 forest functional level provides all features that are available in Windows 2000 forest functional level, and the following additional features:

  • Linked-value replication, which improves the replication of changes to group memberships.

  • More efficient generation of complex replication topologies by the Knowledge Consistency Checker (KCC).

  • Forest trust, which allows organizations to easily share internal resources across multiple forests. Any new domains that are created in this forest will automatically operate at the Windows Server 2003 domain functional level.

Windows Server 2008

This forest functional level does not provide any new features over the Windows Server 2003 forest functional level. However, it ensures that any new domains created in this forest will automatically operate at the Windows Server 2008 domain functional level, which does provide unique features.

Windows Server 2008 R2

The Windows Server 2008 R2 forest functional level provides all features that are available in the Windows Server 2008 forest functional level, and the following additional feature:

  • Recycle Bin. When enabled, Recycle Bin provides the ability to restore deleted objects in their entirety while Active Directory Domain Services is running.

Any new domains that are created in this forest will operate by default at the Windows Server 2008 R2 domain functional level.

  • Windows Server 2003

  • Windows Server 2008

  • Windows Server 2008 R2

Active Directory Domain Services Database folder location

E:\Configuration\

Or accept the default location.

Active Directory Domain Services Log files folder location

E:\Configuration\

Or accept the default location.

Active Directory Domain Services SYSVOL folder location

E:\Configuration\

Or accept the default location

Directory Restore Mode Administrator Password

J*p2leO4$F

Answer file name (optional)

AD DS_AnswerFile

Planning DNS zones

In DNS, a forward lookup zone is created by default during installation. A forward lookup zone allows computers and devices to query for another computer's or device's IP address based on its DNS name. In addition to a forward lookup zone, it is recommended that you create a DNS reverse lookup zone. With a DNS reverse lookup query, a computer or device can discover the name of another computer or device using its IP address. Deploying a reverse lookup zone typically improves DNS performance and greatly increases the success of DNS queries.

When you create a reverse lookup zone, the in-addr.arpa domain, which was defined in the DNS standards and reserved in the Internet DNS namespace to provide a practical and reliable way to perform reverse queries, is installed in DNS. To create the reverse namespace, subdomains within the in-addr.arpa domain are formed, using the reverse ordering of the numbers in the dotted-decimal notation of IP addresses.

The in-addr.arpa domain applies to all TCP/IP networks that are based on Internet Protocol version 4 (IPv4) addressing. The New Zone Wizard automatically assumes that you are using this domain when you create a new reverse lookup zone.

While you are running the New Zone Wizard, the following selections are recommended:

Configuration Items Example values

Zone type

Primary zone, and Store the zone in Active Directory is selected

Active Directory Zone Replication Scope

To all DNS servers in this domain

First Reverse Lookup Zone Name wizard page

IPv4 Reverse Lookup Zone

Second Reverse Lookup Zone Name wizard page

Network ID = 192.168.0.

Dynamic Updates

Allow only secure dynamic updates

Planning domain access

To log onto the domain, the computer must be a domain member computer and the user account must be created in AD DS before the logon attempt.

Note

You cannot log on to the domain with a user account that is located in the Security Accounts Manager (SAM) user accounts database on the local computer.

After the first successful logon with domain logon credentials, the logon settings persist unless the computer is removed from the domain or the logon settings are manually changed.

Before you log on to the domain:

  • Create user accounts in Active Directory Users and Computers. Each user must have an Active Directory Domain Services user account in Active Directory Users and Computers. For more information, see Create a User Account in Active Directory Users and Computers.

  • Ensure IP address configuration. To join a computer to the domain, the computer must have an IP address. In this guide, servers are configured with static IP addresses and client computers receive IP address leases from the DHCP server. For this reason, the DHCP server must be deployed before you join clients to the domain. For more information, see Deploying DHCP-01.

  • Join the computer to the domain. Any computer that provides or accesses network resources must be joined to the domain. For more information, see Join the Computer to the Domain.

Planning the deployment of WINS-01

If you determine that you need to deploy WINS as well as DNS on your network, you must plan how many WINS servers to deploy.

  • On smaller networks, a single WINS server can adequately service up to 10,000 clients for NetBIOS name resolution requests. To provide additional fault tolerance, you can configure a second computer running Windows Server® 2008 R2 or Windows Server® 2008 as a secondary, or backup, WINS server for clients. If you use only two WINS servers, you can easily configure them as replication partners. For simple replication between two servers, one server should be set as a pull partner and the other as a push partner. Replication can be either manual or automatic.

  • Large networks sometimes require more WINS servers for several reasons including, most importantly, the number of client connections per server. The number of users that each WINS server can support varies with usage patterns, data storage, and the processing capabilities of the WINS server computer.

When planning your servers, remember that each WINS server can simultaneously handle hundreds of registrations and queries per second.

Planning the deployment of DHCP-01

Following are key planning steps before installing the DHCP server role on DHCP-01.

Planning DHCP servers and DHCP forwarding

Because DHCP messages are broadcast messages, they are not forwarded between subnets by routers. If you have multiple subnets and want to provide DHCP service for each subnet, you must do one of the following:

  • Install a DHCP server on each subnet

  • Configure routers to forward DHCP broadcast messages across subnets and configure multiple scopes on the DHCP server, one scope per subnet.

In most cases, configuring routers to forward DHCP broadcast messages is more cost effective than deploying a DHCP server on each physical segment of the network.

Planning IP address ranges

Each subnet must have its own unique IP address range. These ranges are represented on a DHCP server with scopes.

A scope is an administrative grouping of IP addresses for computers on a subnet that use the DHCP service. The administrator first creates a scope for each physical subnet and then uses the scope to define the parameters used by clients.

A scope has the following properties:

  • A range of IP addresses from which to include or exclude addresses used for DHCP service lease offerings.

  • A subnet mask, which determines the subnet for a given IP address.

  • A scope name assigned when it is created.

  • Lease duration values, which are assigned to DHCP clients that receive dynamically allocated IP addresses.

  • Any DHCP scope options configured for assignment to DHCP clients, such as DNS server IP address, router/default gateway IP address, and WINS server IP address.

  • Reservations are optionally used to ensure that a DHCP client always receives the same IP address.

Before deploying your servers, list your subnets and the IP address range you want to use for each subnet.

Planning subnet masks

Network IDs and host IDs within an IP address are distinguished by using a subnet mask. Each subnet mask is a 32-bit number that uses consecutive bit groups of all ones (1) to identify the network ID and all zeroes (0) to identify the host ID portions of an IP address.

For example, the subnet mask normally used with the IP address 131.107.16.200 is the following 32-bit binary number:

11111111 11111111 00000000 00000000

This subnet mask number is 16 one-bits followed by 16 zero-bits, indicating that the network ID and host ID sections of this IP address are both 16 bits in length. Normally, this subnet mask is displayed in dotted decimal notation as 255.255.0.0.

The following table displays subnet masks for the Internet address classes.

Address class  Bits for subnet mask Subnet mask

Class A

11111111 00000000 00000000 00000000

255.0.0.0

Class B

11111111 11111111 00000000 00000000

255.255.0.0

Class C

11111111 11111111 11111111 00000000

255.255.255.0

When you create a scope in DHCP and you enter the IP address range for the scope, DHCP provides these default subnet mask values. Typically, default subnet mask values (as shown in the preceding table) are acceptable for most networks with no special requirements and where each IP network segment corresponds to a single physical network.

In some cases, you can use customized subnet masks to implement IP subnetting. With IP subnetting, you can subdivide the default host ID portion of an IP address to specify subnets, which are subdivisions of the original class-based network ID.

By customizing the subnet mask length, you can reduce the number of bits that are used for the actual host ID.

To prevent addressing and routing problems, you should make sure that all TCP/IP computers on a network segment use the same subnet mask and that each computer or device has an unique IP address.

Planning exclusion ranges

You can exclude IP addresses from distribution by the DHCP server by creating an exclusion range for each scope. You should use exclusions for all devices that are configured with a static IP address. The excluded addresses should include all IP addresses that you assigned manually to other servers, non-DHCP clients, diskless workstations, or Routing and Remote Access and PPP clients.

It is recommended that you configure your exclusion range with extra addresses to accommodate future network growth. The following table provides an example exclusion range for a scope with an IP address range of 192.168.0.1 - 192.168.0.254.

Configuration items: Example values:

Exclusion range Start IP Address

192.168.0.1

Exclusion range End IP Address

192.168.0.15

Planning TCP/IP static configuration

Certain devices, such as routers, DHCP servers, and DNS servers, must be configured with a static IP address. In addition, you might have additional devices, such as printers, that you want to ensure always have the same IP address. List the devices that you want to configure statically for each subnet, and then plan the exclusion range you want to use on the DHCP server to ensure that the DHCP server does not lease the IP address of a statically configured device. An exclusion range is a limited sequence of IP addresses within a scope, excluded from DHCP service offerings. Exclusion ranges assure that any addresses in these ranges are not offered by the server to DHCP clients on your network.

For example, if the IP address range for a subnet is 192.168.0.1 through 192.168.0.254 and you have ten devices that you want to configure with a static IP address, you can create an exclusion range for the 192.168.0.x scope that includes ten or more IP addresses: 192.168.0.1 through 192.168.0.15.

In this example, you use ten of the excluded IP addresses to configure servers and other devices with static IP addresses and five additional IP addresses are left available for static configuration of new devices that you might want to add in the future. With this exclusion range, the DHCP server is left with an address pool of 192.168.0.16 through 192.168.0.254.

Additional example configuration items for AD DS and DNS are provided in the following table.

Configuration items: Example values:

Network Connect Bindings

Local Area Connection 2

DNS Server Settings

AD-DNS-01

Preferred DNS server IP address

192.168.0.1

Alternate DNS server IP Address

192.168.0.6

WINS Server Settings, specify the IP address of your preferred WINS server, only if WINS is deployed on the network.

192.168.0.2

Alternate WINS server IP Address

Note
Specify the IP address of your alternate WINS server only if an alternate WINS server is deployed on the network.

192.168.0.12

Add Scope dialog box values:

  • Scope Name:

  • Starting IP Address

  • Ending IP Address:

  • Subnet Mask

  • Default Gateway (optional)

  • Subnet Type

  • Primary Subnet

  • 192.168.0.1

  • 192.168.0.254

  • 255.255.255.0

  • 192.168.0.11

  • Wired (Lease duration will be 6 days)

IPv6 DHCP Server Operation Mode

Not enabled

Planning the deployment of NPS-01

If you intend to deploy network access servers, such as wireless access points or VPN servers, after deploying your core network, it is recommended that you deploy NPS.

When you use NPS as a Remote Authentication Dial-In User Service (RADIUS) server, NPS performs authentication and authorization for connection requests through your network access servers. NPS also allows you to centrally configure and manage network policies that determine who can access the network, how they can access the network, and when they can access the network.

Following are key planning steps before installing NPS.

  • Plan the user accounts database. By default, if you join the server running NPS to an Active Directory domain, NPS performs authentication and authorization using the AD DS user accounts database. In some cases, such as with large networks that use NPS as a RADIUS proxy to forward connection requests to other RADIUS servers, you might want to install NPS on a non-domain member computer.

  • Plan the use of Network Access Protection (NAP). With some NAP enforcement methods, it is required that you install NPS on a specific server. For example, if you deploy NAP with DHCP, NPS must be installed on the DHCP server.

  • Plan RADIUS accounting. NPS allows you to log accounting data to a SQL Server database or to a text file on the local computer. If you want to use SQL Server logging, plan the installation and configuration of your server running SQL Server.