Windows Server 2012 Deployment and Administration Guide

Server Requirements and Deployment Planning

Careful evaluation of present and projected activity helps determine the appropriate server configuration. The number of servers required corresponds directly to the volume of functional data handling anticipated over the next three to five years. If a growth rate of 33% is projected, it is prudent to configure the physical server with 16 GB of RAM. As a general best practice, starting with 12 GB of RAM in a virtual machine and monitoring usage as the project expands is a sound approach (Serhad Makbuloglu, 2012).

The following table illustrates a sample RAM calculation for a base deployment:

Table 1: Calculation Summary Example

Component — Estimated Memory
Base Operating System Recommended RAM (Windows Server 2008): 2 GB
LSASS internal tasks, Monitoring Agent, Antivirus, Database (Global Catalog): variable GB
Cushion for backup and administrator logon without performance impact: 1 GB
Total: 12 GB

If the server is located on premises, a user would require approximately 7.5 MB of external bandwidth per day. Adding a margin for protocol overhead brings this figure to approximately 8 MB. Over an eight-hour working day, this averages to slightly more than a quarter of a kilobyte per second — a rate that would theoretically support thousands of users, even on a slow connection.

However, this calculation is superficial and potentially misleading, because it ignores many practical factors that affect real-world performance. For example, if an on-premises mail system is in place, it will likely handle a significant volume of spam. Spam generally outnumbers legitimate mail by as much as nine to one. In other words, if a firm receives 8 MB of actual mail, it should also expect up to 72 MB of spam. As a result, the effective bandwidth requirement rises to 2–7 Kbps, meaning the connection estimated to serve thousands of users may only realistically serve a few hundred (Peter Bright, 2012).

Windows Edition Selection

The standard edition of Windows — the x64-bit version — will be used. This ensures that even if Active Directory operates on a 2003 x86 architecture with a DIT smaller than 1.5 GB, the configuration described in this paper can still be applied and will perform satisfactorily. Capacity planning must be treated as a continuous activity. System efficiency should be monitored regularly, and upgrades made as conditions require. Optimization is typically achieved after several hardware deployment cycles, as the cost of hardware components changes over time — for instance, as memory prices decrease, cost per core also falls, and the cost of optional storage also shifts (Serhad Makbuloglu, 2012).

Planning should also account for peak periods during the day, broken into 30-minute or one-hour intervals. Intervals shorter or longer than this range can either conceal true peaks or smooth them out too broadly. It is also prudent to plan for growth in alignment with hardware lifecycle timelines. Options include adding hardware in a staggered fashion or replacing the entire infrastructure every three to five years. Regardless of the approach chosen, estimating the growth in Active Directory load is essential. Historical usage data, if available, can be a valuable resource in making such estimates (Serhad Makbuloglu, 2012).

Hyper-V Virtualization Considerations

The key concern when virtualizing domain controllers using Hyper-V is ensuring that the shared infrastructure can support both the domain controller (DC) load and other dependent resources, such as shared media and the pathways connecting to it. This applies whether the physical DC is co-located on shared NAS, iSCSI, or SAN infrastructure alongside other servers or applications; or whether it is a guest using pass-through access to such storage; or even a guest running a virtual disk file on locally shared or networked media (Serhad Makbuloglu, 2012).

The planning process is intended to ensure that the underlying storage media can support the total load. This is further complicated by the variety of storage options available, each of which carries a different performance impact. A multiplier of 1:10 is a useful adjustment factor when comparing storage options for Hyper-V virtualized guests — for example, when choosing between pass-through storage, IDE, or SCSI configurations. Adjustments between storage option types are independent of whether the storage medium is iSCSI, NAS, or SAN.

Server Site Placement

A server will be placed at each of the two sites for purposes of security, audit compliance, and operational safety.

Deployment Method: Windows Deployment Services

Windows operating systems can be deployed using Windows Deployment Services (WDS). WDS enables network-based installation, eliminating the need to install an operating system on each computer individually from physical installation media (Windows Deployment Services Getting Started Guide for Windows Server 2012, n.d.).

To install WDS using Server Manager:

a. Click Manage
b. Select Add Roles and Features
c. Choose Role-based or Feature-based Installation and select the target server
d. On the Select Server Roles page, select Windows Deployment Services
e. Click Next and follow the wizard to complete the installation.

DNS Namespace Design and Multi-Site Handling

On the Select Role Services page, the wizard offers the option to install the Deployment Server, the Transport Server, or neither. Select the appropriate role service based on the deployment scenario.

Windows operations are heavily dependent on DNS name resolution. Without a well-designed naming system, users cannot locate network resources. The DNS namespace should be designed in conjunction with Active Directory. The internal namespace of an organization must not conflict with any existing external namespace on the internet (DNS Namespace Planning, n.d.).

For organizations operating across multiple sites, there are two primary approaches to DNS namespace management (Planning and Implementing a DNS Namespace, n.d.):

The first option is to register multiple second-level domains — one for each name required. Note that each domain registration carries a fee, and a separate DNS infrastructure must be maintained for each registered domain.

The second option is to register a single second-level domain and create multiple subdomains beneath it. This approach is generally simpler to manage and reduces registration overhead.