Contents

Networking documentation
Windows Server supported networking scenarios
What's new in networking
Core network guidance for Windows Server
Core network components
Core network companion guidance
Deploy server certificates for 802.1X wired and wireless deployments
Server certificate deployment overview
Server certificate deployment planning
Server certificate deployment
Install the Web Server WEB1
Create an alias (CNAME) record in DNS for WEB1
Configure WEB1 to distribute certificate revocation lists (CRLs)
Prepare the CAPolicy.inf File
Install the Certification Authority
Configure the CDP and AIA Extensions on CA1
Copy the CA certificate and CRL to the virtual directory
Configure the server certificate template
Configure server certificate autoenrollment
Refresh group policy
Verify server enrollment of a server certificate
Deploy password-based 802.1X authenticated wireless access
Wireless access deployment overview
Wireless access deployment process
Wireless access deployment planning
Wireless access deployment
Deploy BranchCache hosted cache mode
BranchCache hosted cache mode deployment overview
BranchCache hosted cache mode deployment planning
 BranchCache hosted cache mode deployment
Install the BranchCache feature and configure the hosted cache server by
Service Connection Point
Move and resize the hosted cache (Optional)
Prehash and preload content on the hosted cache server (Optional)
Configure client automatic hosted cache discovery by Service Connection Point
Additional resources
BranchCache
BranchCache netsh and Windows PowerShell commands
BranchCache deployment guidance
Choosing a BranchCache design
Deploy BranchCache
Install and configure content servers
Install content servers that use the BranchCache feature
Install File Services content servers
Deploy hosted cache servers (Optional)
Prehashing and preloading content on hosted cache servers (Optional)
Configure BranchCache client computers
Use group policy to configure domain member client computers
Use Windows PowerShell to configure non-domain member client computers
Verify client computer settings
DirectAccess
Domain Name System (DNS)
What's new in DNS client in Windows Server
What's new in DNS server in Windows Server
DNS policy scenario guidance
DNS policies overview
Use DNS policy for geo-location traffic management with primary servers
Use DNS policy for geo-location traffic management with primary-secondary
deployments
Use DNS policy for intelligent DNS responses based on time of day
DNS responses based on time of day with an Azure cloud app server
Use DNS policy for Split-Brain DNS deployment
 Use DNS policy for Split-Brain DNS in Active Directory
Use DNS policy for applying filters on DNS queries
Use DNS policy for app load balancing
Use DNS policy for app load balancing with geo-location awareness
Troubleshooting DNS issues
Troubleshooting DNS clients
Disable DNS client-side caching on DNS clients
Troubleshooting DNS servers
Dynamic Host Configuration Protocol (DHCP)
What's new in DHCP
DHCP subnet selection options
DHCP logging events for DNS record registrations
Deploy DHCP using Windows PowerShell
Troubleshoot DHCP issues
Dynamic Host Configuration Protocol (DHCP) Basics
General guidance to troubleshoot DHCP
How to use automatic TCP/IP addressing without a DHCP server
Troubleshoot problems on the DHCP client
Troubleshoot problems on the DHCP server
High-Performance Networking (HPN)
Network offload and optimization technologies
Software only (SO) features and technologies
Software and hardware (SH) integrated features and technologies
Hardware Only (HO) features and technologies
NIC advanced properties
Insider preview
Receive Segment Coalescing (RSC) in the vSwitch
Converged NIC configuration guidance
Single network adapter configuration
Datacenter network adapter configuration
Physical switch configuration
Troubleshooting Converged NIC
 Data Center Bridging \(DCB\)
Install DCB
Manage DCB
Virtual Receive Side Scaling (vRSS)
Plan the use of vRSS
Enable vRSS on a virtual network adapter
Manage vRSS
vRSS FAQ
Windows PowerShell commands for RSS and vRSS
Resolve vRSS issues
Host Compute Network (HCN) Service API
Common HCN scenarios
RPC context handles for HCN
HCN JSON document schemas
Example of C# generated code
Example of Go generated code
Hyper-V Virtual Switch
IP Address Management (IPAM)
What's new in IPAM
Manage IPAM
DNS resource record management
Add a DNS resource record
Delete DNS resource records
Filter the view of DNS resource records
View DNS resource records for a specific IP address
DNS zone management
Create a DNS zone
Edit a DNS zone
View DNS resource records for a DNS zone
View DNS zones
Manage resources in multiple active directory forests
Purge utilization data
 Role-based access control
Manage role-based access control with Server Manager
Create a user role for access control
Create an access policy
Set access scope for a DNS zone
Set access scope for DNS resource records
View roles and role permissions
Manage role-based access control with Windows PowerShell
Network Load Balancing
Network Policy Server (NPS)
NPS best practices
Getting started with NPS
Connection request processing
Connection request policies
Realm names
Remote RADIUS server groups
Network policies
Access permission
NPS templates
RADIUS clients
Plan NPS
Plan NPS as a RADIUS server
Plan NPS as a RADIUS proxy
Deploy NPS
Manage NPS
Network Policy Server Management with Administration Tools
Configure connection request policies
Configure firewalls for RADIUS traffic
Configure network policies
Configure NPS Accounting
Configure RADIUS clients
Configure remote RADIUS server groups
 Manage certificates used with NPS
Configure certificate templates for PEAP and EAP requirements
Manage NPSs
Configure NPS on a multihomed computer
Configure NPS UDP port information
Disable NAS notification forwarding
Export an NPS configuration for import on another server
Increase concurrent authentications processed by NPS
Install NPS
NPS proxy server load balancing
Register an NPS in an Active Directory Domain
Unregister an NPS from an Active Directory Domain
Use regular expressions in NPS
Verify configuration after NPS changes
NPS data collection
Manage NPS templates
Network Shell (Netsh)
Netsh command syntax, contexts, and formatting
Network Shell (Netsh) example batch file
Netsh http commands
Netsh interface portproxy commands
Netsh mbn commands
Network subsystem performance tuning
Choosing a network adapter
Configure the order of network interfaces
Performance tuning network adapters
Network-related performance counters
Performance tools for network workloads
NIC Teaming
NIC Teaming MAC address use and management
Create a New NIC Team on a host computer or VM
Troubleshooting NIC Teaming
Quality of Service (QoS) policy
Getting started with QoS policy
How QoS policy works
QoS policy architecture
QoS policy scenarios
Manage QoS policy
QoS policy events and errors
QoS policy FAQ
Software Defined Networking (SDN)
SDN in Windows Server overview
SDN technologies
Hyper-V network virtualization
Hyper-V network virtualization overview
Hyper-V network virtualization technical details
What's new in Hyper-V Network virtualization
Internal DNS service (iDNS) for SDN
Network Controller
Network Controller high availability
Install the Network Controller server role using Server Manager
Post-deployment steps for Network Controller
Network function virtualization
Datacenter firewall overview
RAS Gateway for SDN
What's new in RAS Gateway
RAS Gateway deployment architecture
RAS Gateway high availability
Software Load Balancing (SLB) for SDN
Switch Embedded Teaming (SET) for SDN
Container networking
Plan for SDN
Installation and preparation requirements for deploying Network Controller
Deploy SDN
 Deploy an SDN Infrastructure
Deploy an SDN infrastructure using scripts
Deploy SDN technologies using Windows PowerShell
Deploy Network Controller using Windows PowerShell
Manage SDN
Manage tenant virtual networks
Understanding usage of virtual networks and VLANs
Use Access Control lists (ACLs) to manage datacenter network traffic flow
Create, delete, or update tenant virtual networks
Add a virtual gateway to a tenant virtual network
Connect container endpoints to a tenant virtual network
Configure encryption for a virtual subnet
Egress metering in a virtual network
Manage tenant workloads
Create a VM and connect to a tenant virtual network or VLAN
Configure QoS for a tenant VM network adapter
Configure datacenter firewall ACLs
Configure the Software Load Balancer for load balancing and Network address
Translation (NAT)
Use network virtual appliances on a virtual network
Guest clustering in a virtual network
Update, backup, and restore an SDN infrastructure
Security for SDN
Secure the Network Controller
Manage certificates for SDN
Kerberos with Service Principal Name (SPN)
SDN firewall auditing
Virtual network peering
Configure virtual network peering
Windows Server 2019 gateway performance
Gateway bandwidth allocation
Troubleshoot SDN
Troubleshoot the Windows Server Software Defined Networking Stack
 System Center Technologies for SDN
Microsoft Azure and SDN
Contact the Datacenter and Cloud Networking Team
Virtual Private Networking (VPN)
Windows Internet Name Service (WINS)
Windows Time service
Insider preview - Windows Time service in Windows Server 2019
Accurate time for Windows Server 2016
Support boundary for high-accuracy time
Configuring systems for high accuracy
Windows Time for traceability
Windows Time service technical reference
How the Windows Time service works
Windows Time service tools and settings
 Windows Server supported networking scenarios
4/7/2020 • 4 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This topic provides information about supported and unsupported scenarios that you can or cannot perform with
this release of Windows Server 2016.

IMPORTANT
For all production scenarios, use the latest signed hardware drivers from your original equipment manufacturer (OEM) or
independent hardware vendor (IHV).

Supported Networking Scenarios

This section includes information about the supported networking scenarios for Windows Server 2016, and
includes the following scenario categories.
Software Defined Networking (SDN) scenarios
Network Platform scenarios
DNS Server scenarios
IPAM scenarios with DHCP and DNS
NIC Teaming scenarios
Switch Embedded Teaming (SET) scenarios
Software Defined Networking (SDN ) scenarios
You can use the following documentation to deploy SDN scenarios with Windows Server 2016.
Deploy a Software Defined Network infrastructure using scripts
For more information, see Software Defined Networking (SDN).
Network Controller scenarios
The Network Controller scenarios allow you to:
Deploy and manage a multiple-node instance of Network Controller. For more information, see Deploy
Network Controller using Windows PowerShell.
Use Network Controller to programmatically define network policy by using the REST Northbound API.
Use Network Controller to create and manage virtual networks with Hyper-V Network Virtualization - using
NVGRE or VXLAN encapsulation.
For more information, see Network Controller.
Network Function Virtualization (NFV) scenarios
The NFV scenarios allow you to:
Deploy and use a software load balancer to distribute both northbound and southbound traffic.
 Deploy and use a software load balancer to distribute eastbound and westbound traffic for virtual networks
created with Hyper-V Network Virtualization.
Deploy and use a NAT software load balancer for virtual networks created with Hyper-V Network
Virtualization.
Deploy and use a Layer 3 forwarding gateway
Deploy and use a virtual private network (VPN) gateway for site-to-site IPsec (IKEv2) tunnels
Deploy and use a Generic Routing Encapsulation (GRE) gateway.
Deploy and configure dynamic routing and transit routing between sites using Border Gateway Protocol
(BGP).
Configure M+N redundancy for Layer 3 and site-to-site gateways, and for BGP routing.
Use Network Controller to specify ACLs on virtual networks and network interfaces.
For more information, see Network Function Virtualization.
Network Platform scenarios
For the scenarios in this section the Windows Server Networking team supports the use of any Windows Server
2016 certified driver. Please check with your network interface card (NIC) manufacturer to ensure you have the
most recent driver updates.
The network platform scenarios allow you to:
Use a converged NIC to combine both RDMA and Ethernet traffic using a single network adapter.
Create a low-latency data path by using Packet Direct, enabled in the Hyper-V Virtual Switch, and a single
network adapter.
Configure SET to spread SMB Direct and RDMA traffic flows between up to two network adapters.
For more information, see Remote Direct Memory Access (RDMA) and Switch Embedded Teaming (SET).
Hyper-V Virtual Switch Scenarios
The Hyper-V Virtual Switch scenarios allow you to:
Create a Hyper-V Virtual Switch with a Remote Direct Memory Access (RDMA) vNIC
Create a Hyper-V Virtual Switch with Switch Embedded Teaming (SET) and RDMA vNICs
Create a SET team in Hyper-V Virtual Switch
Manage a SET team by using Windows PowerShell commands
For more information, see Remote Direct Memory Access (RDMA) and Switch Embedded Teaming (SET)
DNS Server scenarios
DNS Server scenarios allow you to:
Specify Geo-Location based traffic management using DNS Policies
Configure split-brain DNS using DNS Policies
Apply filters on DNS queries using DNS Policies
Configure Application Load Balancing using DNS Policies
Specify Intelligent DNS Responses based on the time of day
 Configure DNS Zone transfer policies
Configure DNS server policies on Active Directory Domain Services (AD DS) integrated zones
Configure Response Rate Limiting
Specify DNS-based Authentication of Named Entities (DANE)
Configure support for Unknown Records in DNS
For more information, see the topics What's New in DNS Client in Windows Server 2016 and What's New in DNS
Server in Windows Server 2016.
IPAM scenarios with DHCP and DNS
The IPAM scenarios allow you to:
Discover and administer DNS and DHCP servers and IP addressing across multiple federated Active
Directory forests
Use IPAM for centralized management of DNS properties, including zones and resource records.
Define granular role-based access control policies and delegate IPAM users or user groups to manage the set
of DNS properties that you specify.
Use the Windows PowerShell commands for IPAM to automate access control configuration for DHCP and
DNS.
For more information, see Manage IPAM.
NIC Teaming scenarios
The NIC Teaming scenarios allow you to:
Create a NIC team in a supported configuration
Delete a NIC team
Add network adapters to the NIC team in a supported configuration
Remove network adapters from the NIC team

NOTE
In Windows Server 2016, you can use NIC Teaming in Hyper-V, however in some cases Virtual Machine Queues (VMQ) might
not automatically enable on the underlying network adapters when you create a NIC Team. If this occurs, you can use the
following Windows PowerShell command to ensure that VMQ is enabled on the NIC team member adapters:
Set-NetAdapterVmq -Name <NetworkAdapterName> -Enable

For more information, see NIC Teaming.

Switch Embedded Teaming (SET ) scenarios
SET is an alternative NIC Teaming solution that you can use in environments that include Hyper-V and the Software
Defined Networking (SDN) stack in Windows Server 2016. SET integrates some NIC Teaming functionality into the
Hyper-V Virtual Switch.
For more information, see Remote Direct Memory Access (RDMA) and Switch Embedded Teaming (SET)

Unsupported Networking Scenarios

The following networking scenarios are not supported in Windows Server 2016.
VLAN-based tenant virtual networks.
IPv6 is not supported in either the underlay or overlay.
 What's new in networking
4/7/2020 • 8 minutes to read • Edit Online

Applies to: Windows Server 2016

Following are the new or enhanced networking technologies in Windows Server 2016.
Upd This topic contains the following sections.
New Networking Features and Technologies
New Features for Additional Networking Technologies

New Networking Features and Technologies

Networking is a foundational part of the Software Defined Datacenter (SDDC) platform, and Windows Server 2016
provides new and improved Software Defined Networking (SDN) technologies to help you move to a fully realized
SDDC solution for your organization.
When you manage networks as a software defined resource, you can describe an application's infrastructure
requirements one time, and then choose where the application runs - on premises or in the cloud. This consistency
means that your applications are now easier to scale and you can seamlessly run applications , anywhere, with
equal confidence around security, performance, quality of service, and availability.
The following sections contain information about these new networking features and technologies.
Software Defined Networking Infrastructure
Following are the new or improved SDN infrastructure technologies.
Network Controller . New in Windows Server 2016, Network Controller provides a centralized,
programmable point of automation to manage, configure, monitor, and troubleshoot virtual and physical
network infrastructure in your datacenter. Using Network Controller, you can automate the configuration of
network infrastructure instead of performing manual configuration of network devices and services. For
more information, see Network Controller and Deploy Software Defined Networks using scripts.
Hyper-V Vir tual Switch . The Hyper-V Virtual Switch runs on Hyper-V hosts, and allows you to create
distributed switching and routing, and a policy enforcement layer that is aligned and compatible with
Microsoft Azure. For more information, see Hyper-V Virtual Switch.
Network Function Vir tualization (NFV) . In today's software defined datacenters, network functions that
are being performed by hardware appliances (such as load balancers, firewalls, routers, switches, and so on)
are increasingly being deployed as virtual appliances. This "network function virtualization" is a natural
progression of server virtualization and network virtualization. Virtual appliances are quickly emerging and
creating a brand new market. They continue to generate interest and gain momentum in both virtualization
platforms and cloud services. The following NFV technologies are available in Windows Server 2016.
Datacenter Firewall . This distributed firewall provides granular access control lists (ACLs), enabling
you to apply firewall policies at the VM interface level or at the subnet level.
For more information, see Datacenter Firewall Overview.
RAS Gateway . You can use RAS Gateway for routing traffic between virtual networks and physical
networks, including site-to-site VPN connections from your cloud datacenter to your tenants' remote
sites. Specifically, you can deploy Internet Key Exchange version 2 (IKEv2) site-to-site virtual private
 networks (VPNs), Layer 3 (L3) VPN, and Generic Routing Encapsulation (GRE) gateways. In addition,
gateway pools and M+N redundancy of gateways are now supported; and Border Gateway Protocol
(BGP) with Route Reflector capabilities provides dynamic routing between networks for all gateway
scenarios (IKEv2 VPN, GRE VPN, and L3 VPN).
For more information, see What's New in RAS Gateway and RAS Gateway for SDN.
Software Load Balancer (SLB) and Network Address Translation (NAT) . The north-south and
east-west layer 4 load balancer and NAT enhances throughput by supporting Direct Server Return,
with which the return network traffic can bypass the Load Balancing multiplexer.
For more information, see Software Load Balancing (SLB) for SDN.
For more information, see Network Function Virtualization.
Standardized Protocols . Network Controller uses Representational State Transfer (REST) on its
northbound interface with JavaScript Object Notation (JSON) payloads. The Network Controller southbound
interface uses Open vSwitch Database Management Protocol (OVSDB).
Flexible encapsulation technologies . These technologies operate at the data plane, and support both
Virtual Extensible LAN (VxLAN) and Network Virtualization Generic Routing Encapsulation (NVGRE). For
more information, see GRE Tunneling in Windows Server 2016.
For more information about SDN, see Software Defined Networking (SDN).
Cloud Scale Fundamentals
The following cloud scale fundamentals are now available.
Converged Network Interface Card (NIC) . The converged NIC allows you to use a single network
adapter for management, Remote Direct Memory Access (RDMA)-enabled storage, and tenant traffic. This
reduces the capital expenditures that are associated with each server in your datacenter, because you need
fewer network adapters to manage different types of traffic per server.
Packet Direct . Packet Direct provides a high network traffic throughput and low-latency packet processing
infrastructure.
Switch Embedded Teaming (SET) . SET is a NIC Teaming solution that is integrated in the Hyper-V Virtual
Switch. SET allows the teaming of up to eight physical NICS into a single SET team, which improves
availability and provides failover. In Windows Server 2016, you can create SET teams that are restricted to
the use of Server Message Block (SMB) and RDMA. In addition, you can use SET teams to distribute network
traffic for Hyper-V Network Virtualization. For more information, see Remote Direct Memory Access (RDMA)
and Switch Embedded Teaming (SET).

New Features for Additional Networking Technologies

This section contains information about new features for familiar networking technologies.

DHCP
DHCP is an Internet Engineering Task Force (IETF) standard that is designed to reduce the administrative burden and
complexity of configuring hosts on a TCP/IP-based network, such as a private intranet. By using the DHCP Server
service, the process of configuring TCP/IP on DHCP clients is automatic.
For more information, see What's New in DHCP.

DNS
DNS is a system that is used in TCP/IP networks for naming computers and network services. DNS naming locates
computers and services through user-friendly names. When a user enters a DNS name in an application, DNS
services can resolve the name to other information that is associated with the name, such as an IP address.
Following is information about DNS Client and DNS Server.
DNS Client
Following are the new or improved DNS client technologies.
DNS Client ser vice binding . In Windows 10, the DNS Client service offers enhanced support for computers
with more than one network interface.
For more information, see What's New in DNS Client in Windows Server 2016
DNS Server
Following are the new or improved DNS server technologies.
DNS Policies . You can configure DNS policies to specify how a DNS server responds to DNS queries. DNS
responses can be based on client IP address (location), time of the day, and several other parameters. DNS
policies enable location-aware DNS, traffic management, load balancing, split-brain DNS, and other
scenarios.
Nano Ser ver suppor t for file based DNS , You can deploy DNS server in Windows Server 2016 on a
Nano Server image. This deployment option is available to you if you are using file based DNS. By running
DNS server on a Nano Server image, you can run your DNS servers with reduced footprint, quick boot up,
and minimized patching.

NOTE
Active Directory integrated DNS is not supported on Nano Server.

Response Rate Limiting (RRL) . You can enable response rate limiting on your DNS servers. By doing this,
you avoid the possibility of malicious systems using your DNS servers to initiate a denial of service attack on
a DNS client.
DNS-based Authentication of Named Entities (DANE) . You can use TLSA (Transport Layer Security
Authentication) records to provide information to DNS clients that state what certification authority (CA) they
should expect a certificate from for your domain name. This prevents man-in-the-middle attacks where
someone might corrupt the DNS cache to point to their own website, and provide a certificate they issued
from a different CA.
Unknown record suppor t .
You can add records which are not explicitly supported by the Windows DNS server using the unknown
record functionality.
IPv6 root hints .
You can use the native IPV6 root hints support to perform internet name resolution using the IPV6 root
servers.
Improved Windows PowerShell Suppor t .
New Windows PowerShell cmdlets are available for DNS Server.
For more information, see What's New in DNS Server in Windows Server 2016

GRE Tunneling
RAS Gateway now supports high availability Generic Routing Encapsulation (GRE) tunnels for site to site
connections and M+N redundancy of gateways. GRE is a lightweight tunneling protocol that can encapsulate a wide
variety of network layer protocols inside virtual point-to-point links over an Internet Protocol internetwork.
For more information, see GRE Tunneling in Windows Server 2016.

Hyper-V Network Virtualization

Introduced in Windows Server 2012, Hyper-V Network Virtualization (HNV) enables virtualization of customer
networks on top of a shared physical network infrastructure. With minimal changes necessary on the physical
network fabric, HNV gives service providers the agility to deploy and migrate tenant workloads anywhere across
the three clouds: the service provider cloud, the private cloud, or the Microsoft Azure public cloud.
For more information, see What's New in Hyper-V Network Virtualization in Windows Server 2016

IPAM
IPAM provides highly customizable administrative and monitoring capabilities for the IP address and DNS
infrastructure on an organization network. Using IPAM, you can monitor, audit, and manage servers that are
running Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS).
Enhanced IP address management .
IPAM capabilities are improved for scenarios such as handling IPv4 /32 and IPv6 /128 subnets and finding
free IP address subnets and ranges in an IP address block.
Enhanced DNS ser vice management .
IPAM supports DNS resource record, conditional forwarder, and DNS zone management for both domain-
joined Active Directory-integrated and file-backed DNS servers.
Integrated DNS, DHCP, and IP address (DDI) management .
Several new experiences and integrated lifecycle management operations are enabled, such as visualizing all
DNS resource records that pertain to an IP address, automated inventory of IP addresses based on DNS
resource records, and IP address lifecycle management for both DNS and DHCP operations.
Multiple Active Director y Forest suppor t .
You can use IPAM to manage the DNS and DHCP servers of multiple Active Directory forests when there is a
two-way trust relationship between the forest where IPAM is installed and each of the remote forests.
Windows PowerShell suppor t for Role Based Access Control .
You can use Windows PowerShell to set access scopes on IPAM objects.
For more information, see What's New in IPAM and Manage IPAM.
 Core network guidance for Windows Server
4/7/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server, Windows Server 2016

This topic provides an overview of the Core network guidance for Windows Server® 2016, and contains the
following sections.
Introduction to the Windows Server Core Network
Core Network Guide for Windows Server

Introduction to the Windows Server Core Network

A core network is a collection of network hardware, devices, and software that provides the fundamental services
for your organization's information technology (IT) needs.
A Windows Server core network provides you with many benefits, including the following.
Core protocols for network connectivity between computers and other Transmission Control
Protocol/Internet Protocol (TCP/IP) compatible devices. TCP/IP is a suite of standard protocols for connecting
computers and building networks. TCP/IP is network protocol software provided with Microsoft®
Windows® operating systems that implements and supports the TCP/IP protocol suite.
Dynamic Host Configuration Protocol (DHCP) server automatic IP addressing. Manual configuration of IP
addresses on all computers on your network is time-consuming and less flexible than dynamically providing
computers and other devices with IP address leases from a DHCP server.
Domain Name System (DNS) name resolution service. DNS allows users, computers, applications, and
services to find the IP addresses of computers and devices on the network by using the Fully Qualified
Domain Name of the computer or device.
A forest, which is one or more Active Directory domains that share the same class and attribute definitions
(schema), site and replication information (configuration), and forest-wide search capabilities (global
catalog).
A forest root domain, which is the first domain created in a new forest. The Enterprise Admins and Schema
Admins groups, which are forest-wide administrative groups, are located in the forest root domain. In
addition, a forest root domain, as with other domains, is a collection of computer, user, and group objects
that are defined by the administrator in Active Directory Domain Services (AD DS). These objects share a
common directory database and security policies. They can also share security relationships with other
domains if you add domains as your organization grows. The directory service also stores directory data
and allows authorized computers, applications, and users to access the data.
A user and computer account database. The directory service provides a centralized user accounts database
that allows you to create user and computer accounts for people and computers that are authorized to
connect to your network and access network resources, such as applications, databases, shared files and
folders, and printers.
A core network also allows you to scale your network as your organization grows and IT requirements change. For
example, with a core network you can add domains, IP subnets, remote access services, wireless services, and other
features and server roles provided by Windows Server 2016.
Core Network Guide for Windows Server
The Windows Server 2016 Core Network Guide provides instructions on how to plan and deploy the core
components required for a fully functioning network and a new Active Directory® domain in a new forest. Using
this guide, you can deploy computers configured with the following Windows server components:
The Active Directory Domain Services (AD DS) server role
The Domain Name System (DNS) server role
The Dynamic Host Configuration Protocol (DHCP) server role
The Network Policy Server (NPS) role service of the Network Policy and Access Services server role
The Web Server (IIS) server role
Transmission Control Protocol/Internet Protocol version 4 (TCP/IP) connections on individual servers
This guide is available at the following location.
The Core Network Guide in the Windows Server 2016 Technical Library.
 Core network components
4/7/2020 • 72 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This guide provides instructions on how to plan and deploy the core components required for a fully functioning
network and a new Active Directory domain in a new forest.

NOTE
This guide is available for download in Microsoft Word format from TechNet Gallery. For more information, see Core Network
Guide for Windows Server 2016.

This guide contains the following sections.

About this guide
Core Network Overview
Core Network Planning
Core Network Deployment
Additional Technical Resources
Appendices A through E

About this guide

This guide is designed for network and system administrators who are installing a new network or who want to
create a domain-based network to replace a network that consists of workgroups. The deployment scenario
provided in this guide is particularly useful if you foresee the need to add more services and features to your
network in the future.
It is recommended that you review design and deployment guides for each of the technologies used in this
deployment scenario to assist you in determining whether this guide provides the services and configuration that
you need.
A core network is a collection of network hardware, devices, and software that provides the fundamental services
for your organization's information technology (IT) needs.
A Windows Server core network provides you with many benefits, including the following.
Core protocols for network connectivity between computers and other Transmission Control
Protocol/Internet Protocol (TCP/IP) compatible devices. TCP/IP is a suite of standard protocols for
connecting computers and building networks. TCP/IP is network protocol software provided with Microsoft
Windows operating systems that implements and supports the TCP/IP protocol suite.
Dynamic Host Configuration Protocol (DHCP) automatic IP address assignment to computers and other
devices that are configured as DHCP clients. Manual configuration of IP addresses on all computers on your
network is time-consuming and less flexible than dynamically providing computers and other devices with
IP address configurations using a DHCP server.
Domain Name System (DNS) name resolution service. DNS allows users, computers, applications, and
 services to find the IP addresses of computers and devices on the network by using the Fully Qualified
Domain Name of the computer or device.
A forest, which is one or more Active Directory domains that share the same class and attribute definitions
(schema), site and replication information (configuration), and forest-wide search capabilities (global
catalog).
A forest root domain, which is the first domain created in a new forest. The Enterprise Admins and Schema
Admins groups, which are forest-wide administrative groups, are located in the forest root domain. In
addition, a forest root domain, as with other domains, is a collection of computer, user, and group objects
that are defined by the administrator in Active Directory Domain Services (AD DS). These objects share a
common directory database and security policies. They can also share security relationships with other
domains if you add domains as your organization grows. The directory service also stores directory data
and allows authorized computers, applications, and users to access the data.
A user and computer account database. The directory service provides a centralized user accounts database
that allows you to create user and computer accounts for people and computers that are authorized to
connect to your network and access network resources, such as applications, databases, shared files and
folders, and printers.
A core network also allows you to scale your network as your organization grows and IT requirements change. For
example, with a core network you can add domains, IP subnets, remote access services, wireless services, and
other features and server roles provided by Windows Server 2016.
Network hardware requirements
To successfully deploy a core network, you must deploy network hardware, including the following:
Ethernet, Fast Ethernet, or Gigabyte Ethernet cabling
A hub, Layer 2 or 3 switch, router, or other device that performs the function of relaying network traffic
between computers and devices.
Computers that meet the minimum hardware requirements for their respective client and server operating
systems.

What this guide does not provide

This guide does not provide instructions for deploying the following:
Network hardware, such as cabling, routers, switches, and hubs
Additional network resources, such as printers and file servers
Internet connectivity
Remote access
Wireless access
Client computer deployment

NOTE
Computers running Windows client operating systems are configured by default to receive IP address leases from the DHCP
server. Therefore, no additional DHCP or Internet Protocol version 4 (IPv4) configuration of client computers is required.

Technology Overviews
The following sections provide brief overviews of the required technologies that are deployed to create a core
network.
Active Directory Domain Services
A directory is a hierarchical structure that stores information about objects on the network, such as users and
computers. A directory service, such as AD DS, provides the methods for storing directory data and making this
data available to network users and administrators. For example, AD DS stores information about user accounts,
including names, email addresses, passwords, and phone numbers, and enables other authorized users on the
same network to access this information.
DNS
DNS is a name resolution protocol for TCP/IP networks, such as the Internet or an organization network. A DNS
server hosts the information that enables client computers and services to resolve easily recognized, alphanumeric
DNS names to the IP addresses that computers use to communicate with each other.
DHCP
DHCP is an IP standard for simplifying the management of host IP configuration. The DHCP standard provides for
the use of DHCP servers as a way to manage dynamic allocation of IP addresses and other related configuration
details for DHCP-enabled clients on your network.
DHCP allows you to use a DHCP server to dynamically assign an IP address to a computer or other device, such as
a printer, on your local network. Every computer on a TCP/IP network must have a unique IP address, because the
IP address and its related subnet mask identify both the host computer and the subnet to which the computer is
attached. By using DHCP, you can ensure that all computers that are configured as DHCP clients receive an IP
address that is appropriate for their network location and subnet, and by using DHCP options, such as default
gateway and DNS servers, you can automatically provide DHCP clients with the information that they need to
function correctly on your network.
For TCP/IP-based networks, DHCP reduces the complexity and amount of administrative work involved in
reconfiguring computers.
TCP/IP
TCP/IP in Windows Server 2016 is the following:
Networking software based on industry-standard networking protocols.
A routable enterprise networking protocol that supports the connection of your Windows-based computer
to both local area network (LAN) and wide area network (WAN) environments.
Core technologies and utilities for connecting your Windows-based computer with dissimilar systems for
the purpose of sharing information.
A foundation for gaining access to global Internet services, such as the World Wide Web and File Transfer
Protocol (FTP) servers.
A robust, scalable, cross-platform, client/server framework.
TCP/IP provides basic TCP/IP utilities that enable Windows-based computers to connect and share information
with other Microsoft and non-Microsoft systems, including:
Windows Server 2016
Windows 10
Windows Server 2012 R2
Windows 8.1
Windows Server 2012
 Windows 8
Windows Server 2008 R2
Windows 7
Windows Server 2008
Windows Vista
Internet hosts
Apple Macintosh systems
IBM mainframes
UNIX and Linux systems
Open VMS systems
Network-ready printers
Tablets and cellular telephones with wired Ethernet or wireless 802.11 technology enabled

Core Network Overview

The following illustration shows the Windows Server Core Network topology.

NOTE
This guide also includes instructions for adding optional Network Policy Server (NPS) and Web Server (IIS) servers to your
network topology to provide the foundation for secure network access solutions, such as 802.1X wired and wireless
deployments that you can implement using Core Network Companion guides. For more information, see Deploying optional
features for network access authentication and Web services.

Core Network Components

Following are the components of a core network.
Ro u t er

This deployment guide provides instructions for deploying a core network with two subnets separated by a router
that has DHCP forwarding enabled. You can, however, deploy a Layer 2 switch, a Layer 3 switch, or a hub,
depending on your requirements and resources. If you deploy a switch, the switch must be capable of DHCP
forwarding or you must place a DHCP server on each subnet. If you deploy a hub, you are deploying a single
subnet and do not need DHCP forwarding or a second scope on your DHCP server.
St a t i c T C P / I P c o n fi g u r a t i o n s

The servers in this deployment are configured with static IPv4 addresses. Client computers are configured by
default to receive IP address leases from the DHCP server.
A c t i v e D i r e c t o r y D o m a i n Se r v i c e s g l o b a l c a t a l o g a n d D N S se r v e r D C 1

Both Active Directory Domain Services (AD DS) and Domain Name System (DNS) are installed on this server,
named DC1, which provides directory and name resolution services to all computers and devices on the network.
D H C P se r v e r D H C P 1

The DHCP server, named DHCP1, is configured with a scope that provides Internet Protocol (IP) address leases to
computers on the local subnet. The DHCP server can also be configured with additional scopes to provide IP
address leases to computers on other subnets if DHCP forwarding is configured on routers.
Cl i en t c o m pu t er s

Computers running Windows client operating systems are configured by default as DHCP clients, which obtain IP
addresses and DHCP options automatically from the DHCP server.

Core Network Planning

Before you deploy a core network, you must plan the following items.
Planning subnets
Planning basic configuration of all servers
Planning the deployment of DC1
Planning domain access
Planning the deployment of DHCP1
The following sections provide more detail on each of these items.

NOTE
For assistance with planning your deployment, also see Appendix E - Core Network Planning Preparation Sheet.

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 ranges 10.0.0.1 - 10.0.0.254 and 10.0.1.1 - 10.0.1.254 are used as examples, but you can use any private IP
address range that you prefer.

IMPORTANT
After you select the IP address ranges that you want to use for each subnet, ensure that you configure your routers with an
IP address from the same IP address range as that used on the subnet where the router is installed. For example, if your
router is configured by default with an IP address of 192.168.1.1, but you are installing the router on a subnet with an IP
address range of 10.0.0.0/24, you must reconfigure the router to use an IP address from the 10.0.0.0/24 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 on the Internet. Most routers
provide NAT services, so selecting a router that is NAT-capable should be fairly simple.

For more information, see Planning the deployment of DHCP1.

Planning basic configuration of all servers
For each server in the core network, you must rename the computer and assign and configure a static IPv4
address and other TCP/IP properties for the computer.
Planning naming conventions for computers and devices
For consistency across your network, it is 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-DEN-01. This name represents the DNS server in Denver, Colorado. If additional DNS servers are
added in Denver, the numeric value in the name can be incremented, as in DNS-DEN-02 and DNS-DEN-03.
DNS-SPAS-01. This name represents the DNS server in South Pasadena, California.
DNS-ORL-01. This name represents the DNS server in Orlando, Florida.
For this guide, the server naming convention is very simple, and consists of the primary server function and a
number. For example, the domain controller is named DC1 and the DHCP server is named DHCP1.
It is recommended that you 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 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.

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES

IP address 10.0.0.2

Subnet mask 255.255.255.0

 C O N F IGURAT IO N IT EM S EXA M P L E VA L UES

Default gateway (Router IP address) 10.0.0.1

Preferred DNS server 10.0.0.2

NOTE
If you plan on deploying more than one DNS server, you can also plan the Alternate DNS Server IP address.

Planning the deployment of DC1

Following are key planning steps before installing Active Directory Domain Services (AD DS) and DNS on DC1.
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 external-facing Internet based
Web servers to provide information and services for your customers or partners, choose a domain name that is
not already in use, and then register the domain name so that your organization owns it.
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 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.
Windows Server 2012 . This forest functional level supports Windows Server 2012 domain controllers and
domain controllers that are running later versions of the Windows Server operating system.
Windows Server 2012 R2 . This forest functional level supports Windows Server 2012 R2 domain
controllers and domain controllers that are running later versions of the Windows Server operating system.
Windows Server 2016. This forest functional level supports only Windows Server 2016 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 2016, it is recommended that you configure AD DS with the Windows Server 2016 forest functional level
during AD DS installation.
 IMPORTANT
After the forest functional level is raised, domain controllers that are running earlier operating systems cannot be introduced
into the forest. For example, if you raise the forest functional level to Windows Server 2016, domain controllers running
Windows Server 2012 R2 or Windows Server 2008 cannot be added to the forest.

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

C O N F IGURAT IO N IT EM S: EXA M P L E VA L UES:

Full DNS name Examples:

- corp.contoso.com
- example.com

Forest functional level - Windows Server 2008

- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016

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

On primary, Active Directory-integrated DNS servers, a forward lookup zone is created by default during
installation of the DNS Server role. 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 is defined in the DNS standards and
reserved in the Internet DNS namespace to provide a practical and reliable way to perform reverse queries, is
configured 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:
 C O N F IGURAT IO N IT EM S EXA M P L E VA L UES

Zone type Primar y zone , and Store the zone in Active Director y is
selected

Active Directory Zone Replication Scope To all DNS ser vers in this domain

First Reverse Lookup Zone Name wizard page IPv4 Reverse Lookup Zone

Second Reverse Lookup Zone Name wizard page Network ID = 10.0.0.

Dynamic Updates Allow only secure dynamic updates

Planning domain access

To log on to 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
Individual computers that are running Windows have a local users and groups user account database that is called the
Security Accounts Manager (SAM) user accounts database. When you create a user account on the local computer in the
SAM database, you can log onto the local computer, but you cannot log on to a domain. Domain user accounts are created
with the Active Directory Users and Computers Microsoft Management Console (MMC) on a domain controller, not with
local users and groups 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 the correct 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 DHCP1.
Join the computer to the domain. Any computer that provides or accesses network resources must be
joined to the domain. For more information, see Joining Server Computers to the Domain and Logging On
and Joining Client Computers to the Domain and Logging On.
Planning the deployment of DHCP1
Following are key planning steps before installing the DHCP server role on DHCP1.
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 prefix 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 and
router/default gateway 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.

A DDRESS C L A SS B IT S F O R SUB N ET M A SK SUB N ET M A SK

Class A 11111111 00000000 00000000 255.0.0.0

00000000

Class B 11111111 11111111 00000000 255.255.0.0

00000000

Class C 11111111 11111111 11111111 255.255.255.0

00000000

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 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
When you create a scope on a DHCP server, you specify an IP address range that includes all of the IP addresses
that the DHCP server is allowed to lease to DHCP clients, such as computers and other devices. If you then go and
manually configure some servers and other devices with static IP addresses from the same IP address range that
the DHCP server is using, you can accidentally create an IP address conflict, where you and the DHCP server have
both assigned the same IP address to different devices.
To solve this problem, you can create an exclusion range for the DHCP scope. An exclusion range is a contiguous
range of IP addresses within the scope's IP address range that the DHCP server is not allowed to use. If you create
an exclusion range, the DHCP server does not assign the addresses in that range, allowing you to manually assign
these addresses without creating an IP address conflict.
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 10.0.0.1 -
10.0.0.254 and a subnet mask of 255.255.255.0.

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES

Exclusion range Start IP Address 10.0.0.1

Exclusion range End IP Address 10.0.0.25

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.
 C O N F IGURAT IO N IT EM S EXA M P L E VA L UES

Network Connect Bindings Ethernet

DNS Server Settings DC1.corp.contoso.com

Preferred DNS server IP address 10.0.0.2

Add Scope dialog box values 1. Primary Subnet

1. Scope Name 2. 10.0.0.1
2. Starting IP Address 3. 10.0.0.254
3. Ending IP Address 4. 255.255.255.0
4. Subnet Mask 5. 10.0.0.1
5. Default Gateway (optional) 6. 8 days
6. Lease duration

IPv6 DHCP Server Operation Mode Not enabled

Core Network Deployment

To deploy a core network, the basic steps are as follows:
1. Configuring All Servers
2. Deploying DC1
3. Joining Server Computers to the Domain and Logging On
4. Deploying DHCP1
5. Joining Client Computers to the Domain and Logging On
6. Deploying optional features for network access authentication and Web services

NOTE
Equivalent Windows PowerShell commands are provided for most procedures in this guide. Before running these cmdlets
in Windows PowerShell, replace example values with values that are appropriate for your network deployment. In
addition, you must enter each cmdlet on a single line in Windows PowerShell. In this guide, individual cmdlets might
appear on several lines due to formatting constraints and the display of the document by your browser or other
application.
The procedures in this guide do not include instructions for those cases in which the User Account Control dialog box
opens to request your permission to continue. If this dialog box opens while you are performing the procedures in this
guide, and if the dialog box was opened in response to your actions, click Continue .

Configuring All Servers

Before installing other technologies, such as Active Directory Domain Services or DHCP, it is important to configure
the following items.
Rename the computer
Configure a static IP address
You can use the following sections to perform these actions for each server.
Membership in Administrators , or equivalent, is the minimum required to perform these procedures.
Rename the computer
You can use the procedure in this section to change the name of a computer. Renaming the computer is useful for
circumstances in which the operating system has automatically created a computer name that you do not want to
use.

NOTE
To perform this procedure by using Windows PowerShell, open PowerShell and type the following cmdlets on separate lines,
and then press ENTER. You must also replace ComputerName with the name that you want to use.
Rename-Computer ComputerName
Restart-Computer

To re n a me c o mp u t e rs ru n n i n g W i n d o w s Se rv e r 2016, W i n d o w s Se rv e r 2012 R 2, a n d W i n d o w s Se rv e r 2012

1. In Server Manager, click Local Ser ver . The computer Proper ties are displayed in the details pane.
2. In Proper ties , in Computer name , click the existing computer name. The System Proper ties dialog box
opens. Click Change . The Computer Name/Domain Changes dialog box opens.
3. In the Computer Name/Domain Changes dialog box, in Computer name , type a new name for your
computer. For example, if you want to name the computer DC1, type DC1 .
4. Click OK twice, and then click Close . If you want to restart the computer immediately to complete the name
change, click Restar t Now . Otherwise, click Restar t Later .

NOTE
For information on how to rename computers that are running other Microsoft operating systems, see Appendix A -
Renaming computers.

Configure a static IP address

You can use the procedures in this topic to configure the Internet Protocol version 4 (IPv4) properties of a network
connection with a static IP address for computers running Windows Server 2016.

NOTE
To perform this procedure by using Windows PowerShell, open PowerShell and type the following cmdlets on separate lines,
and then press ENTER. You must also replace interface names and IP addresses in this example with the values that you want
to use to configure your computer.
New-NetIPAddress -IPAddress 10.0.0.2 -InterfaceAlias "Ethernet" -DefaultGateway 10.0.0.1 -AddressFamily
IPv4 -PrefixLength 24

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1

To c o n f i g u re a s t a t i c I P a d d re s s o n c o mp u t e rs ru n n i n g W i n d o w s Se rv e r 2016, W i n d o w s Se rv e r 2012 R 2, a n d W i n d o w s Se rv e r 2012

1. In the task bar, right-click the Network icon, and then click Open Network and Sharing Center .
2. In Network and Sharing Center , click Change adapter settings . The Network Connections folder
opens and displays the available network connections.
3. In Network Connections , right-click the connection that you want to configure, and then click Proper ties .
The network connection Proper ties dialog box opens.
4. In the network connection Proper ties dialog box, in This connection uses the following items , select
Internet Protocol Version 4 (TCP/IPv4) , and then click Proper ties . The Internet Protocol Version 4
(TCP/IPv4) Proper ties dialog box opens.
 5. In Internet Protocol Version 4 (TCP/IPv4) Proper ties , on the General tab, click Use the following IP
address . In IP address , type the IP address that you want to use.
6. Press tab to place the cursor in Subnet mask . A default value for subnet mask is entered automatically.
Either accept the default subnet mask, or type the subnet mask that you want to use.
7. In Default gateway , type the IP address of your default gateway.

NOTE
You must configure Default gateway with the same IP address that you use on the local area network (LAN)
interface of your router. For example, if you have a router that is connected to a wide area network (WAN) such as
the Internet as well as to your LAN, configure the LAN interface with the same IP address that you will then specify
as the Default gateway . In another example, if you have a router that is connected to two LANs, where LAN A uses
the address range 10.0.0.0/24 and LAN B uses the address range 192.168.0.0/24, configure the LAN A router IP
address with an address from that address range, such as 10.0.0.1. In addition, in the DHCP scope for this address
range, configure Default gateway with the IP address 10.0.0.1. For the LAN B, configure the LAN B router interface
with an address from that address range, such as 192.168.0.1, and then configure the LAN B scope 192.168.0.0/24
with a Default gateway value of 192.168.0.1.

8. In Preferred DNS ser ver , type the IP address of your DNS server. If you plan to use the local computer as
the preferred DNS server, type the IP address of the local computer.
9. In Alternate DNS Ser ver , type the IP address of your alternate DNS server, if any. If you plan to use the
local computer as an alternate DNS server, type the IP address of the local computer.
10. Click OK , and then click Close .

NOTE
For information on how to configure a static IP address on computers that are running other Microsoft operating systems,
see Appendix B - Configuring static IP addresses.

Deploying DC1
To deploy DC1, which is the computer running Active Directory Domain Services (AD DS) and DNS, you must
complete these steps in the following order:
Perform the steps in the section Configuring All Servers.
Install AD DS and DNS for a New Forest
Create a User Account in Active Directory Users and Computers
Assign Group Membership
Configure a DNS Reverse Lookup Zone
Administrative privileges
If you are installing a small network and are the only administrator for the network, it is recommended that you
create a user account for yourself, and then add your user account as a member of both Enterprise Admins and
Domain Admins. Doing so will make it easier for you to act as the administrator for all network resources. It is also
recommended that you log on with this account only when you need to perform administrative tasks, and that you
create a separate user account for performing non-IT related tasks.
If you have a larger organization with multiple administrators, refer to AD DS documentation to determine the best
group membership for organization employees.
Differences between domain user accounts and user accounts on the local computer
One of the advantages of a domain-based infrastructure is that you do not need to create user accounts on each
computer in the domain. This is true whether the computer is a client computer or a server.
Because of this, you should not create user accounts on each computer in the domain. Create all user accounts in
Active Directory Users and Computers and use the preceding procedures to assign group membership. By default,
all user accounts are members of the Domain Users group.
All members of the Domain Users group can log on to any client computer after it is joined to the domain.
You can configure user accounts to designate the days and times that the user is allowed to log on to the computer.
You can also designate which computers each user is allowed to use. To configure these settings, open Active
Directory Users and Computers, locate the user account that you want to configure, and double-click the account.
In the user account Proper ties , click the Account tab, and then click either Logon Hours or Log On To .
Install AD DS and DNS for a New Forest
You can use one of the following procedures to install Active Directory Domain Services (AD DS) and DNS and to
create a new domain in a new forest.
The first procedure provides instructions on performing these actions by using Windows PowerShell, while the
second procedure shows you how to install AD DS and DNS by using Server Manager.

IMPORTANT
After you finish performing the steps in this procedure, the computer is automatically restarted.

Install AD DS and DNS Using Windows PowerShell

You can use the following commands to install and configure AD DS and DNS. You must replace the domain name
in this example with the value that you want to use for your domain.

NOTE
For more information about these Windows PowerShell commands, see the following reference topics.
Install-WindowsFeature
Install-ADDSForest

Membership in Administrators is the minimum required to perform this procedure.

Run Windows PowerShell as an Administrator, type the following command, and then press ENTER:
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

When installation has successfully completed, the following message is displayed in Windows PowerShell.

Success Restart Needed Exit Code Feature Result

------- -------------- --------- --------------
True No Success {Active Directory Domain Services, Group P...

In Windows PowerShell, type the following command, replacing the text corp.contoso.com with your domain
name, and then press ENTER:

Install-ADDSForest -DomainName "corp.contoso.com"

 During the installation and configuration process, which is visible at the top of the Windows PowerShell
window, the following prompt appears. After it appears, type a password and then press ENTER.
SafeModeAdministratorPassword:
After you type a password and press ENTER, the following confirmation prompt appears. Type the same
password and then press ENTER.
Confirm SafeModeAdministratorPassword:
When the following prompt appears, type the letter Y and then press ENTER.

The target server will be configured as a domain controller and restarted when this operation is complete.
Do you want to continue with this operation?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):

If you want to, you can read the warning messages that are displayed during normal, successful installation
of AD DS and DNS. These messages are normal and are not an indication of install failure.
After installation succeeds, a message appears stating that you are about to be logged off of the computer
so that the computer can restart. If you click Close , you are immediately logged off the computer, and the
computer restarts. If you do not click Close , the computer restarts after a default period of time.
After the server is restarted, you can verify successful installation of Active Directory Domain Services and
DNS. Open Windows PowerShell, type the following command, and press ENTER.

Get-WindowsFeature

The results of this command are displayed in Windows PowerShell, and should be similar to the results in the
image below. For installed technologies, the brackets to the left of the technology name contain the character X ,
and the value of Install State is Installed .

Install AD DS and DNS Using Ser ver Manager

1. On DC1, in Ser ver Manager , click Manage , and then click Add Roles and Features . The Add Roles and
Features Wizard opens.
2. In Before You Begin , click Next .

NOTE
The Before You Begin page of the Add Roles and Features Wizard is not displayed if you have previously selected
Skip this page by default when the Add Roles and Features Wizard was run.
 3. In Select Installation Type , ensure that Role-Based or feature-based installation is selected, and then
click Next .
4. In Select destination ser ver , ensure that Select a ser ver from the ser ver pool is selected. In Ser ver
Pool , ensure that the local computer is selected. Click Next .
5. In Select ser ver roles , in Roles , click Active Director y Domain Ser vices . In Add features that are
required for Active Director y Domain Ser vices , click Add Features . Click Next .
6. In Select features , click Next , and in Active Director y Domain Ser vices , review the information that is
provided, and then click Next .
7. In Confirm installation selections , click Install . The Installation progress page displays status during the
installation process. When the process completes, in the message details, click Promote this ser ver to a
domain controller . The Active Directory Domain Services Configuration Wizard opens.
8. In Deployment Configuration , select Add a new forest . In Root domain name , type the fully qualified
domain name (FQDN) for your domain. For example, if your FQDN is corp.contoso.com, type
corp.contoso.com . Click Next .
9. In Domain Controller Options , in Select functional level of the new forest and root domain ,
select the forest functional level and domain functional level that you want to use. In Specify domain
controller capabilities , ensure that Domain Name System (DNS) ser ver and Global Catalog (GC)
are selected. In Password and Confirm password , type the Directory Services Restore Mode (DSRM)
password that you want to use. Click Next .
10. In DNS Options , click Next .
11. In Additional Options , verify the NetBIOS name that is assigned to the domain, and change it only if
necessary. Click Next .
12. In Paths , in Specify the location of the AD DS database, log files, and SYSVOL , do one of the
following:
Accept the default values.
Type folder locations that you want to use for Database folder , Log files folder , and SYSVOL
folder .
13. Click Next .
14. In Review Options , review your selections.
15. If you want to export settings to a Windows PowerShell script, click View script . The script opens in
Notepad, and you can save it to the folder location that you want. Click Next . In Prerequisites Check , your
selections are validated. When the check completes, click Install . When prompted by Windows, click Close .
The server restarts to complete installation of AD DS and DNS.
16. To verify successful installation, view the Server Manager console after the server restarts. Both AD DS and
DNS should appear in the left pane, like the highlighted items in the image below.
C r e a t e a U se r A c c o u n t i n A c t i v e D i r e c t o r y U se r s a n d C o m p u t e r s

You can use this procedure to create a new domain user account in Active Directory Users and Computers
Microsoft Management Console (MMC).
Membership in Domain Admins , or equivalent, is the minimum required to perform this procedure.

NOTE
To perform this procedure by using Windows PowerShell, open PowerShell and type the following cmdlet on one line, and
then press ENTER. You must also replace the user account name in this example with the value that you want to use.
New-ADUser -SamAccountName User1 -AccountPassword (read-host "Set user password" -assecurestring) -name
"User1" -enabled $true -PasswordNeverExpires $true -ChangePasswordAtLogon $false

After you press ENTER, type the password for the user account. The account is created and, by default, is granted
membership to the Domain Users group.
With the following cmdlet, you can assign additional group memberships for the new user account. The example below adds
User1 to the Domain Admins and Enterprise Admins groups. Ensure before running this command that you change the user
account name, domain name, and groups to match your requirements.
Add-ADPrincipalGroupMembership -Identity "CN=User1,CN=Users,DC=corp,DC=contoso,DC=com" -MemberOf
"CN=Enterprise Admins,CN=Users,DC=corp,DC=contoso,DC=com","CN=Domain
Admins,CN=Users,DC=corp,DC=contoso,DC=com"

To c re a t e a u s e r a c c o u n t

1. On DC1, in Server Manager, click Tools , and then click Active Director y Users and Computers . The
Active Directory Users and Computers MMC opens. If it is not already selected, click the node for your
domain. For example, if your domain is corp.contoso.com, click corp.contoso.com .
2. In the details pane, right-click the folder in which you want to add a user account.
Where?
Active Directory Users and Computers/domain node/folder
3. Point to New , and then click User . The New Object - User dialog box opens.
4. In First name , type the user's first name.
5. In Initials , type the user's initials.
6. In Last name , type the user's last name.
7. Modify Full name to add initials or reverse the order of first and last names.
8. In User logon name , type the user logon name. Click Next .
9. In New Object - User , in Password and Confirm password , type the user's password, and then select
the appropriate password options.
10. Click Next , review the new user account settings, and then click Finish .
A ssi g n G r o u p M e m b e r sh i p

You can use this procedure to add a user, computer, or group to a group in Active Directory Users and Computers
Microsoft Management Console (MMC).
Membership in Domain Admins , or equivalent is the minimum required to perform this procedure.
To a s s i g n g ro u p me mb e rs h i p

1. On DC1, in Server Manager, click Tools , and then click Active Director y Users and Computers . The
Active Directory Users and Computers MMC opens. If it is not already selected, click the node for your
domain. For example, if your domain is corp.contoso.com, click corp.contoso.com .
2. In the details pane, double-click the folder that contains the group to which you want to add a member.
Where?
Active Director y Users and Computers /domain node/folder that contains the group
3. In the details pane, right-click the object that you want to add to a group, such as a user or computer, and
then click Proper ties . The object's Proper ties dialog box opens. Click the Member of tab.
4. On the Member of tab, click Add .
5. In Enter the object names to select , type the name of the group to which you want to add the object,
and then click OK .
6. To assign group membership to other users, groups or computers, repeat steps 4 and 5 of this procedure.
C o n fi g u r e a D N S R e v e r se L o o k u p Z o n e

You can use this procedure to configure a reverse lookup zone in Domain Name System (DNS).
Membership in Domain Admins is the minimum required to perform this procedure.

NOTE
For medium and large organizations, it's recommended that you configure and use the DNSAdmins group in Active
Directory Users and Computers. For more information, see Additional Technical Resources
To perform this procedure by using Windows PowerShell, open PowerShell and type the following cmdlet on one line, and
then press ENTER. You must also replace the DNS reverse lookup zone and zonefile names in this example with the values
that you want to use. Ensure that you reverse the network ID for the reverse zone name. For example, if the network ID
is 192.168.0, create the reverse lookup zone name 0.168.192.in-addr.arpa .
Add-DnsServerPrimaryZone 0.0.10.in-addr.arpa -ZoneFile 0.0.10.in-addr.arpa.dns

To c o n f i g u re a DN S re v e rs e l o o k u p z o n e

1. On DC1, in Server Manager, click Tools , and then click DNS . The DNS MMC opens.
2. In DNS, if it is not already expanded, double-click the server name to expand the tree. For example, if the
DNS server name is DC1, double-click DC1 .
3. Select Reverse Lookup Zones , right-click Reverse Lookup Zones , and then click New Zone . The New
Zone Wizard opens.
4. In Welcome to the New Zone Wizard , click Next .
5. In Zone Type , select Primar y zone .
6. If your DNS server is a writeable domain controller, ensure that Store the zone in Active Director y is
selected. Click Next .
7. In Active Director y Zone Replication Scope , select To all DNS ser vers running on domain
 controllers in this domain , unless you have a specific reason to choose a different option. Click Next .
8. In the first Reverse Lookup Zone Name page, select IPv4 Reverse Lookup Zone . Click Next .
9. In the second Reverse Lookup Zone Name page, do one of the following:
In Network ID , type the network ID of your IP address range. For example, if your IP address range
is 10.0.0.1 through 10.0.0.254, type 10.0.0 .
In Reverse lookup zone name , your IPv4 reverse lookup zone name is automatically added. Click
Next .
10. In Dynamic Update , select the type of dynamic updates that you want to allow. Click Next .
11. In Completing the New Zone Wizard , review your choices, and then click Finish .
Joining Server Computers to the Domain and Logging On
After you have installed Active Directory Domain Services (AD DS) and created one or more user accounts that
have permissions to join a computer to the domain, you can join core network servers to the domain and log on to
the servers in order to install additional technologies, such as Dynamic Host Configuration Protocol (DHCP).
On all servers that you are deploying, except for the server running AD DS, do the following:
1. Complete the procedures provided in Configuring All Servers.
2. Use the instructions in the following two procedures to join your servers to the domain and to log on to the
servers to perform additional deployment tasks:

NOTE
To perform this procedure by using Windows PowerShell, open PowerShell and type the following cmdlet, and then press
ENTER. You must also replace the domain name with the name that you want to use.
Add-Computer -DomainName corp.contoso.com

When you are prompted to do so, type the user name and password for an account that has permission to join a computer
to the domain. To restart the computer, type the following command and press ENTER.
Restart-Computer

To j o i n c o mp u t e rs ru n n i n g W i n d o w s Se rv e r 2016, W i n d o w s Se rv e r 2012 R 2 , a n d W i n d o w s Se rv e r 2012 t o t h e d o ma i n

1. In Server Manager, click Local Ser ver . In the details pane, click WORKGROUP . The System Proper ties
dialog box opens.
2. In the System Proper ties dialog box, click Change . The Computer Name/Domain Changes dialog box
opens.
3. In Computer Name , in Member of , click Domain , and then type the name of the domain that you want
to join. For example, if the domain name is corp.contoso.com, type corp.contoso.com .
4. Click OK . The Windows Security dialog box opens.
5. In Computer Name/Domain Changes , in User name , type the user name, and in Password , type the
password, and then click OK . The Computer Name/Domain Changes dialog box opens, welcoming you
to the domain. Click OK .
6. The Computer Name/Domain Changes dialog box displays a message indicating that you must restart
the computer to apply the changes. Click OK .
7. On the System Proper ties dialog box, on the Computer Name tab, click Close . The Microsoft
Windows dialog box opens, and displays a message, again indicating that you must restart the computer to
 apply the changes. Click Restar t Now .

NOTE
For information on how to join computers that are running other Microsoft operating systems to the domain, see Appendix
C - Joining computers to the domain.

To l o g o n t o t h e d o ma i n u s i n g c o mp u t e rs ru n n i n g W i n d o w s Se rv e r 2016

1. Log off the computer, or restart the computer.

2. Press CTRL + ALT + DELETE. The logon screen appears.
3. In the lower left corner, click Other User .
4. In User name , type your user name.
5. In Password , type your domain password, and then click the arrow, or press ENTER.

NOTE
For information on how to log on to the domain using computers that are running other Microsoft operating systems, see
Appendix D - Log on to the domain.

Deploying DHCP1
Before deploying this component of the core network, you must do the following:
Perform the steps in the section Configuring All Servers.
Perform the steps in the section Joining Server Computers to the Domain and Logging On.
To deploy DHCP1, which is the computer running the Dynamic Host Configuration Protocol (DHCP) server role,
you must complete these steps in the following order:
Install Dynamic Host Configuration Protocol (DHCP)
Create and Activate a New DHCP Scope
 NOTE
To perform these procedures by using Windows PowerShell, open PowerShell and type the following cmdlets on separate
lines, and then press ENTER. You must also replace the scope name, IP address start and end ranges, subnet mask, and other
values in this example with the values that you want to use.
Install-WindowsFeature DHCP -IncludeManagementTools

Add-DhcpServerv4Scope -name "Corpnet" -StartRange 10.0.0.1 -EndRange 10.0.0.254 -SubnetMask 255.255.255.0 -

State Active

Add-DhcpServerv4ExclusionRange -ScopeID 10.0.0.0 -StartRange 10.0.0.1 -EndRange 10.0.0.15

Set-DhcpServerv4OptionValue -OptionID 3 -Value 10.0.0.1 -ScopeID 10.0.0.0 -ComputerName

DHCP1.corp.contoso.com

Add-DhcpServerv4Scope -name "Corpnet2" -StartRange 10.0.1.1 -EndRange 10.0.1.254 -SubnetMask 255.255.255.0

-State Active

Add-DhcpServerv4ExclusionRange -ScopeID 10.0.1.0 -StartRange 10.0.1.1 -EndRange 10.0.1.15

Set-DhcpServerv4OptionValue -OptionID 3 -Value 10.0.1.1 -ScopeID 10.0.1.0 -ComputerName

DHCP1.corp.contoso.com

Set-DhcpServerv4OptionValue -DnsDomain corp.contoso.com -DnsServer 10.0.0.2

Add-DhcpServerInDC -DnsName DHCP1.corp.contoso.com

I n st a l l D y n a m i c H o st C o n fi g u r a t i o n P r o t o c o l (D H C P )

You can use this procedure to install and configure the DHCP Server role using the Add Roles and Features Wizard.
Membership in Domain Admins , or equivalent, is the minimum required to perform this procedure.
To i n s t a l l DHC P

1. On DHCP1, in Server Manager, click Manage , and then click Add Roles and Features . The Add Roles and
Features Wizard opens.
2. In Before You Begin , click Next .

NOTE
The Before You Begin page of the Add Roles and Features Wizard is not displayed if you have previously selected
Skip this page by default when the Add Roles and Features Wizard was run.

3. In Select Installation Type , ensure that Role-Based or feature-based installation is selected, and then
click Next .
4. In Select destination ser ver , ensure that Select a ser ver from the ser ver pool is selected. In Ser ver
Pool , ensure that the local computer is selected. Click Next .
5. In Select Ser ver Roles , in Roles , select DHCP Ser ver . In Add features that are required for DHCP
Ser ver , click Add Features . Click Next .
6. In Select features , click Next , and in DHCP Ser ver , review the information that is provided, and then click
Next .
7. In Confirm installation selections , click Restar t the destination ser ver automatically if required .
When you are prompted to confirm this selection, click Yes , and then click Install . The Installation
progress page displays status during the installation process. When the process completes, the message
"Configuration required. Installation succeeded on ComputerName" is displayed, where ComputerName is
the name of the computer upon which you installed DHCP Server. In the message window, click Complete
DHCP configuration . The DHCP Post-Install configuration wizard opens. Click Next .
 8. In Authorization , specify the credentials that you want to use to authorize the DHCP server in Active
Directory Domain Services, and then click Commit . After authorization is complete, click Close .
C r e a t e a n d A c t i v a t e a N e w D H C P Sc o p e

You can use this procedure to create a new DHCP scope using the DHCP Microsoft Management Console (MMC).
When you complete the procedure, the scope is activated and the exclusion range that you create prevents the
DHCP server from leasing the IP addresses that you use to statically configure your servers and other devices that
require a static IP address.
Membership in DHCP Administrators , or equivalent, is the minimum required to perform this procedure.
To c re a t e a n d a c t i v a t e a n e w DHC P Sc o p e

1. On DHCP1, in Server Manager, click Tools , and then click DHCP . The DHCP MMC opens.
2. In DHCP , expand the server name. For example, if the DHCP server name is DHCP1.corp.contoso.com, click
the down arrow next to DHCP1.corp.contoso.com .
3. Beneath the server name, right-click IPv4 , and then click New Scope . The New Scope Wizard opens.
4. In Welcome to the New Scope Wizard , click Next .
5. In Scope Name , in Name , type a name for the scope. For example, type Subnet 1 .
6. In Description , type a description for the new scope, and then click Next .
7. In IP Address Range , do the following:
a. In Star t IP address , type the IP address that is the first IP address in the range. For example, type
10.0.0.1 .
b. In End IP address , type the IP address that is the last IP address in the range. For example, type
10.0.0.254 . Values for Length and Subnet mask are entered automatically, based on the IP
address you entered for Star t IP address .
c. If necessary, modify the values in Length or Subnet mask , as appropriate for your addressing
scheme.
d. Click Next .
8. In Add Exclusions , do the following:
a. In Star t IP address , type the IP address that is the first IP address in the exclusion range. For
example, type 10.0.0.1 .
b. In End IP address , type the IP address that is the last IP address in the exclusion range, For example,
type 10.0.0.15 .
9. Click Add , and then click Next .
10. In Lease Duration , modify the default values for Days , Hours , and Minutes , as appropriate for your
network, and then click Next .
11. In Configure DHCP Options , select Yes, I want to configure these options now , and then click Next .
12. In Router (Default Gateway) , do one of the following:
If you do not have routers on your network, click Next .
In IP address , type the IP address of your router or default gateway. For example, type 10.0.0.1 .
Click Add , and then click Next .
13. In Domain Name and DNS Ser vers , do the following:
 a. In Parent domain , type the name of the DNS domain that clients use for name resolution. For
example, type corp.contoso.com .
b. In Ser ver name , type the name of the DNS computer that clients use for name resolution. For
example, type DC1 .
c. Click Resolve . The IP address of the DNS server is added in IP address . Click Add , wait for DNS
server IP address validation to complete, and then click Next .
14. In WINS Ser vers , because you do not have WINS servers on your network, click Next .
15. In Activate Scope , select Yes, I want to activate this scope now .
16. Click Next , and then click Finish .

IMPORTANT
To create new scopes for additional subnets, repeat this procedure. Use a different IP address range for each subnet that you
plan to deploy, and ensure that DHCP message forwarding is enabled on all routers that lead to other subnets.

Joining Client Computers to the Domain and Logging On

NOTE
To perform this procedure by using Windows PowerShell, open PowerShell and type the following cmdlet, and then press
ENTER. You must also replace the domain name with the name that you want to use.
Add-Computer -DomainName corp.contoso.com

When you are prompted to do so, type the user name and password for an account that has permission to join a computer
to the domain. To restart the computer, type the following command and press ENTER.
Restart-Computer

To j o i n c o m p u t e r s r u n n i n g W i n d o w s 1 0 t o t h e d o m a i n

1. Log on to the computer with the local Administrator account.

2. In Search the web and Windows , type System . In search results, click System (Control panel) . The
System dialog box opens.
3. In System , click Advanced system settings . The System Proper ties dialog box opens. Click the
Computer Name tab.
4. In Computer Name , click Change . The Computer Name/Domain Changes dialog box opens.
5. In Computer Name/Domain Changes , In Member of , click Domain , and then type the name of the
domain you want to join. For example, if the domain name is corp.contoso.com, type corp.contoso.com .
6. Click OK . The Windows Security dialog box opens.
7. In Computer Name/Domain Changes , in User name , type the user name, and in Password , type the
password, and then click OK . The Computer Name/Domain Changes dialog box opens, welcoming you
to the domain. Click OK .
8. The Computer Name/Domain Changes dialog box displays a message indicating that you must restart
the computer to apply the changes. Click OK .
9. On the System Proper ties dialog box, on the Computer Name tab, click Close . The Microsoft
Windows dialog box opens, and displays a message, again indicating that you must restart the computer to
apply the changes. Click Restar t Now .
To j o i n c o m p u t e r s r u n n i n g W i n d o w s 8 .1 t o t h e d o m a i n

1. Log on to the computer with the local Administrator account.

2. Right-click Star t , and then click System . The System dialog box opens.
3. In System , click Advanced system settings . The System Proper ties dialog box opens. Click the
Computer Name tab.
4. In Computer Name , click Change . The Computer Name/Domain Changes dialog box opens.
5. In Computer Name/Domain Changes , In Member of , click Domain , and then type the name of the
domain you want to join. For example, if the domain name is corp.contoso.com, type corp.contoso.com .
6. Click OK . The Windows Security dialog box opens.
7. In Computer Name/Domain Changes , in User name , type the user name, and in Password , type the
password, and then click OK . The Computer Name/Domain Changes dialog box opens, welcoming you
to the domain. Click OK .
8. The Computer Name/Domain Changes dialog box displays a message indicating that you must restart
the computer to apply the changes. Click OK .
9. On the System Proper ties dialog box, on the Computer Name tab, click Close . The Microsoft
Windows dialog box opens, and displays a message, again indicating that you must restart the computer to
apply the changes. Click Restar t Now .
To l o g o n t o t h e d o m a i n u si n g c o m p u t e r s r u n n i n g W i n d o w s 1 0

1. Log off the computer, or restart the computer.

2. Press CTRL + ALT + DELETE. The logon screen appears.
3. In the lower left, click Other User .
4. In User name , type your domain and user name in the format domain\user. For example, to log on to the
domain corp.contoso.com with an account named User-01 , type CORP\User-01 .
5. In Password , type your domain password, and then click the arrow, or press ENTER.
Deploying optional features for network access authentication and Web services
If you intend to deploy network access servers, such as wireless access points or VPN servers, after installing your
core network, it is recommended that you deploy both an NPS and a Web server. For network access deployments,
the use of secure certificate-based authentication methods is recommended. You can use NPS to manage network
access policies and to deploy secure authentication methods. You can use a Web server to publish the certificate
revocation list (CRL) of your certification authority (CA) that provides certificates for secure authentication.

NOTE
You can deploy server certificates and other additional features by using Core Network Companion Guides. For more
information, see Additional Technical Resources.

The following illustration shows the Windows Server Core Network topology with added NPS and Web servers.
The following sections provide information on adding NPS and Web servers to your network.
Deploying NPS1
Deploying WEB1
Deploying NPS1
The Network Policy Server (NPS) server is installed as a preparatory step for deploying other network access
technologies, such as virtual private network (VPN) servers, wireless access points, and 802.1X authenticating
switches.
Network Policy Server (NPS) allows you to centrally configure and manage network policies with the following
features: Remote Authentication Dial-In User Service (RADIUS) server and RADIUS proxy.
NPS is an optional component of a core network, but you should install NPS if any of the following are true:
You are planning to expand your network to include remote access servers that are compatible with the
RADIUS protocol, such as a computer running Windows Server 2016, Windows Server 2012 R2, Windows
Server 2012, Windows Server 2008 R2 or Windows Server 2008 and Routing and Remote Access service,
Terminal Services Gateway, or Remote Desktop Gateway.
You plan to deploy 802.1X authentication for wired or wireless access.
Before deploying this role service, you must perform the following steps on the computer you are configuring as
an NPS.
Perform the steps in the section Configuring All Servers.
Perform the steps in the section Joining Server Computers to the Domain and Logging On
To deploy NPS1, which is the computer running the Network Policy Server (NPS) role service of the Network Policy
and Access Services server role, you must complete this step:
Planning the deployment of NPS1
Install Network Policy Server (NPS)
 Register the NPS in the Default Domain

NOTE
This guide provides instructions for deploying NPS on a standalone server or VM named NPS1. Another recommended
deployment model is the installation of NPS on a domain controller. If you prefer installing NPS on a domain controller
instead of on a standalone server, install NPS on DC1.

P l a n n i n g t h e d e p l o y m e n t o f N P S1

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 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.
I n st a l l N e t w o r k P o l i c y Se r v e r (N P S)

You can use this procedure to install Network Policy Server (NPS) by using the Add Roles and Features Wizard.
NPS is a role service of the Network Policy and Access Services server role.

NOTE
By default, NPS listens for RADIUS traffic on ports 1812, 1813, 1645, and 1646 on all installed network adapters. If Windows
Firewall with Advanced Security is enabled when you install NPS, firewall exceptions for these ports are automatically created
during the installation process for both Internet Protocol version 6 (IPv6) and IPv4 traffic. If your network access servers are
configured to send RADIUS traffic over ports other than these defaults, remove the exceptions created in Windows Firewall
with Advanced Security during NPS installation, and create exceptions for the ports that you do use for RADIUS traffic.

Administrative Credentials
To complete this procedure, you must be a member of the Domain Admins group.

NOTE
To perform this procedure by using Windows PowerShell, open PowerShell and type the following, and then press ENTER.
Install-WindowsFeature NPAS -IncludeManagementTools

To i n s t a l l N P S

1. On NPS1, in Server Manager, click Manage , and then click Add Roles and Features . The Add Roles and
Features Wizard opens.
2. In Before You Begin , click Next .
 NOTE
The Before You Begin page of the Add Roles and Features Wizard is not displayed if you have previously selected
Skip this page by default when the Add Roles and Features Wizard was run.

3. In Select Installation Type , ensure that Role-Based or feature-based installation is selected, and then
click Next .
4. In Select destination ser ver , ensure that Select a ser ver from the ser ver pool is selected. In Ser ver
Pool , ensure that the local computer is selected. Click Next .
5. In Select Ser ver Roles , in Roles , select Network Policy and Access Ser vices . A dialog box opens
asking if it should add features that are required for Network Policy and Access Services. Click Add
Features , and then click Next .
6. In Select features , click Next , and in Network Policy and Access Ser vices , review the information that
is provided, and then click Next .
7. In Select role ser vices , click Network Policy Ser ver . In Add features that are required for
Network Policy Ser ver , click Add Features . Click Next .
8. In Confirm installation selections , click Restar t the destination ser ver automatically if required .
When you are prompted to confirm this selection, click Yes , and then click Install . The Installation progress
page displays status during the installation process. When the process completes, the message "Installation
succeeded on ComputerName" is displayed, where ComputerName is the name of the computer upon
which you installed Network Policy Server. Click Close .
R e g i st e r t h e N P S i n t h e D e fa u l t D o m a i n

You can use this procedure to register an NPS in the domain where the server is a domain member.
NPSs must be registered in Active Directory so that they have permission to read the dial-in properties of user
accounts during the authorization process. Registering an NPS adds the server to the RAS and IAS Ser vers
group in Active Directory.
Administrative credentials
To complete this procedure, you must be a member of the Domain Admins group.

NOTE
To perform this procedure by using network shell (Netsh) commands within Windows PowerShell, open PowerShell and type
the following, and then press ENTER.
netsh nps add registeredserver domain=corp.contoso.com server=NPS1.corp.contoso.com

To re g i s t e r a n N P S i n i t s d e f a u l t d o ma i n

1. On NPS1, in Server Manager, click Tools, and then click Network Policy Ser ver . The Network Policy Server
MMC opens.
2. Right-click NPS (Local) , and then click Register ser ver in Active Director y . The Network Policy
Ser ver dialog box opens.
3. In Network Policy Ser ver , click OK , and then click OK again.
For more information about Network Policy Server, see Network Policy Server (NPS).
Deploying WEB1
The Web Server (IIS) role in Windows Server 2016 provides a secure, easy-to-manage, modular and extensible
platform for reliably hosting web sites, services, and applications. With Internet Information Services (IIS), you can
share information with users on the Internet, an intranet, or an extranet. IIS is a unified web platform that
integrates IIS, ASP.NET, FTP services, PHP, and Windows Communication Foundation (WCF).
In addition to allowing you to publish a CRL for access by domain member computers, the Web Server (IIS) server
role allows you to set up and manage multiple web sites, web applications, and FTP sites. IIS also provides the
following benefits:
Maximize web security through a reduced server foot print and automatic application isolation.
Easily deploy and run ASP.NET, classic ASP, and PHP web applications on the same server.
Achieve application isolation by giving worker processes a unique identity and sandboxed configuration by
default, further reducing security risks.
Easily add, remove, and even replace built-in IIS components with custom modules, suited for customer
needs.
Speed up your website through built-in dynamic caching and enhanced compression.
To deploy WEB1, which is the computer that is running the Web Server (IIS) server role, you must do the following:
Perform the steps in the section Configuring All Servers.
Perform the steps in the section Joining Server Computers to the Domain and Logging On
Install the Web Server (IIS) server role
I n st a l l t h e W e b Se r v e r (I I S) se r v e r r o l e

To complete this procedure, you must be a member of the Administrators group.

NOTE
To perform this procedure by using Windows PowerShell, open PowerShell and type the following, and then press ENTER.
Install-WindowsFeature Web-Server -IncludeManagementTools

1. In Ser ver Manager , click Manage , and then click Add Roles and Features . The Add Roles and Features
Wizard opens.
2. In Before You Begin , click Next .

NOTE
The Before You Begin page of the Add Roles and Features Wizard is not displayed if you have previously selected
Skip this page by default when the Add Roles and Features Wizard was run.

3. On the Select Installation Type page, click Next .

4. On the Select destination ser ver page, ensure that the local computer is selected, and then click Next .
5. On the Select ser ver roles page, scroll to and select Web Ser ver (IIS) . The Add features that are
required for Web Ser ver (IIS) dialog box opens. Click Add Features , and then click Next .
6. Click Next until you have accepted all of the default web server settings, and then click Install .
7. Verify that all installations were successful, and then click Close .

Additional Technical Resources

For more information about the technologies in this guide, see the following resources:
Windows Server 2016, Windows Server 2012 R2 , and Windows Server 2012 Technical Library Resources
What's new in Active Directory Domain Services (AD DS) in Windows Server 2016
Active Directory Domain Services overview at https://technet.microsoft.com/library/hh831484.aspx.
Domain Name System (DNS) overview at https://technet.microsoft.com/library/hh831667.aspx.
Implementing the DNS Admins Role
Dynamic Host Configuration Protocol (DHCP) overview at
https://technet.microsoft.com/library/hh831825.aspx.
Network Policy and Access Services overview at https://technet.microsoft.com/library/hh831683.aspx.
Web Server (IIS) overview at https://technet.microsoft.com/library/hh831725.aspx.

Appendices A through E
The following sections contain additional configuration information for computers that are running operating
systems other than Windows Server 2016, Windows 10, Windows Server 2012 , and Windows 8. In addition, a
network preparation worksheet is provided to assist you with your deployment.
1. Appendix A - Renaming computers
2. Appendix B - Configuring static IP addresses
3. Appendix C - Joining computers to the domain
4. Appendix D - Log on to the domain
5. Appendix E - Core Network Planning Preparation Sheet

Appendix A - Renaming computers

You can use the procedures in this section to provide computers running Windows Server 2008 R2, Windows 7,
Windows Server 2008 , and Windows Vista with a different computer name.
Windows Server 2008 R2 and Windows 7
Windows Server 2008 and Windows Vista
Windows Server 2008 R2 and Windows 7
Membership in Administrators , or equivalent, is the minimum required to perform these procedures.
To r e n a m e c o m p u t e r s r u n n i n g W i n d o w s Se r v e r 2 0 0 8 R 2 a n d W i n d o w s 7

1. Click Star t , right-click Computer , and then click Proper ties . The System dialog box opens.
2. In Computer name, domain, and workgroup settings , click Change settings . The System
Proper ties dialog box opens.

NOTE
On computers running Windows 7, before the System Proper ties dialog box opens, the User Account Control
dialog box opens, requesting permission to continue. Click Continue to proceed.

3. Click Change . The Computer Name/Domain Changes dialog box opens.

4. In Computer Name , type the name for your computer. For example, if you want to name the computer
 DC1, type DC1 .
5. Click OK twice, click Close , and then click Restar t Now to restart the computer.
Windows Server 2008 and Windows Vista
Membership in Administrators , or equivalent, is the minimum required to perform these procedures.
To r e n a m e c o m p u t e r s r u n n i n g W i n d o w s Se r v e r 2 0 0 8 a n d W i n d o w s Vi st a

1. Click Star t , right-click Computer , and then click Proper ties . The System dialog box opens.
2. In Computer name, domain, and workgroup settings , click Change settings . The System
Proper ties dialog box opens.

NOTE
On computers running Windows Vista, before the System Proper ties dialog box opens, the User Account
Control dialog box opens, requesting permission to continue. Click Continue to proceed.

3. Click Change . The Computer Name/Domain Changes dialog box opens.

4. In Computer Name , type the name for your computer. For example, if you want to name the computer
DC1, type DC1 .
5. Click OK twice, click Close , and then click Restar t Now to restart the computer.

Appendix B - Configuring static IP addresses

This topic provides procedures for configuring static IP addresses on computers running the following operating
systems:
Windows Server 2008 R2
Windows Server 2008
Windows Server 2008 R2
Membership in Administrators , or equivalent, is the minimum required to perform this procedure.
To c o n fi g u r e a st a t i c I P a d d r e ss o n a c o m p u t e r r u n n i n g W i n d o w s Se r v e r 2 0 0 8 R 2

1. Click Star t , and then click Control Panel .

2. In Control Panel , click Network and Internet . Network and Internet opens.
In Network and Internet , click Network and Sharing Center . Network and Sharing Center opens.
3. In Network and Sharing Center , click Change adapter settings . Network Connections opens.
4. In Network Connections , right-click the network connection that you want to configure, and then click
Proper ties .
5. In Local Area Connection Proper ties , in This connection uses the following items , select Internet
Protocol Version 4 (TCP/IPv4) , and then click Proper ties . The Internet Protocol Version 4
(TCP/IPv4) Proper ties dialog box opens.
6. In Internet Protocol Version 4 (TCP/IPv4) Proper ties , on the General tab, click Use the following IP
address . In IP address , type the IP address that you want to use.
7. Press tab to place the cursor in Subnet mask . A default value for subnet mask is entered automatically.
Either accept the default subnet mask, or type the subnet mask that you want to use.
8. In Default gateway , type the IP address of your default gateway.
 9. In Preferred DNS ser ver , type the IP address of your DNS server. If you plan to use the local computer as
the preferred DNS server, type the IP address of the local computer.
10. In Alternate DNS Ser ver , type the IP address of your alternate DNS server, if any. If you plan to use the
local computer as an alternate DNS server, type the IP address of the local computer.
11. Click OK , and then click Close .
Windows Server 2008
Membership in Administrators , or equivalent, is the minimum required to perform these procedures.
To c o n fi g u r e a st a t i c I P a d d r e ss o n a c o m p u t e r r u n n i n g W i n d o w s Se r v e r 2 0 0 8

1. Click Star t , and then click Control Panel .

2. In Control Panel , verify that Classic View is selected, and then double-click Network and Sharing
Center .
3. In Network and Sharing Center , in Tasks , click Manage Network Connections .
4. In Network Connections , right-click the network connection that you want to configure, and then click
Proper ties .
5. In Local Area Connection Proper ties , in This connection uses the following items , select Internet
Protocol Version 4 (TCP/IPv4) , and then click Proper ties . The Internet Protocol Version 4
(TCP/IPv4) Proper ties dialog box opens.
6. In Internet Protocol Version 4 (TCP/IPv4) Proper ties , on the General tab, click Use the following IP
address . In IP address , type the IP address that you want to use.
7. Press tab to place the cursor in Subnet mask . A default value for subnet mask is entered automatically.
Either accept the default subnet mask, or type the subnet mask that you want to use.
8. In Default gateway , type the IP address of your default gateway.
9. In Preferred DNS ser ver , type the IP address of your DNS server. If you plan to use the local computer as
the preferred DNS server, type the IP address of the local computer.
10. In Alternate DNS Ser ver , type the IP address of your alternate DNS server, if any. If you plan to use the
local computer as an alternate DNS server, type the IP address of the local computer.
11. Click OK , and then click Close .

Appendix C - Joining computers to the domain

You can use these procedures to join computers running Windows Server 2008 R2, Windows 7, Windows Server
2008 , and Windows Vista to the domain.
Windows Server 2008 R2 and Windows 7
Windows Server 2008 and Windows Vista

IMPORTANT
To join a computer to a domain, you must be logged on to the computer with the local Administrator account or, if you are
logged on to the computer with a user account that does not have local computer administrative credentials, you must
provide the credentials for the local Administrator account during the process of joining the computer to the domain. In
addition, you must have a user account in the domain to which you want to join the computer. During the process of joining
the computer to the domain, you will be prompted for your domain account credentials (user name and password).
Windows Server 2008 R2 and Windows 7
Membership in Domain Users , or equivalent, is the minimum required to perform this procedure.
To j o i n c o m p u t e r s r u n n i n g W i n d o w s Se r v e r 2 0 0 8 R 2 a n d W i n d o w s 7 t o t h e d o m a i n

1. Log on to the computer with the local Administrator account.

2. Click Star t , right-click Computer , and then click Proper ties . The System dialog box opens.
3. In Computer name, domain, and workgroup settings , click Change settings . The System
Proper ties dialog box opens.

NOTE
On computers running Windows 7, before the System Proper ties dialog box opens, the User Account Control
dialog box opens, requesting permission to continue. Click Continue to proceed.

4. Click Change . The Computer Name/Domain Changes dialog box opens.

5. In Computer Name , in Member of , select Domain , and then type the name of the domain you want to
join. For example, if the domain name is corp.contoso.com, type corp.contoso.com .
6. Click OK . The Windows Security dialog box opens.
7. In Computer Name/Domain Changes , in User name , type the user name, and in Password , type the
password, and then click OK . The Computer Name/Domain Changes dialog box opens, welcoming you
to the domain. Click OK .
8. The Computer Name/Domain Changes dialog box displays a message indicating that you must restart
the computer to apply the changes. Click OK .
9. On the System Proper ties dialog box, on the Computer Name tab, click Close . The Microsoft
Windows dialog box opens, and displays a message, again indicating that you must restart the computer to
apply the changes. Click Restar t Now .
Windows Server 2008 and Windows Vista
Membership in Domain Users , or equivalent, is the minimum required to perform this procedure.
To j o i n c o m p u t e r s r u n n i n g W i n d o w s Se r v e r 2 0 0 8 a n d W i n d o w s Vi st a t o t h e d o m a i n

1. Log on to the computer with the local Administrator account.

2. Click Star t , right-click Computer , and then click Proper ties . The System dialog box opens.
3. In Computer name, domain, and workgroup settings , click Change settings . The System
Proper ties dialog box opens.
4. Click Change . The Computer Name/Domain Changes dialog box opens.
5. In Computer Name , in Member of , select Domain , and then type the name of the domain you want to
join. For example, if the domain name is corp.contoso.com, type corp.contoso.com .
6. Click OK . The Windows Security dialog box opens.
7. In Computer Name/Domain Changes , in User name , type the user name, and in Password , type the
password, and then click OK . The Computer Name/Domain Changes dialog box opens, welcoming you
to the domain. Click OK .
8. The Computer Name/Domain Changes dialog box displays a message indicating that you must restart
the computer to apply the changes. Click OK .
9. On the System Proper ties dialog box, on the Computer Name tab, click Close . The Microsoft
 Windows dialog box opens, and displays a message, again indicating that you must restart the computer to
apply the changes. Click Restar t Now .

Appendix D - Log on to the domain

You can use these procedures to log on to the domain using computers running Windows Server 2008 R2,
Windows 7, Windows Server 2008 , and Windows Vista.
Windows Server 2008 R2 and Windows 7
Windows Server 2008 and Windows Vista
Windows Server 2008 R2 and Windows 7
Membership in Domain Users , or equivalent, is the minimum required to perform this procedure.
L o g o n t o t h e d o m a i n u si n g c o m p u t e r s r u n n i n g W i n d o w s Se r v e r 2 0 0 8 R 2 a n d W i n d o w s 7

1. Log off the computer, or restart the computer.

2. Press CTRL + ALT + DELETE. The logon screen appears.
3. Click Switch User , and then click Other User .
4. In User name , type your domain and user name in the format domain\user. For example, to log on to the
domain corp.contoso.com with an account named User-01 , type CORP\User-01 .
5. In Password , type your domain password, and then click the arrow, or press ENTER.
Windows Server 2008 and Windows Vista
Membership in Domain Users , or equivalent, is the minimum required to perform this procedure.
L o g o n t o t h e d o m a i n u si n g c o m p u t e r s r u n n i n g W i n d o w s Se r v e r 2 0 0 8 a n d W i n d o w s Vi st a

1. Log off the computer, or restart the computer.

2. Press CTRL + ALT + DELETE. The logon screen appears.
3. Click Switch User , and then click Other User .
4. In User name , type your domain and user name in the format domain\user. For example, to log on to the
domain corp.contoso.com with an account named User-01 , type CORP\User-01 .
5. In Password , type your domain password, and then click the arrow, or press ENTER.

Appendix E - Core Network Planning Preparation Sheet

You can use this Network Planning Preparation Sheet to gather the information required to install a core network.
This topic provides tables that contain the individual configuration items for each server computer for which you
must supply information or specific values during the installation or configuration process. Example values are
provided for each configuration item.
For planning and tracking purposes, spaces are provided in each table for you to enter the values used for your
deployment. If you log security-related values in these tables, you should store the information in a secure location.
The following links lead to the sections in this topic that provide configuration items and example values that are
associated with the deployment procedures presented in this guide.
1. Installing Active Directory Domain Services and DNS
Configuring a DNS Reverse Lookup Zone
2. Installing DHCP
Creating an exclusion range in DHCP
 Creating a new DHCP scope
3. Installing Network Policy Server (optional)
Installing Active Directory Domain Services and DNS
The tables in this section list configuration items for pre-installation and installation of Active Directory Domain
Services (AD DS) and DNS.
P r e - i n st a l l a t i o n c o n fi g u r a t i o n i t e m s fo r A D D S a n d D N S

The following tables list pre-installation configuration items as described in Configuring All Servers:
Configure a Static IP Address

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

IP address 10.0.0.2

Subnet mask 255.255.255.0

Default gateway 10.0.0.1

Preferred DNS server 127.0.0.1

Alternate DNS server 10.0.0.15

Rename the Computer

C O N F IGURAT IO N IT EM EXA M P L E VA L UE VA L UE

Computer name DC1

A D D S a n d D N S i n st a l l a t i o n c o n fi g u r a t i o n i t e m s

Configuration items for the Windows Server Core Network deployment procedure Install AD DS and DNS for a
New Forest:

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

Full DNS name corp.contoso.com

Forest functional level Windows Server 2003

Active Directory Domain Services E:\Configuration\

database folder location Or accept the default location.

Active Directory Domain Services log E:\Configuration\

files folder location Or accept the default location.

Active Directory Domain Services E:\Configuration\

SYSVOL folder location Or accept the default location

Directory Restore Mode Administrator J*p2leO4$F

password
 C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

Answer file name (optional) AD DS_AnswerFile

Configuring a DNS Reverse Lookup Zone

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

Zone type: - Primary zone

- Secondary zone
- Stub zone

Zone type - Selected

Store the zone in Active - Not selected
Director y

Active Directory zone replication scope - To all DNS servers in this forest
- To all DNS servers in this domain
- To all domain controllers in this
domain
- To all domain controllers specified in
the scope of this directory partition

Reverse lookup zone name - IPv4 Reverse Lookup Zone

(IP type) - IPv6 Reverse Lookup Zone

Reverse lookup zone name 10.0.0

(network ID)

Installing DHCP
The tables in this section list configuration items for pre-installation and installation of DHCP.
P r e - i n st a l l a t i o n c o n fi g u r a t i o n i t e m s fo r D H C P

The following tables list pre-installation configuration items as described in Configuring All Servers:
Configure a Static IP Address

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

IP address 10.0.0.3

Subnet mask 255.255.255.0

Default gateway 10.0.0.1

Preferred DNS server 10.0.0.2

Alternate DNS server 10.0.0.15

Rename the Computer

C O N F IGURAT IO N IT EM EXA M P L E VA L UE VA L UE

Computer name DHCP1

D H C P i n st a l l a t i o n c o n fi g u r a t i o n i t e m s

Configuration items for the Windows Server Core Network deployment procedure Install Dynamic Host
Configuration Protocol (DHCP):

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

Network connect bindings Ethernet

DNS server settings DC1

Preferred DNS server IP address 10.0.0.2

Alternate DNS server IP address 10.0.0.15

Scope name Corp1

Starting IP address 10.0.0.1

Ending IP address 10.0.0.254

Subnet mask 255.255.255.0

Default gateway (optional) 10.0.0.1

Lease duration 8 days

IPv6 DHCP server operation mode Not enabled

Creating an exclusion range in DHCP

Configuration items to create an exclusion range while creating a scope in DHCP.

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

Scope name Corp1

Scope description Main office subnet 1

Exclusion range start IP address 10.0.0.1

Exclusion range end IP address 10.0.0.15

Creating a new DHCP scope

Configuration items for the Windows Server Core Network deployment procedure Create and Activate a New
DHCP Scope:

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

New scope name Corp2

Scope description Main office subnet 2

(IP address range) 10.0.1.1

Start IP address
 C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

(IP address range) 10.0.1.254

End IP address

Length 8

Subnet mask 255.255.255.0

(Exclusion range) Start IP address 10.0.1.1

Exclusion range end IP address 10.0.1.15

Lease duration -8
Days -0
-0
Hours
Minutes

Router (default gateway) 10.0.1.1

IP address

DNS parent domain corp.contoso.com

DNS server 10.0.0.2

IP address

Installing Network Policy Server (optional)

The tables in this section list configuration items for pre-installation and installation of NPS.
P r e - i n st a l l a t i o n c o n fi g u r a t i o n i t e m s

The following three tables list pre-installation configuration items as described in Configuring All Servers:
Configure a Static IP Address

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES VA L UES

IP address 10.0.0.4

Subnet mask 255.255.255.0

Default gateway 10.0.0.1

Preferred DNS server 10.0.0.2

Alternate DNS server 10.0.0.15

Rename the Computer

C O N F IGURAT IO N IT EM EXA M P L E VA L UE VA L UE

Computer name NPS1

N e t w o r k P o l i c y Se r v e r i n st a l l a t i o n c o n fi g u r a t i o n i t e m s

Configuration items for the Windows Server Core Network NPS deployment procedures Install Network Policy
Server (NPS) and Register the NPS in the Default Domain.
No additional configuration items are required to install and register NPS.
 Core network companion guidance
3/26/2020 • 3 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

While the Windows Server 2016 Core Network Guide provides instructions on how to deploy a new Active
Directory® forest with a new root domain and the supporting networking infrastructure, Companion Guides
provide you with the ability to add features to your network.
Each companion guide allows you to accomplish a specific goal after you have deployed your core network. In
some cases, there are multiple companion guides that, when deployed together and in the correct order, allow you
to accomplish very complex goals in a measured, cost-effective, reasonable manner.
If you deployed your Active Directory domain and core network before encountering the Core Network Guide, you
can still use the Companion Guides to add features to your network. Simply use the Core Network Guide as a list of
prerequisites, and know that to deploy additional features with the Companion Guides, your network must meet the
prerequisites that are provided by the Core Network Guide.

Core Network Companion Guide: Deploy Server Certificates for 802.1X

Wired and Wireless Deployments
This companion guide explains how to build upon the core network by deploying server certificates for computers
that are running Network Policy Server (NPS), Remote Access Service (RAS), or both.
Server certificates are required when you deploy certificate-based authentication methods with Extensible
Authentication Protocol (EAP) and Protected EAP (PEAP) for network access authentication. Deploying server
certificates with Active Directory Certificate Services (AD CS) for EAP and PEAP certificate-based authentication
methods provides the following benefits:
Binding the identity of the NPS or RAS server to a private key
A cost-efficient and secure method for automatically enrolling certificates to domain member NPS and RAS
servers
An efficient method for managing certificates and certification authorities
Security provided by certificate-based authentication
The ability to expand the use of certificates for additional purposes
For instructions on how to deploy server certificates, see Deploy Server Certificates for 802.1X Wired and Wireless
Deployments.

Core Network Companion Guide: Deploy Password-Based 802.1X

Authenticated Wireless Access
This companion guide explains how to build upon the core network by providing instructions about how to deploy
Institute of Electrical and Electronics Engineers (IEEE) 802.1X-authenticated IEEE 802.11 wireless access using
Protected Extensible Authentication Protocol\–Microsoft Challenge Handshake Authentication Protocol version 2
(PEAP-MS-CHAP v2).
The authentication method PEAP-MS-CHAP v2 requires that authenticating servers running Network Policy Server
(NPS) present wireless clients with a server certificate to prove the NPS identity to the client, however user
authentication is not performed by using a certificate - instead, users provide their domain user name and
password.
Because PEAP-MS-CHAP v2 requires that users provide password-based credentials rather than a certificate during
the authentication process, it is typically easier and less expensive to deploy than EAP-TLS or PEAP-TLS.
Before you use this guide to deploy wireless access with the PEAP-MS-CHAP v2 authentication method, you must
do the following:
1. Follow the instructions in the Core Network Guide to deploy your core network infrastructure, or already have
the technologies presented in that guide deployed on your network.
2. Follow the instructions in the Core Network Companion Guide Deploy Server Certificates for 802.1X Wired and
Wireless Deployments, or already have the technologies presented in that guide deployed on your network.
For instructions on how to deploy wireless access with PEAP-MS-CHAP v2, see Deploy Password-Based 802.1X
Authenticated Wireless Access.

Core Network Companion Guide: Deploy BranchCache Hosted Cache

Mode
This companion guide explains how to deploy BranchCache in Hosted Cache Mode in one or more branch offices.
BranchCache is a wide area network (WAN) bandwidth optimization technology that is included in some editions of
the Windows Server 2016 and Windows 10 operating systems, as well as in earlier versions of Windows and
Windows Server.
When you deploy BranchCache in hosted cache mode, the content cache at a branch office is hosted on one or
more server computers, which are called hosted cache servers. Hosted cache servers can run workloads in addition
to hosting the cache, which allows you to use the server for multiple purposes in the branch office.
BranchCache hosted cache mode increases the cache efficiency because content is available even if the client that
originally requested and cached the data is offline. Because the hosted cache server is always available, more
content is cached, providing greater WAN bandwidth savings, and BranchCache efficiency is improved.
When you deploy hosted cache mode, all clients in a multiple-subnet branch office can access a single cache, which
is stored on the hosted cache server, even if the clients are on different subnets.
For instructions on how to deploy BranchCache in Hosted Cache Mode, see Deploy BranchCache Hosted Cache
Mode.
 Deploy Server Certificates for 802.1X Wired and
Wireless Deployments
3/26/2020 • 4 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this guide to deploy server certificates to your Remote Access and Network Policy Server (NPS)
infrastructure servers.
This guide contains the following sections.
Prerequisites for using this guide
What this guide does not provide
Technology overviews
Server Certificate Deployment Overview
Server Certificate Deployment Planning
Server Certificate Deployment
Digital server certificates
This guide provides instructions for using Active Directory Certificate Services (AD CS) to automatically enroll
certificates to Remote Access and NPS infrastructure servers. AD CS allows you to build a public key infrastructure
(PKI) and provide public key cryptography, digital certificates, and digital signature capabilities for your
organization.
When you use digital server certificates for authentication between computers on your network, the certificates
provide:
1. Confidentiality through encryption.
2. Integrity through digital signatures.
3. Authentication by associating certificate keys with computer, user, or device accounts on a computer network.
Server types
By using this guide, you can deploy server certificates to the following types of servers.
Servers that are running the Remote Access service, that are DirectAccess or standard virtual private network
(VPN) servers, and that are members of the RAS and IAS Ser vers group.
Servers that are running the Network Policy Server (NPS) service that are members of the RAS and IAS
Ser vers group.
Advantages of certificate autoenrollment
Automatic enrollment of server certificates, also called autoenrollment, provides the following advantages.
The AD CS certification authority (CA) automatically enrolls a server certificate to all of your NPS and Remote
Access servers.
All computers in the domain automatically receive your CA certificate, which is installed in the Trusted Root
Certification Authorities store on every domain member computer. Because of this, all computers in the domain
trust the certificates that are issued by your CA. This trust allows your authentication servers to prove their
 identities to each other and engage in secure communications.
Other than refreshing Group Policy, the manual reconfiguration of every server is not required.
Every server certificate includes both the Server Authentication purpose and the Client Authentication purpose
in Enhanced Key Usage (EKU) extensions.
Scalability. After deploying your Enterprise Root CA with this guide, you can expand your public key
infrastructure (PKI) by adding Enterprise subordinate CAs.
Manageability. You can manage AD CS by using the AD CS console or by using Windows PowerShell commands
and scripts.
Simplicity. You specify the servers that enroll server certificates by using Active Directory group accounts and
group membership.
When you deploy server certificates, the certificates are based on a template that you configure with the
instructions in this guide. This means that you can customize different certificate templates for specific server
types, or you can use the same template for all server certificates that you want to issue.

Prerequisites for using this guide

This guide provides instructions on how to deploy server certificates by using AD CS and the Web Server (IIS)
server role in Windows Server 2016. Following are the prerequisites for performing the procedures in this guide.
You must deploy a core network using the Windows Server 2016 Core Network Guide, or you must already
have the technologies provided in the Core Network Guide installed and functioning correctly on your
network. These technologies include TCP/IP v4, DHCP, Active Directory Domain Services (AD DS), DNS, and
NPS.

NOTE
The Windows Server 2016 Core Network Guide is available in the Windows Server 2016 Technical Library. For more
information, see Core Network Guide.

You must read the planning section of this guide to ensure that you are prepared for this deployment before
you perform the deployment.
You must perform the steps in this guide in the order in which they are presented. Do not jump ahead and
deploy your CA without performing the steps that lead up to deploying the server, or your deployment will
fail.
You must be prepared to deploy two new servers on your network - one server upon which you will install
AD CS as an Enterprise Root CA, and one server upon which you will install Web Server (IIS) so that your CA
can publish the certificate revocation list (CRL) to the Web server.

NOTE
You are prepared to assign a static IP address to the Web and AD CS servers that you deploy with this guide, as well as to
name the computers according to your organization naming conventions. In addition, you must join the computers to your
domain.

What this guide does not provide

This guide does not provide comprehensive instructions for designing and deploying a public key infrastructure
(PKI) by using AD CS. It is recommended that you review AD CS documentation and PKI design documentation
before deploying the technologies in this guide.
Technology overviews
Following are technology overviews for AD CS and Web Server (IIS).
Active Directory Certificate Services
AD CS in Windows Server 2016 provides customizable services for creating and managing the X.509 certificates
that are used in software security systems that employ public key technologies. Organizations can use AD CS to
enhance security by binding the identity of a person, device, or service to a corresponding public key. AD CS also
includes features that allow you to manage certificate enrollment and revocation in a variety of scalable
environments.
For more information, see Active Directory Certificate Services Overview and Public Key Infrastructure Design
Guidance.
Web Server (IIS )
The Web Server (IIS) role in Windows Server 2016 provides a secure, easy-to-manage, modular, and extensible
platform for reliably hosting websites, services, and applications. With IIS, you can share information with users on
the Internet, an intranet, or an extranet. IIS is a unified web platform that integrates IIS, ASP.NET, FTP services, PHP,
and Windows Communication Foundation (WCF).
For more information, see Web Server (IIS) Overview.
 Server Certificate Deployment Overview
3/26/2020 • 5 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This topic contains the following sections.

Server certificate deployment components
Server certificate deployment process overview

Server certificate deployment components

You can use this guide to install Active Directory Certificate Services (AD CS) as an Enterprise root certification
authority (CA) and to enroll server certificates to servers that are running Network Policy Server (NPS), Routing
and Remote Access service (RRAS), or both NPS and RRAS.
If you deploy SDN with certificate-based authentication, servers are required to use a server certificate to prove
their identities to other servers so that they achieve secure communications.
The following illustration shows the components that are required to deploy server certificates to servers in your
SDN infrastructure.

NOTE
In the illustration above, multiple servers are depicted: DC1, CA1, WEB1, and many SDN servers. This guide provides
instructions for deploying and configuring CA1 and WEB1, and for configuring DC1, which this guide assumes you have
already installed on your network. If you have not already installed your Active Directory domain, you can do so by using the
Core Network Guide for Windows Server 2016.

For more information on each item depicted in the illustration above, see the following:
CA1
WEB1
DC1
NPS1
CA1 running the AD CS server role
In this scenario, the Enterprise Root certification authority (CA) is also an issuing CA. The CA issues certificates to
server computers that have the correct security permissions to enroll a certificate. Active Directory Certificate
Services (AD CS) is installed on CA1.
For larger networks or where security concerns provide justification, you can separate the roles of root CA and
issuing CA, and deploy subordinate CAs that are issuing CAs.
In the most secure deployments, the Enterprise Root CA is taken offline and physically secured.
CAPolicy.inf
Before you install AD CS, you configure the CAPolicy.inf file with specific settings for your deployment.
Copy of the RAS and IAS servers certificate template
When you deploy server certificates, you make one copy of the RAS and IAS ser vers certificate template and
then configure the template according to your requirements and the instructions in this guide.
You utilize a copy of the template rather than the original template so that the configuration of the original template
is preserved for possible future use. You configure the copy of the RAS and IAS ser vers template so that the CA
can create server certificates that it issues to the groups in Active Directory Users and Computers that you specify.
Additional CA1 configuration
The CA publishes a certificate revocation list (CRL) that computers must check to ensure that certificates that are
presented to them as proof of identity are valid certificates and have not been revoked. You must configure your CA
with the correct location of the CRL so that computers know where to look for the CRL during the authentication
process.
WEB1 running the Web Services (IIS ) server role
On the computer that is running the Web Server (IIS) server role, WEB1, you must create a folder in Windows
Explorer for use as the location for the CRL and AIA.
Virtual directory for the CRL and AIA
After you create a folder in Windows Explorer, you must configure the folder as a virtual directory in Internet
Information Services (IIS) Manager, as well as configuring the access control list for the virtual directory to allow
computers to access the AIA and CRL after they are published there.
DC1 running the AD DS and DNS server roles
DC1 is the domain controller and DNS server on your network.
Group Policy default domain policy
After you configure the certificate template on the CA, you can configure the default domain policy in Group Policy
so that certificates are autoenrolled to NPS and RAS servers. Group Policy is configured in AD DS on the server
DC1.
DNS alias (CNAME) resource record
You must create an alias (CNAME) resource record for the Web server to ensure that other computers can find the
server, as well as the AIA and the CRL that are stored on the server. In addition, using an alias CNAME resource
record provides flexibility so that you can use the Web server for other purposes, such as hosting Web and FTP
sites.
NPS1 running the Network Policy Server role service of the Network Policy and Access Services server role
The NPS is installed when you perform the tasks in the Windows Server 2016 Core Network Guide, so before you
perform the tasks in this guide, you should already have one or more NPSs installed on your network.
Group Policy applied and certificate enrolled to servers
After you have configured the certificate template and autoenrollment, you can refresh Group Policy on all target
servers. At this time, the servers enroll the server certificate from CA1.
Server certificate deployment process overview
 NOTE
The details of how to perform these steps are provided in the section Server Certificate Deployment.

The process of configuring server certificate enrollment occurs in these stages:

1. On WEB1, install the Web Server (IIS) role.
2. On DC1, create an alias (CNAME) record for your Web server, WEB1.
3. Configure your Web server to host the CRL from the CA, then publish the CRL and copy the Enterprise Root
CA certificate into the new virtual directory.
4. On the computer where you are planning to install AD CS, assign the computer a static IP address, rename
the computer, join the computer to the domain, and then log on to the computer with a user account that is a
member of the Domain Admins and Enterprise Admins groups.
5. On the computer where you are planning to install AD CS, configure the CAPolicy.inf file with settings that
are specific to your deployment.
6. Install the AD CS server role and perform additional configuration of the CA.
7. Copy the CRL and CA certificate from CA1 to the share on the Web server WEB1.
8. On the CA, configure a copy of the RAS and IAS Servers certificate template. The CA issues certificates based
on a certificate template, so you must configure the template for the server certificate before the CA can
issue a certificate.
9. Configure server certificate autoenrollment in Group Policy. When you configure autoenrollment, all servers
that you have specified with Active Directory group memberships automatically receive a server certificate
when Group Policy on each server is refreshed. If you add more servers later, they will automatically receive
a server certificate, too.
10. Refresh Group Policy on servers. When Group Policy is refreshed, the servers receive the server certificate,
which is based on the template that you configured in the previous step. This certificate is used by the server
to prove its identity to client computers and other servers during the authentication process.

NOTE
All domain member computers automatically receive the Enterprise Root CA's certificate without the configuration of
autoenrollment. This certificate is different than the server certificate that you configure and distribute by using
autoenrollment. The CA's certificate is automatically installed in the Trusted Root Certification Authorities certificate
store for all domain member computers so that they will trust certificates that are issued by this CA.

11. Verify that all servers have enrolled a valid server certificate.
 Server Certificate Deployment Planning
3/26/2020 • 6 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Before you deploy server certificates, you must plan the following items:
Plan basic server configuration
Plan domain access
Plan the location and name of the virtual directory on your Web server
Plan a DNS alias (CNAME) record for your Web server
Plan configuration of CAPolicy.inf
Plan configuration of the CDP and AIA extensions on CA1
Plan the copy operation between the CA and the Web server
Plan the configuration of the server certificate template on the CA

Plan basic server configuration

After you install Windows Server 2016 on the computers that you are planning to use as your certification
authority and Web server, you must rename the computer and assign and configure a static IP address for the local
computer.
For more information, see the Windows Server 2016 Core Network Guide.

Plan domain access

To log on to the domain, the computer must be a domain member computer and the user account must be created
in AD DS before the logon attempt. In addition, most procedures in this guide require that the user account is a
member of the Enterprise Admins or Domain Admins groups in Active Directory Users and Computers, so you
must log on to the CA with an account that has the appropriate group membership.
For more information, see the Windows Server 2016 Core Network Guide.

Plan the location and name of the virtual directory on your Web server
To provide access to the CRL and the CA certificate to other computers, you must store these items in a virtual
directory on your Web server. In this guide, the virtual directory is located on the Web server WEB1. This folder is
on the "C:" drive and is named "pki." You can locate your virtual directory on your Web server at any folder location
that is appropriate for your deployment.

Plan a DNS alias (CNAME) record for your Web server

Alias (CNAME) resource records are also sometimes called canonical name resource records. With these records,
you can use more than one name to point to a single host, making it easy to do such things as host both a File
Transfer Protocol (FTP) server and a Web server on the same computer. For example, the well-known server names
(ftp, www) are registered using alias (CNAME) resource records that map to the Domain Name System (DNS) host
name, such as WEB1, for the server computer that hosts these services.
This guide provides instructions for configuring your Web server to host the certificate revocation list (CRL) for
your certification authority (CA). Because you might also want to use your Web server for other purposes, such as
to host an FTP or Web site, it's a good idea to create an alias resource record in DNS for your Web server. In this
guide, the CNAME record is named "pki," but you can choose a name that is appropriate for your deployment.

Plan configuration of CAPolicy.inf

Before you install AD CS, you must configure CAPolicy.inf on the CA with information that is correct for your
deployment. A CAPolicy.inf file contains the following information:

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=https://pki.corp.contoso.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=weeks
CRLPeriodUnits=1
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1

You must plan the following items for this file:

URL . The example CAPolicy.inf file has a URL value of https://pki.corp.contoso.com/pki/cps.txt . This is
because the Web server in this guide is named WEB1 and has a DNS CNAME resource record of pki. The
Web server is also joined to the corp.contoso.com domain. In addition, there is a virtual directory on the
Web server named "pki" where the certificate revocation list is stored. Ensure that the value that you provide
for URL in your CAPolicy.inf file points to a virtual directory on your Web server in your domain.
RenewalKeyLength . The default renewal key length for AD CS in Windows Server 2012 is 2048. The key
length that you select should be as long as possible while still providing compatibility with the applications
that you intend to use.
RenewalValidityPeriodUnits . The example CAPolicy.inf file has a RenewalValidityPeriodUnits value of 5
years. This is because the expected lifespan of the CA is around ten years. The value of
RenewalValidityPeriodUnits should reflect the overall validity period of the CA or the highest number of
years for which you want to provide enrollment.
CRLPeriodUnits . The example CAPolicy.inf file has a CRLPeriodUnits value of 1. This is because the example
refresh interval for the certificate revocation list in this guide is 1 week. At the interval value that you specify
with this setting, you must publish the CRL on the CA to the Web server virtual directory where you store
the CRL and provide access to it for computers that are in the authentication process.
AlternateSignatureAlgorithm . This CAPolicy.inf implements an improved security mechanism by
implementing alternate signature formats. You should not implement this setting if you still have Windows
XP clients that require certificates from this CA.
If you do not plan on adding any subordinate CAs to your public key infrastructure at a later time, and if you want
to prevent the addition of any subordinate CAs, you can add the PathLength key to your CAPolicy.inf file with a
value of 0. To add this key, copy and paste the following code into your file:
 [BasicConstraintsExtension]
PathLength=0
Critical=Yes

IMPORTANT
It is not recommended that you change any other settings in the CAPolicy.inf file unless you have a specific reason for doing
so.

Plan configuration of the CDP and AIA extensions on CA1

When you configure the Certificate Revocation List (CRL) Distribution Point (CDP) and the Authority Information
Access (AIA) settings on CA1, you need the name of your Web server and your domain name. You also need the
name of the virtual directory that you create on your Web server where the certificate revocation list (CRL) and the
certification authority certificate are stored.
The CDP location that you must enter during this deployment step has the format:

`http:\/\/*DNSAlias\(CNAME\)RecordName*.*Domain*.com\/*VirtualDirectoryName*\/<CaName><CRLNameSuffix>
<DeltaCRLAllowed>.crl.`

For example, if your Web server is named WEB1 and your DNS alias CNAME record for the Web server is "pki,"
your domain is corp.contoso.com, and your virtual directory is named pki, the CDP location is:

`http:\/\/pki.corp.contoso.com\/pki\/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl`

The AIA location that you must enter has the format:

`http:\/\/*DNSAlias\(CNAME\)RecordName*.*Domain*.com\/*VirtualDirectoryName*\/<ServerDNSName>\_<CaName>
<CertificateName>.crt.`

For example, if your Web server is named WEB1 and your DNS alias CNAME record for the Web server is "pki,"
your domain is corp.contoso.com, and your virtual directory is named pki, the AIA location is:

`http:\/\/pki.corp.contoso.com\/pki\/<ServerDNSName>\_<CaName><CertificateName>.crt`

Plan the copy operation between the CA and the Web server
To publish the CRL and CA certificate from the CA to the Web server virtual directory, you can run the certutil -crl
command after you configure the CDP and AIA locations on the CA. Ensure that you configure the correct paths on
the CA Properties Extensions tab before you run this command using the instructions in this guide. In addition, to
copy the Enterprise CA certificate to the Web server, you must have already created the virtual directory on the
Web server and configured the folder as a shared folder.

Plan the configuration of the server certificate template on the CA

To deploy autoenrolled server certificates, you must copy the certificate template named RAS and IAS Ser ver . By
default, this copy is named Copy of RAS and IAS Ser ver . If you want to rename this template copy, plan the
name that you want to use during this deployment step.

NOTE
The last three deployment sections in this guide - which allow you to configure server certificate autoenrollment, refresh
Group Policy on servers, and verify that the servers have received a valid server certificate from the CA - do not require
additional planning steps.
 Server Certificate Deployment
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Follow these steps to install an enterprise root certification authority (CA) and to deploy server certificates for use
with PEAP and EAP.

IMPORTANT
Before you install Active Directory Certificate Services, you must name the computer, configure the computer with a static IP
address, and join the computer to the domain. After you install AD CS, you cannot change the computer name or the
domain membership of the computer, however you can change the IP address if needed. For more information on how to
accomplish these tasks, see the Windows Server® 2016 Core Network Guide.

Install the Web Server WEB1

Create an alias (CNAME) record in DNS for WEB1
Configure WEB1 to distribute Certificate Revocation Lists (CRLs)
Prepare the CAPolicy inf file
Install the Certification Authority
Configure the CDP and AIA extensions on CA1
Copy the CA certificate and CRL to the virtual directory
Configure the server certificate template
Configure server certificate autoenrollment
Refresh Group Policy
Verify Server Enrollment of a Server Certificate

NOTE
The procedures in this guide do not include instructions for cases in which the User Account Control dialog box opens to
request your permission to continue. If this dialog box opens while you are performing the procedures in this guide, and if
the dialog box was opened in response to your actions, click Continue .
 Install the Web Server WEB1
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

The Web Server (IIS) role in Windows Server 2016 provides a secure, easy-to-manage, modular and extensible
platform for reliably hosting websites, services, and applications. With IIS, you can share information with users on
the Internet, an intranet, or an extranet. IIS is a unified web platform that integrates IIS, ASP.NET, FTP services, PHP,
and Windows Communication Foundation (WCF).
When you deploy server certificates, your Web server provides you with a location where you can publish the
certificate revocation list (CRL) for your certification authority (CA). After publication, the CRL is accessible to all
computers on your network so that they can use this list during the authentication process to verify that certificates
presented by other computers are not revoked.
If a certificate is on the CRL as revoked, the authentication effort fails and your computer is protected from trusting
an entity that has a certificate that is no longer valid.
Before you install the Web Server (IIS) role, ensure that you have configured the server name and IP address and
have joined the computer to the domain.

To install the Web Server (IIS) server role

To complete this procedure, you must be a member of the Administrators group.

NOTE
To perform this procedure by using Windows PowerShell, open PowerShell, type the following command, and then press
ENTER.
Install-WindowsFeature Web-Server -IncludeManagementTools

1. In Server Manager, click Manage , and then click Add Roles and Features . The Add Roles and Features Wizard
opens.
2. In Before You Begin , click Next .
Note
The Before You Begin page of the Add Roles and Features Wizard is not displayed if you have previously run the
Add Roles and Features Wizard and you selected Skip this page by default at that time.
3. On the Installation Type page, click Next .
4. On the Ser ver selection page, click Next .
5. On the Ser ver roles page, select Web Ser ver (IIS) , and then click Next .
6. Click Next until you have accepted all of the default web server settings, and then click Install .
7. Verify that all installations were successful, and then click Close .
 Create an Alias (CNAME) Record in DNS for WEB1
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to add an Alias canonical name (CNAME) resource record for your Web server to a zone
in DNS on your domain controller. With CNAME records, you can use more than one name to point to a single host,
making it easy to do such things as host both a File Transfer Protocol (FTP) server and a Web server on the same
computer.
Because of this, you are free to use your Web server to host the certificate revocation list (CRL) for your
certification authority (CA) as well as to perform additional services, such as FTP or Web server.
When you perform this procedure, replace Alias name and other variables with values that are appropriate for
your deployment.
To perform this procedure, you must be a member of Domain Admins .

To add an alias (CNAME) resource record to a zone

NOTE
To perform this procedure by using Windows PowerShell, see Add-DnsServerResourceRecordCName.

1. On DC1, in Server Manager, click Tools and then click DNS . The DNS Manager Microsoft Management
Console (MMC) opens.
2. In the console tree, double-click For ward Lookup Zones , right-click the forward lookup zone where you
want to add the Alias resource record, and then click New Alias (CNAME) . The New Resource Record
dialog box opens.
3. In Alias name , type the alias name pki .
4. When you type a value for Alias name , the Fully qualified domain name (FQDN) auto-fills in the dialog
box. For example, if your alias name is "pki" and your domain is corp.contoso.com, the value
pki.corp.contoso.com is auto-filled for you.
5. In Fully qualified domain name (FQDN) for target host , type the FQDN of your Web server. For
example, if your Web server is named WEB1 and your domain is corp.contoso.com, type
WEB1.corp.contoso.com .
6. Click OK to add the new record to the zone.
 Configure WEB1 to Distribute Certificate Revocation
Lists (CRLs)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to configure the web server WEB1 to distribute CRLs.
In the extensions of the root CA, it was stated that the CRL from the root CA would be available via
https://pki.corp.contoso.com/pki. Currently, there is not a PKI virtual directory on WEB1, so one must be created.
To perform this procedure, you must be a member of Domain Admins .

NOTE
In the procedure below, replace the user account name, the Web server name, folder names and locations, and other values
with those that are appropriate for your deployment.

To configure WEB1 to distribute certificates and CRLs

1. On WEB1, run Windows PowerShell as an administrator, type explorer c:\ , and then press ENTER.
Windows Explorer opens to drive C.
2. Create a new folder named PKI on the C: drive. To do so, click Home , and then click New Folder . A new
folder is created with the temporary name highlighted. Type pki and then press ENTER.
3. In Windows Explorer, right-click the folder you just created, hover the mouse cursor over Share with , and
then click Specific people . The File Sharing dialog box opens.
4. In File Sharing , type Cer t Publishers , and then click Add . The Cert Publishers group is added to the list. In
the list, in Permission Level , click the arrow next to Cer t Publishers , and then click Read/Write . Click
Share , and then click Done .
5. Close Windows Explorer.
6. Open the IIS console. In Server Manager, click Tools , and then click Internet Information Ser vices (IIS)
Manager .
7. In the Internet Information Services (IIS) Manager console tree, expand WEB1 . If you are invited to get
started with Microsoft Web Platform, click Cancel .
8. Expand Sites and then right-click the Default Web Site and then click Add Vir tual Director y .
9. In Alias , type pki . In Physical path type C:\pki , then click OK .
10. Enable Anonymous access to the pki virtual directory, so that any client can check the validity of the CA
certificates and CRLs. To do so:
a. In the Connections pane, ensure that pki is selected.
b. On pki Home click Authentication .
c. In the Actions pane, click Edit Permissions .
d. On the Security tab, click Edit
 e. On the Permissions for pki dialog box, click Add .
f. In the Select Users, Computers, Ser vice Accounts, or Groups , type ANONYMOUS LOGON;
Ever yone and then click Check Names . Click OK .
g. Click OK on the Select Users, Computers, Ser vice Accounts or Groups dialog box.
h. Click OK on the Permissions for pki dialog box.
11. Click OK on the pki Proper ties dialog box.
12. In the pki Home pane, double-click Request Filtering .
13. The File Name Extensions tab is selected by default in the Request Filtering pane. In the Actions pane,
click Edit Feature Settings .
14. In Edit Request Filtering Settings , select Allow double escaping and then click OK .
15. In the Internet Information Services (IIS) Manager MMC, click your Web server name. For example, if your
Web server is named WEB1, click WEB1 .
16. In Actions , click Restar t . Internet services are stopped and then restarted.
 CAPolicy.inf Syntax
3/26/2020 • 9 minutes to read • Edit Online

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

The CAPolicy.inf is a configuration file that defines the extensions, constraints, and other configuration settings that
are applied to a root CA certificate and all certificates issued by the root CA. The CAPolicy.inf file must be installed
on a host server before the setup routine for the root CA begins. When the security restrictions on a root CA are to
be modified, the root certificate must be renewed and an updated CAPolicy.inf file must be installed on the server
before the renewal process begins.
The CAPolicy.inf is:
Created and defined manually by an administrator
Utilized during the creation of root and subordinate CA certificates
Defined on the signing CA where you sign and issue the certificate (not the CA where the request is granted)
Once you have created your CAPolicy.inf file, you must copy it into the %systemroot% folder of your server
before you install ADCS or renew the CA certificate.
The CAPolicy.inf makes it possible to specify and configure a wide variety of CA attributes and options. The
following section describes all the options for you to create an .inf file tailored to your specific needs.

CAPolicy.inf File Structure

The following terms are used to describe the .inf file structure:
Section – is an area of the file that covers a logical group of keys. Section names in .inf files are identified by
appearing in brackets. Many, but not all, sections are used to configure certificate extensions.
Key – is the name of an entry and appears to the left of the equal sign.
Value – is the parameter and appears to the right of the equal sign.
In the example below, [Version] is the section, Signature is the key, and "$Windows NT$" is the value.
Example:

[Version] #section
Signature="$Windows NT$" #key=value

Version
Identifies the file as an .inf file. Version is the only required section and must be at the beginning of your
CAPolicy.inf file.
PolicyStatementExtension
Lists the policies that have been defined by the organization, and whether they are optional or mandatory. Multiple
policies are separated by commas. The names have meaning in the context of a specific deployment, or in relation
to custom applications that check for the presence of these policies.
For each policy defined, there must be a section that defines the settings for that particular policy. For each policy,
you need to provide a user-defined object identifier (OID) and either the text you want displayed as the policy
statement or a URL pointer to the policy statement. The URL can be in the form of an HTTP, FTP, or LDAP URL.
If you are going to have descriptive text in the policy statement, then the next three lines of the CAPolicy.inf would
look like:

[InternalPolicy]
OID=1.1.1.1.1.1.1
Notice=”Legal policy statement text”

If you are going to use a URL to host the CA policy statement, then next three lines would instead look like:

[InternalPolicy]
OID=1.1.1.1.1.1.2
URL=https://pki.wingtiptoys.com/policies/legalpolicy.asp

In addition:
Multiple URL and Notice keys are supported.
Notice and URL keys in the same policy section are supported.
URLs with spaces or text with spaces must be surrounded by quotes. This is true for the URL key, regardless
of the section in which it appears.
An example of multiple notices and URLs in a policy section would look like:

[InternalPolicy]
OID=1.1.1.1.1.1.1
URL=https://pki.wingtiptoys.com/policies/legalpolicy.asp
URL=ftp://ftp.wingtiptoys.com/pki/policies/legalpolicy.asp
Notice=”Legal policy statement text”

CRLDistributionPoint
You can specify CRL Distribution Points (CDPs) for a root CA certificate in the CAPolicy.inf. After installing the CA,
you can configure the CDP URLs that the CA includes in each certificate issued. The root CA certificate shows the
URLs specified in this section of the CAPolicy.inf file.

[CRLDistributionPoint]
URL=http://pki.wingtiptoys.com/cdp/WingtipToysRootCA.crl

Some additional information about this section:

Supports:
HTTP
File URLs
LDAP URLs
Multiple URLs

IMPORTANT
Does not support HTTPS URLs.

Quotes must surround URLs with spaces.

 If no URLs are specified – that is, if the [CRLDistributionPoint] section exists in the file but is empty – the
CRL Distribution Point extension is omitted from the root CA certificate. This is usually preferable when
setting up a root CA. Windows does not perform revocation checking on a root CA certificate, so the CDP
extension is superfluous in a root CA certificate.
CA can publish to FILE UNC, for example, to a share that represents the folder of a website where a client
retrieves via HTTP.
Only use this section if you are setting up a root CA or renewing the root CA certificate. The CA determines
the subordinate CA CDP extensions.
AuthorityInformationAccess
You can specify the authority information access points in the CAPolicy.inf for the root CA certificate.

[AuthorityInformationAccess]
URL=http://pki.wingtiptoys.com/Public/myCA.crt

Some additional notes on the authority information access section:

Multiple URLs are supported.
HTTP, FTP, LDAP and FILE URLs are supported. HTTPS URLs are not supported.
This section is only used if you are setting up a root CA, or renewing the root CA certificate. Subordinate CA
AIA extensions are determined by the CA which issued the subordinate CA's certificate.
URLs with spaces must be surrounded by quotes.
If no URLs are specified – that is, if the [AuthorityInformationAccess] section exists in the file but is empty
– the Authority Information Access extension is omitted from the root CA certificate. Again, this would be the
preferred setting in the case of a root CA certificate as there is no authority higher than a root CA that would
need to be referenced by a link to its certificate.
certsrv_Server
Another optional section of the CAPolicy.inf is [certsrv_server], which is used to specify renewal key length, the
renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or
installed. None of the keys in this section are required. Many of these settings have default values that are sufficient
for most needs and can simply be omitted from the CAPolicy.inf file. Alternatively, many of these settings can be
changed after the CA has been installed.
An example would look like:

[certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=Days
CRLPeriodUnits=2
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=4
ClockSkewMinutes=20
LoadDefaultTemplates=True
AlternateSignatureAlgorithm=0
ForceUTF8=0
EnableKeyCounting=0

RenewalKeyLength sets the key size for renewal only. This is only used when a new key pair is generated during
CA certificate renewal. The key size for the initial CA certificate is set when the CA is installed.
When renewing a CA certificate with a new key pair, the key length can be either increased or decreased. For
example, if you have set a root CA key size of 4096 bytes or higher, and then discover that you have Java apps or
network devices that can only support key sizes of 2048 bytes. Whether you increase or decrease the size, you
must reissue all the certificates issued by that CA.
RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of the new root CA certificate
when renewing the old root CA certificate. It only applies to a root CA. The certificate lifetime of a subordinate CA is
determined by its superior. RenewalValidityPeriod can have the following values: Hours, Days, Weeks, Months, and
Years.
CRLPeriod and CRLPeriodUnits establish the validity period for the base CRL. CRLPeriod can have the following
values: Hours, Days, Weeks, Months, and Years.
CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period of the delta CRL. CRLDeltaPeriod can
have the following values: Hours, Days, Weeks, Months, and Years.
Each of these settings can be configured after the CA has been installed:

Certutil -setreg CACRLPeriod Weeks

Certutil -setreg CACRLPeriodUnits 1
Certutil -setreg CACRLDeltaPeriod Days
Certutil -setreg CACRLDeltaPeriodUnits 1

Remember to restart Active Directory Certificate Services for any changes to take effect.
LoadDefaultTemplates only applies during the install of an Enterprise CA. This setting, either True or False (or 1 or
0), dictates if the CA is configured with any of the default templates.
In a default installation of the CA, a subset of the default certificate templates is added to the Certificate Templates
folder in the Certification Authority snap-in. This means that as soon as the AD CS service starts after the role has
been installed a user or computer with sufficient permissions can immediately enroll for a certificate.
You may not want to issue any certificates immediately after a CA has been installed, so you can use the
LoadDefaultTemplates setting to prevent the default templates from being added to the Enterprise CA. If there are
no templates configured on the CA then it can issue no certificates.
AlternateSignatureAlgorithm configures the CA to support the PKCS#1 V2.1 signature format for both the CA
certificate and certificate requests. When set to 1 on a root CA the CA certificate will include the PKCS#1 V2.1
signature format. When set on a subordinate CA, the subordinate CA will create a certificate request that includes
the PKCS#1 V2.1 signature format.
ForceUTF8 changes the default encoding of relative distinguished names (RDNs) in Subject and Issuer
distinguished names to UTF-8. Only those RDNs that support UTF-8, such as those that are defined as Directory
String types by an RFC, are affected. For example, the RDN for Domain Component (DC) supports encoding as
either IA5 or UTF-8, while the Country RDN (C) only supports encoding as a Printable String. The ForceUTF8
directive will therefore affect a DC RDN but will not affect a C RDN.
EnableKeyCounting configures the CA to increment a counter every time the CA's signing key is used. Do not
enable this setting unless you have a Hardware Security Module (HSM) and associated cryptographic service
provider (CSP) that supports key counting. Neither the Microsoft Strong CSP nor the Microsoft Software Key
Storage Provider (KSP) support key counting.

Create the CAPolicy.inf file

Before you install AD CS, you configure the CAPolicy.inf file with specific settings for your deployment.
Prerequisite: You must be a member of the Administrators group.
1. On the computer where you are planning to install AD CS, open Windows PowerShell, type notepad
c:\CAPolicy.inf and press ENTER.
2. When prompted to create a new file, click Yes .
3. Enter the following as the contents of the file:

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=https://pki.corp.contoso.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=weeks
CRLPeriodUnits=1
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1
[CRLDistributionPoint]
[AuthorityInformationAccess]

4. Click File , and then click Save As .

5. Navigate to the %systemroot% folder.
6. Ensure the following:
File name is set to CAPolicy.inf
Save as type is set to All Files
Encoding is ANSI
7. Click Save .
8. When you are prompted to overwrite the file, click Yes .

Cau t i on

Be sure to save the CAPolicy.inf with the inf extension. If you do not specifically type .inf at the end of the file
name and select the options as described, the file will be saved as a text file and will not be used during CA
 installation.
9. Close Notepad.

IMPORTANT
In the CAPolicy.inf, you can see there is a line specifying the URL https://pki.corp.contoso.com/pki/cps.txt. The Internal Policy
section of the CAPolicy.inf is just shown as an example of how you would specify the location of a certificate practice
statement (CPS). In this guide, you are not instructed to create the certificate practice statement (CPS).
 Install the Certification Authority
3/26/2020 • 3 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to install Active Directory Certificate Services (AD CS) so that you can enroll a server
certificate to servers that are running Network Policy Server (NPS), Routing and Remote Access Service (RRAS), or
both.

IMPORTANT
Before you install Active Directory Certificate Services, you must name the computer, configure the computer with a static
IP address, and join the computer to the domain. For more information on how to accomplish these tasks, see the
Windows Server 2016 Core Network Guide.
To perform this procedure, the computer on which you are installing AD CS must be joined to a domain where Active
Directory Domain Services (AD DS) is installed.

Membership in both the Enterprise Admins and the root domain's Domain Admins group is the minimum
required to complete this procedure.

NOTE
To perform this procedure by using Windows PowerShell, open Windows PowerShell and type the following command, and
then press ENTER.
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

After AD CS is installed, type the following command and press ENTER.

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

To install Active Directory Certificate Services

TIP
If you want to use Windows PowerShell to install Active Directory Certificate Services, see Install-AdcsCertificationAuthority
for cmdlets and optional parameters.

1. Log on as a member of both the Enterprise Admins group and the root domain's Domain Admins group.
2. In Server Manager, click Manage , and then click Add Roles and Features . The Add Roles and Features
Wizard opens.
3. In Before You Begin , click Next .

NOTE
The Before You Begin page of the Add Roles and Features Wizard is not displayed if you have previously selected
Skip this page by default when the Add Roles and Features Wizard was run.

4. In Select Installation Type , ensure that Role-Based or feature-based installation is selected, and then
 click Next .
5. In Select destination ser ver , ensure that Select a ser ver from the ser ver pool is selected. In Ser ver
Pool , ensure that the local computer is selected. Click Next .
6. In Select Ser ver Roles , in Roles , select Active Director y Cer tificate Ser vices . When you are prompted
to add required features, click Add Features , and then click Next .
7. In Select features , click Next .
8. In Active Director y Cer tificate Ser vices , read the provided information, and then click Next .
9. In Confirm installation selections , click Install . Do not close the wizard during the installation process.
When installation is complete, click Configure Active Director y Cer tificate Ser vices on the
destination ser ver . The AD CS Configuration wizard opens. Read the credentials information and, if
needed, provide the credentials for an account that is a member of the Enterprise Admins group. Click Next .
10. In Role Ser vices , click Cer tification Authority , and then click Next .
11. On the Setup Type page, verify that Enterprise CA is selected, and then click Next .
12. On the Specify the type of the CA page, verify that Root CA is selected, and then click Next .
13. On the Specify the type of the private key page, verify that Create a new private key is selected, and
then click Next .
14. On the Cr yptography for CA page, keep the default settings for CSP (RSA#Microsoft Software Key
Storage Provider ) and hash algorithm (SHA2 ), and determine the best key character length for your
deployment. Large key character lengths provide optimal security; however, they can impact server
performance and might not be compatible with legacy applications. It is recommended that you keep the
default setting of 2048. Click Next .
15. On the CA Name page, keep the suggested common name for the CA or change the name according to
your requirements. Ensure that you are certain the CA name is compatible with your naming conventions
and purposes, because you cannot change the CA name after you have installed AD CS. Click Next .
16. On the Validity Period page, in Specify the validity period , type the number and select a time value
(Years, Months, Weeks, or Days). The default setting of five years is recommended. Click Next .
17. On the CA Database page, in Specify the database locations , specify the folder location for the
certificate database and the certificate database log. If you specify locations other than the default locations,
ensure that the folders are secured with access control lists (ACLs) that prevent unauthorized users or
computers from accessing the CA database and log files. Click Next .
18. In Confirmation , click Configure to apply your selections, and then click Close .
 Configure the CDP and AIA Extensions on CA1
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to configure the Certificate Revocation List (CRL) Distribution Point (CDP) and the
Authority Information Access (AIA) settings on CA1.
To perform this procedure, you must be a member of Domain Admins.
To configure the CDP and AIA extensions on CA1
1. In Server Manager, click Tools and then click Cer tification Authority .
2. In the Certification Authority console tree, right-click corp-CA1-CA , and then click Proper ties .

NOTE
The name of your CA is different if you did not name the computer CA1 and your domain name is different than the
one in this example. The CA name is in the format domain-CAComputerName-CA.

3. Click the Extensions tab. Ensure that Select extension is set to CRL Distribution Point (CDP) , and in the
Specify locations from which users can obtain a cer tificate revocation list (CRL) , do the following:
a. Select the entry file://\\<ServerDNSName>\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl ,
and then click Remove . In Confirm removal , click Yes .
b. Select the entry http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl , and
then click Remove . In Confirm removal , click Yes .
c. Select the entry that starts with the path
ldap:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName> , and then click Remove . In
Confirm removal , click Yes .
4. In Specify locations from which users can obtain a cer tificate revocation list (CRL) , click Add . The
Add Location dialog box opens.
5. In Add Location , in Location , type
http://pki.corp.contoso.com/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl , and then click OK . This
returns you to the CA properties dialog box.
6. On the Extensions tab, select the following check boxes:
Include in CRLs. Clients use this to find the Delta CRL locations
Include in the CDP extension of issued cer tificates
7. In Specify locations from which users can obtain a cer tificate revocation list (CRL) , click Add . The
Add Location dialog box opens.
8. In Add Location , in Location , type
file://\\pki.corp.contoso.com\pki\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl , and then click OK . This
returns you to the CA properties dialog box.
9. On the Extensions tab, select the following check boxes:
 Publish CRLs to this location
Publish Delta CRLs to this location
10. Change Select extension to Authority Information Access (AIA) , and in the Specify locations from
which users can obtain a cer tificate revocation list (CRL) , do the following:
a. Select the entry that starts with the path ldap:///CN=<CATruncatedName>,CN=AIA,CN=Public Key Services ,
and then click Remove . In Confirm removal , click Yes .
b. Select the entry http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt ,
and then click Remove . In Confirm removal , click Yes .
c. Select the entry file://\\<ServerDNSName>\CertEnroll\<ServerDNSName><CaName><CertificateName>.crt ,
and then click Remove . In Confirm removal , click Yes .
11. In Specify locations from which users can obtain the cer tificate for this CA , click Add . The Add
Location dialog box opens.
12. In Add Location , in Location , type
http://pki.corp.contoso.com/pki/<ServerDNSName>_<CaName><CertificateName>.crt , and then click OK . This
returns you to the CA properties dialog box.
13. On the Extensions tab, select Include in the AIA of issued cer tificates .
14. When prompted to restart Active Directory Certificate Services, click No . You will restart the service later.
 Copy the CA Certificate and CRL to the Virtual
Directory
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to copy the Certificate Revocation List and Enterprise root CA certificate from your
certification authority to a virtual directory on your Web server, and to ensure that AD CS is configured correctly.
Before running the commands below, ensure that you replace directory and server names with those that are
appropriate for your deployment.
To perform this procedure you must be a member of Domain Admins .
To copy the certificate revocation list from CA1 to WEB1
1. On CA1, run Windows PowerShell as an Administrator, and then publish the CRL with the following
command:
Type certutil -crl , and then press ENTER.
To copy the CA1 certificate to the file share on your Web server, type
copy C:\Windows\system32\certsrv\certenroll\*.crt \\WEB1\pki , and then press ENTER.

To copy the certificate revocation lists to the file share on your Web server, type
copy C:\Windows\system32\certsrv\certenroll\*.crl \\WEB1\pki , and then press ENTER.

2. To verify that your CDP and AIA extension locations are correctly configured, type pkiview.msc , and then
press ENTER. The pkiview Enterprise PKI MMC opens.
3. In the left pane, click your CA name.
For example, if your CA name is corp-CA1-CA, click corp-CA1-CA .
4. In the Status column of the results pane, verify that the values for the following shows OK :
CA Cer tificate
AIA Location #1
CDP Location #1

TIP
If Status for any item is not OK , do the following:
Open the share on your Web server to verify that the certificate and certificate revocation list files were successfully
copied to the share. If they were not successfully copied to the share, modify your copy commands with the correct file
source and share destination and run the commands again.
Verify that you have entered the correct locations for the CDP and AIA on the CA Extensions tab. Ensure that there are no
extra spaces or other characters in the locations that you have provided.
Verify that you copied the CRL and CA certificate to the correct location on your Web server, and that the location
matches the location you provided for the CDP and AIA locations on the CA.
Verify that you correctly configured permissions for the virtual folder where the CA certificate and CRL are stored.
 Configure the Server Certificate Template
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to configure the certificate template that Active Directory® Certificate Services (AD
CS) uses as the basis for server certificates that are enrolled to servers on your network.
While configuring this template, you can specify the servers by Active Directory group that should automatically
receive a server certificate from AD CS.
The procedure below includes instructions for configuring the template to issue certificates to all of the following
server types:
Servers that are running the Remote Access service, including RAS Gateway servers, that are members of the
RAS and IAS Ser vers group.
Servers that are running the Network Policy Server (NPS) service that are members of the RAS and IAS
Ser vers group.
Membership in both the Enterprise Admins and the root domain's Domain Admins group is the minimum
required to complete this procedure.
To configure the certificate template
1. On CA1, in Server Manager, click Tools , and then click Cer tification Authority . The Certification Authority
Microsoft Management Console (MMC) opens.
2. In the MMC, double-click the CA name, right-click Cer tificate Templates , and then click Manage .
3. The Certificate Templates console opens. All of the certificate templates are displayed in the details pane.
4. In the details pane, click the RAS and IAS Ser ver template.
5. Click the Action menu, and then click Duplicate Template . The template Proper ties dialog box opens.
6. Click the Security tab.
7. On the Security tab, in Group or user names , click RAS and IAS ser vers .
8. In Permissions for RAS and IAS ser vers , under Allow , ensure that Enroll is selected, and then select the
Autoenroll check box. Click OK , and close the Certificate Templates MMC.
9. In the Certification Authority MMC, click Cer tificate Templates . On the Action menu, point to New , and
then click Cer tificate Template to Issue . The Enable Cer tificate Templates dialog box opens.
10. In Enable Cer tificate Templates , click the name of the certificate template that you just configured, and
then click OK . For example, if you did not change the default certificate template name, click Copy of RAS
and IAS Ser ver , and then click OK .
 Configure certificate auto-enrollment
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

NOTE
Before you perform this procedure, you must configure a server certificate template by using the Certificate Templates
Microsoft Management Console snap-in on a CA that is running AD CS. Membership in both the Enterprise Admins and
the root domain's Domain Admins group is the minimum required to complete this procedure.

Configure server certificate auto-enrollment

1. On the computer where AD DS is installed, open Windows PowerShell®, type mmc , and then press ENTER.
The Microsoft Management Console opens.
2. On the File menu, click Add/Remove Snap-in . The Add or Remove Snap-ins dialog box opens.
3. In Available snap-ins , scroll down to and double-click Group Policy Management Editor . The Select
Group Policy Object dialog box opens.

IMPORTANT
Ensure that you select Group Policy Management Editor and not Group Policy Management . If you select
Group Policy Management , your configuration using these instructions will fail and a server certificate will not be
autoenrolled to your NPSs.

4. In Group Policy Object , click Browse . The Browse for a Group Policy Object dialog box opens.
5. In Domains, OUs, and linked Group Policy Objects, click Default Domain Policy , and then click OK .
6. Click Finish , and then click OK .
7. Double-click Default Domain Policy . In the console, expand the following path: Computer
Configuration , Policies , Windows Settings , Security Settings , and then Public Key Policies .
8. Click Public Key Policies . In the details pane, double-click Cer tificate Ser vices Client - Auto-
Enrollment . The Proper ties dialog box opens. Configure the following items, and then click OK :
a. In Configuration Model , select Enabled .
b. Select the Renew expired cer tificates, update pending cer tificates, and remove revoked
cer tificates check box.
c. Select the Update cer tificates that use cer tificate templates check box.
9. Click OK .

Configure user certificate auto-enrollment

1. On the computer where AD DS is installed, open Windows PowerShell®, type mmc , and then press ENTER.
The Microsoft Management Console opens.
2. On the File menu, click Add/Remove Snap-in . The Add or Remove Snap-ins dialog box opens.
3. In Available snap-ins , scroll down to and double-click Group Policy Management Editor . The Select
Group Policy Object dialog box opens.

IMPORTANT
Ensure that you select Group Policy Management Editor and not Group Policy Management . If you select
Group Policy Management , your configuration using these instructions will fail and a server certificate will not be
autoenrolled to your NPSs.

4. In Group Policy Object , click Browse . The Browse for a Group Policy Object dialog box opens.
5. In Domains, OUs, and linked Group Policy Objects, click Default Domain Policy , and then click OK .
6. Click Finish , and then click OK .
7. Double-click Default Domain Policy . In the console, expand the following path: User Configuration ,
Policies , Windows Settings , Security Settings .
8. Click Public Key Policies . In the details pane, double-click Cer tificate Ser vices Client - Auto-
Enrollment . The Proper ties dialog box opens. Configure the following items, and then click OK :
a. In Configuration Model , select Enabled .
b. Select the Renew expired cer tificates, update pending cer tificates, and remove revoked
cer tificates check box.
c. Select the Update cer tificates that use cer tificate templates check box.
9. Click OK .

Next Steps
Refresh Group Policy
 Refresh Group Policy
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to manually refresh Group Policy on the local computer. When Group Policy is
refreshed, if certificate autoenrollment is configured and functioning correctly, the local computer is autoenrolled a
certificate by the certification authority (CA).

NOTE
Group Policy is automatically refreshed when you restart the domain member computer, or when a user logs on to a domain
member computer. In addition, Group Policy is periodically refreshed. By default, this periodic refresh is performed every 90
minutes with a randomized offset of up to 30 minutes.

Membership in Administrators , or equivalent, is the minimum required to complete this procedure.

To refresh Group Policy on the local computer
1. On the computer where NPS is installed, open Windows PowerShell® by using the icon on the taskbar.
2. At the Windows PowerShell prompt, type gpupdate , and then press ENTER.
 Verify Server Enrollment of a Server Certificate
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to verify that your Network Policy Server (NPS) servers have enrolled a server
certificate from the certification authority (CA).

NOTE
Membership in the Domain Admins group is the minimum required to complete these procedures.

Verify Network Policy Server (NPS) enrollment of a server certificate

Because NPS is used to authenticate and authorize network connection requests, it is important to ensure that the
server certificate you have issued to NPSs is valid when used in network policies.
To verify that a server certificate is correctly configured and is enrolled to the NPS, you must configure a test
network policy and allow NPS to verify that NPS can use the certificate for authentication.
To verify NPS enrollment of a server certificate
1. In Server Manager, click Tools , and then click Network Policy Ser ver . The Network Policy Server Microsoft
Management Console (MMC) opens.
2. Double-click Policies , right-click Network Policies , and click New . The New Network Policy wizard opens.
3. In Specify Network Policy Name and Connection Type , in Policy name , type Test policy . Ensure that
Type of network access ser ver has the value Unspecified , and then click Next .
4. In Specify Conditions , click Add . In Select condition , click Windows Groups , and then click Add .
5. In Groups , click Add Groups . In Select Group , type Domain Users , and then press ENTER. Click OK , and
then click Next .
6. In Specify Access Permission , ensure that Access granted is selected, and then click Next .
7. In Configure Authentication Methods , click Add . In Add EAP , click Microsoft: Protected EAP (PEAP) ,
and then click OK . In EAP Types , select Microsoft: Protected EAP (PEAP) , and then click Edit . The Edit
Protected EAP Proper ties dialog box opens.
8. In the Edit Protected EAP Proper ties dialog box, in Cer tificate issued to , NPS displays the name of
your server certificate in the format ComputerName.Domain. For example, if your NPS is named NPS-01
and your domain is example.com, NPS displays the certificate NPS-01.example.com . In addition, in Issuer ,
the name of your certification authority is displayed, and in Expiration date , the date of expiration of the
server certificate is shown. This demonstrates that your NPS has enrolled a valid server certificate that it can
use to prove its identity to client computers that are trying to access the network through your network
access servers, such as virtual private network (VPN) servers, 802.1X-capable wireless access points, Remote
Desktop Gateway servers, and 802.1X-capable Ethernet switches.
 IMPORTANT
If NPS does not display a valid server certificate and if it provides the message that such a certificate cannot be found
on the local computer, there are two possible reasons for this problem. It is possible that Group Policy did not refresh
properly, and the NPS has not enrolled a certificate from the CA. In this circumstance, restart the NPS. When the
computer restarts, Group Policy is refreshed, and you can perform this procedure again to verify that the server
certificate is enrolled. If refreshing Group Policy does not resolve this issue, either the certificate template, certificate
autoenrollment, or both are not configured correctly. To resolve these issues, start at the beginning of this guide and
perform all steps again to ensure that the settings that you have provided are accurate.

9. When you have verified the presence of a valid server certificate, you can click OK and Cancel to exit the
New Network Policy wizard.

NOTE
Because you are not completing the wizard, the test network policy is not created in NPS.
 Deploy Password-Based 802.1X Authenticated
Wireless Access
3/26/2020 • 21 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This is a companion guide to the Windows Server® 2016 Core Network Guide. The Core Network Guide provides
instructions for planning and deploying the components required for a fully functioning network and a new Active
Directory® domain in a new forest.
This guide explains how to build upon a core network by providing instructions about how to deploy Institute of
Electrical and Electronics Engineers (IEEE) 802.1X-authenticated IEEE 802.11 wireless access using Protected
Extensible Authentication Protocol – Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-
CHAP v2).
Because PEAP-MS-CHAP v2 requires that users provide password-based credentials rather than a certificate during
the authentication process, it is typically easier and less expensive to deploy than EAP-TLS or PEAP-TLS.

NOTE
In this guide, IEEE 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2 is abbreviated to “wireless access” and “WiFi
access.”

About this guide

This guide, in combination with the prerequisite guides described below, provides instructions about how to deploy
the following WiFi access infrastructure.
One or more 802.1X-capable 802.11 wireless access points (APs).
Active Directory Domain Services (AD DS) Users and Computers.
Group Policy Management.
One or more Network Policy Server (NPS) servers.
Server certificates for computers running NPS.
Wireless client computers running Windows® 10, Windows 8.1, or Windows 8.
Dependencies for this guide
To successfully deploy authenticated wireless with this guide, you must have a network and domain environment
with all of the required technologies deployed. You must also have server certificates deployed to your
authenticating NPSs.
The following sections provide links to documentation that shows you how to deploy these technologies.
Network and domain environment dependencies
This guide is designed for network and system administrators who have followed the instructions in the Windows
Server 2016 Core Network Guide to deploy a core network, or for those who have previously deployed the core
technologies included in the core network, including AD DS, Domain Name System (DNS), Dynamic Host
Configuration Protocol (DHCP), TCP/IP, NPS, and Windows Internet Name Service (WINS).
The Core Network Guide is available at the following locations:
The Windows Server 2016 Core Network Guide is available in the Windows Server 2016 Technical Library.
The Core Network Guide is also available in Word format at TechNet Gallery, at
https://gallery.technet.microsoft.com/Core-Network-Guide-for-9da2e683.
Server certificate dependencies
There are two available options for enrolling authentication servers with server certificates for use with 802.1X
authentication - deploy your own public key infrastructure by using Active Directory Certificate Services (AD CS) or
use server certificates that are enrolled by a public certification authority (CA).
A D CS

Network and system administrators deploying authenticated wireless must follow the instructions in the Windows
Server 2016 Core Network Companion Guide, Deploy Ser ver Cer tificates for 802.1X Wired and Wireless
Deployments . This guide explains how to deploy and use AD CS to autoenroll server certificates to computers
running NPS.
This guide is available at the following location.
The Windows Server 2016 Core Network Companion Guide Deploy Server Certificates for 802.1X Wired and
Wireless Deployments in HTML format in the Technical Library.
Public CA

You can purchase server certificates from a public CA, such as VeriSign, that client computers already trust.
A client computer trusts a CA when the CA certificate is installed in the Trusted Root Certification Authorities
certificate store. By default, computers running Windows have multiple public CA certificates installed in their
Trusted Root Certification Authorities certificate store.
It is recommended that you review the design and deployment guides for each of the technologies that are used in
this deployment scenario. These guides can help you determine whether this deployment scenario provides the
services and configuration that you need for your organization's network.
Requirements
Following are the requirements for deploying a wireless access infrastructure by using the scenario documented in
this guide:
Before deploying this scenario, you must first purchase 802.1X-capable wireless access points to provide
wireless coverage in the desired locations at your site. The planning section of this guide assists in
determining the features your APs must support.
Active Directory Domain Services (AD DS) is installed, as are the other required network technologies,
according to the instructions in the Windows Server 2016 Core Network Guide.
AD CS is deployed, and server certificates are enrolled to NPSs. These certificates are required when you
deploy the PEAP-MS-CHAP v2 certificate-based authentication method that is used in this guide.
A member of your organization is familiar with the IEEE 802.11 standards that are supported by your
wireless APs and the wireless network adapters that are installed in the client computers and devices on
your network. For example, someone in your organization is familiar with radio frequency types, 802.11
wireless authentication (WPA2 or WPA), and ciphers (AES or TKIP).

What this guide does not provide

Following are some items this guide does not provide:
Comprehensive guidance for selecting 802.1X -capable wireless access points
Because many differences exist between brands and models of 802.1X-capable wireless APs, this guide does not
provide detailed information about:
Determining which brand or model of wireless AP is best suited to your needs.
The physical deployment of wireless APs on your network.
Advanced wireless AP configuration, such as for wireless virtual Local Area Networks (VLANs).
Instructions on how to configure wireless AP vendor-specific attributes in NPS.
Additionally, terminology and names for settings vary between wireless AP brands and models, and might not
match the generic setting names that are used in this guide. For wireless AP configuration details, you must review
the product documentation provided by the manufacturer of your wireless APs.
Instructions for deploying NPS certificates
There are two alternatives for deploying NPS certificates. This guide does not provide comprehensive guidance to
help you determine which alternative will best meet your needs. In general, however, the choices you face are:
Purchasing certificates from a public CA, such as VeriSign, that are already trusted by Windows-based
clients. This option is typically recommended for smaller networks.
Deploying a Public Key Infrastructure (PKI) on your network by using AD CS. This is recommended for most
networks, and the instructions for how to deploy server certificates with AD CS are available in the
previously mentioned deployment guide.
NPS network policies and other NPS settings
Except for the configuration settings made when you run the Configure 802.1X wizard, as documented in this
guide, this guide does not provide detailed information for manually configuring NPS conditions, constraints or
other NPS settings.
DHCP
This deployment guide does not provide information about designing or deploying DHCP subnets for wireless
LANs.

Technology overviews
Following are technology overviews for deploying wireless access:
IEEE 802.1X
The IEEE 802.1X standard defines the port-based network access control that is used to provide authenticated
network access to Ethernet networks. This port-based network access control uses the physical characteristics of the
switched LAN infrastructure to authenticate devices attached to a LAN port. Access to the port can be denied if the
authentication process fails. Although this standard was designed for wired Ethernet networks, it has been adapted
for use on 802.11 wireless LANs.
802.1X -capable wireless access points (APs)
This scenario requires the deployment of one or more 802.1X-capable wireless APs that are compatible with the
Remote Authentication Dial-In User Service (RADIUS) protocol.
802.1X and RADIUS-compliant APs, when deployed in a RADIUS infrastructure with a RADIUS server such as an
NPS, are called RADIUS clients.
Wireless clients
This guide provides comprehensive configuration details to supply 802.1X authenticated access for domain-
member users who connect to the network with wireless client computers running Windows 10, Windows 8.1, and
Windows 8. Computers must be joined to the domain in order to successfully establish authenticated access.
 NOTE
You can also use computers that are running Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012 as
wireless clients.

Support for IEEE 802.11 Standards

Supported Windows and Windows Server operating systems provide built-in support for 802.11 wireless
networking. In these operating systems, an installed 802.11 wireless network adapter appears as a wireless
network connection in Network and Sharing Center.
Although there is built-in support for 802.11 wireless networking, the wireless components of Windows are
dependent upon the following:
The capabilities of the wireless network adapter. The installed wireless network adapter must support the
wireless LAN or wireless security standards that you require. For example, if the wireless network adapter
does not support Wi-Fi Protected Access (WPA), you cannot enable or configure WPA security options.
The capabilities of the wireless network adapter driver. To allow you to configure wireless network options,
the driver for the wireless network adapter must support the reporting of all of its capabilities to Windows.
Verify that the driver for your wireless network adapter is written for the capabilities of your operating
system. Also ensure that the driver is the most current version by checking Microsoft Update or the Web site
of the wireless network adapter vendor.
The following table shows the transmission rates and frequencies for common IEEE 802.11 wireless standards.

STA N DA RDS F REQ UEN C IES B IT T RA N SM ISSIO N RAT ES USA GE

802.11 S-Band Industrial, Scientific, 2 megabits per second Obsolete. Not commonly
and Medical (ISM) frequency (Mbps) used.
range (2.4 to 2.5 GHz)

802.11b S-Band ISM 11 Mbps Commonly used.

802.11a C-Band ISM (5.725 to 5.875 54 Mbps Not commonly used due to
GHz) expense and limited range.

802.11g S-Band ISM 54 Mbps Widely used. 802.11g

devices are compatible with
802.11b devices.

802.11n \2.4 and 5.0 GHz C-Band and S-Band ISM 250 Mbps Devices based on the pre-
ratification IEEE 802.11n
standard became available in
August 2007. Many 802.11n
devices are compatible with
802.11a, b, and g devices.

802.11ac 5 GHz 6.93 Gbps 802.11ac, approved by the

IEEE in 2014, is more
scalable and faster than
802.11n, and is deployed
where APs and wireless
clients both support it.

Wireless network security methods

Wireless network security methods is an informal grouping of wireless authentication (sometimes referred to
as wireless security) and wireless security encryption. Wireless authentication and encryption are used in pairs to
prevent unauthorized users from accessing the wireless network, and to protect wireless transmissions.
When configuring wireless security settings in the Wireless Network Policies of Group Policy, there are multiple
combinations to choose from. However, only the WPA2-Enterprise, WPA-Enterprise, and Open with 802.1X
authentication standards are supported for 802.1X Authenticated wireless deployments.

NOTE
While configuring Wireless Network Policies, you must select WPA2-Enterprise , WPA-Enterprise , or Open with 802.1X
in order to gain access to the EAP settings that are required for 802.1X authenticated wireless deployments.

Wireless authentication
This guide recommends the use of the following wireless authentication standards for 802.1X authenticated
wireless deployments.
Wi-Fi Protected Access – Enterprise (WPA-Enterprise) WPA is an interim standard developed by the WiFi
Alliance to comply with the 802.11 wireless security protocol. The WPA protocol was developed in response to a
number of severe flaws that were discovered in the preceding Wired Equivalent Privacy (WEP) protocol.
WPA-Enterprise provides improved security over WEP by:
1. Requiring authentication that uses the 802.1X EAP framework as part of the infrastructure that ensures
centralized mutual authentication and dynamic key management
2. Enhancing the Integrity Check Value (ICV) with a Message Integrity Check (MIC), to protect the header and
payload
3. Implementing a frame counter to discourage replay attacks
Wi-Fi Protected Access 2 – Enterprise (WPA2-Enterprise) Like the WPA-Enterprise standard, WPA2-
Enterprise uses the 802.1X and EAP framework. WPA2-Enterprise provides stronger data protection for multiple
users and large managed networks. WPA2-Enterprise is a robust protocol that is designed to prevent unauthorized
network access by verifying network users through an authentication server.
Wireless security encryption
Wireless security encryption is used to protect the wireless transmissions that are sent between the wireless client
and the wireless AP. Wireless security encryption is used in conjunction with the selected network security
authentication method. By default, computers running Windows 10, Windows 8.1, and Windows 8 support two
encryption standards:
1. Temporal Key Integrity Protocol (TKIP) is an older encryption protocol that was originally designed to
provide more secure wireless encryption than what was provided by the inherently weak Wired Equivalent
Privacy (WEP) protocol. TKIP was designed by the IEEE 802.11i task group and the Wi-Fi Alliance to replace
WEP without requiring the replacement of legacy hardware. TKIP is a suite of algorithms that encapsulates
the WEP payload, and allows users of legacy WiFi equipment to upgrade to TKIP without replacing hardware.
Like WEP, TKIP uses the RC4 stream encryption algorithm as its basis. The new protocol, however, encrypts
each data packet with a unique encryption key, and the keys are much stronger than those by WEP. Although
TKIP is useful for upgrading security on older devices that were designed to use only WEP, it does not
address all of the security issues facing wireless LANs, and in most cases is not sufficiently robust to protect
sensitive government or corporate data transmissions.
2. Advanced Encr yption Standard (AES) is the preferred encryption protocol for the encryption of
commercial and government data. AES offers a higher level of wireless transmission security than either
TKIP or WEP. Unlike TKIP and WEP, AES requires wireless hardware that supports the AES standard. AES is a
symmetric-key encryption standard that uses three block ciphers, AES-128, AES-192 and AES-256.
In Windows Server 2016, the following AES-based wireless encryption methods are available for configuration in
wireless profile properties when you select an authentication method of WPA2-Enterprise, which is recommended.
1. AES-CCMP . Counter Mode Cipher Block Chaining Message Authentication Code Protocol (CCMP) implements
the 802.11i standard and is designed for higher security encryption than that provided by WEP, and uses 128 bit
AES encryption keys.
2. AES-GCMP . Galois Counter Mode Protocol (GCMP) is supported by 802.11ac, is more efficient than AES-CCMP
and provides better performance for wireless clients. GCMP uses 256 bit AES encryption keys.

IMPORTANT
Wired Equivalency Privacy (WEP) was the original wireless security standard that was used to encrypt network traffic. You
should not deploy WEP on your network because there are well-known vulnerabilities in this outdated form of security.

Active Directory Doman Services (AD DS )

AD DS provides a distributed database that stores and manages information about network resources and
application-specific data from directory-enabled applications. Administrators can use AD DS to organize elements
of a network, such as users, computers, and other devices, into a hierarchical containment structure. The
hierarchical containment structure includes the Active Directory forest, domains in the forest, and organizational
units (OUs) in each domain. A server that is running AD DS is called a domain controller.
AD DS contains the user accounts, computer accounts, and account properties that are required by IEEE 802.1X and
PEAP-MS-CHAP v2 to authenticate user credentials and to evaluate authorization for wireless connections.
Active Directory Users and Computers
Active Directory Users and Computers is a component of AD DS that contains accounts that represent physical
entities, such as a computer, a person, or a security group. A security group is a collection of user or computer
accounts that administrators can manage as a single unit. User and computer accounts that belong to a particular
group are referred to as group members.
Group Policy Management
Group Policy Management enables directory-based change and configuration management of user and computer
settings, including security and user information. You use Group Policy to define configurations for groups of users
and computers. With Group Policy, you can specify settings for registry entries, security, software installation,
scripts, folder redirection, remote installation services, and Internet Explorer maintenance. The Group Policy settings
that you create are contained in a Group Policy object (GPO). By associating a GPO with selected Active Directory
system containers — sites, domains, and OUs — you can apply the GPO's settings to the users and computers in
those Active Directory containers. To manage Group Policy objects across an enterprise, you can use the Group
Policy Management Editor Microsoft Management Console (MMC).
This guide provides detailed instructions about how to specify settings in the Wireless Network (IEEE 802.11)
Policies extension of Group Policy Management. The Wireless Network (IEEE 802.11) Policies configure domain-
member wireless client computers with the necessary connectivity and wireless settings for 802.1X authenticated
wireless access.
Server certificates
This deployment scenario requires server certificates for each NPS that performs 802.1X authentication.
A server certificate is a digital document that is commonly used for authentication and to secure information on
open networks. A certificate securely binds a public key to the entity that holds the corresponding private key.
Certificates are digitally signed by the issuing CA, and they can be issued for a user, a computer, or a service.
A certification authority (CA) is an entity responsible for establishing and vouching for the authenticity of public
keys belonging to subjects (usually users or computers) or other CAs. Activities of a certification authority can
include binding public keys to distinguished names through signed certificates, managing certificate serial
numbers, and revoking certificates.
Active Directory Certificate Services (AD CS) is a server role that issues certificates as a network CA. An AD CS
certificate infrastructure, also known as a public key infrastructure (PKI), provides customizable services for issuing
and managing certificates for the enterprise.
EAP, PEAP, and PEAP-MS -CHAP v2
Extensible Authentication Protocol (EAP) extends Point-to-Point Protocol (PPP) by allowing additional authentication
methods that use credential and information exchanges of arbitrary lengths. With EAP authentication, both the
network access client and the authenticator (such as the NPS) must support the same EAP type for successful
authentication to occur. Windows Server 2016 includes an EAP infrastructure, supports two EAP types, and the
ability to pass EAP messages to NPSs. By using EAP, you can support additional authentication schemes, known as
EAP types. The EAP types that are supported by Windows Server 2016 are:
Transport Layer Security (TLS)
Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2)

IMPORTANT
Strong EAP types (such as those that are based on certificates) offer better security against brute-force attacks, dictionary
attacks, and password guessing attacks than password-based authentication protocols (such as CHAP or MS-CHAP version
1).

Protected EAP (PEAP) uses TLS to create an encrypted channel between an authenticating PEAP client, such as a
wireless computer, and a PEAP authenticator, such as an NPS or other RADIUS servers. PEAP does not specify an
authentication method, but it provides additional security for other EAP authentication protocols (such as EAP-MS-
CHAP v2) that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication
method for access clients that are connecting to your organization's network through the following types of
network access servers (NASs):
802.1X-capable wireless access points
802.1X-capable authenticating switches
Computers running Windows Server 2016 and the Remote Access Service (RAS) that are configured as
virtual private network (VPN) servers, DirectAccess Servers, or both
Computers running Windows Server 2016 and Remote Desktop Services
PEAP-MS-CHAP v2 is easier to deploy than EAP-TLS because user authentication is performed by using password-
based credentials (user name and password), instead of certificates or smart cards. Only NPS or other RADIUS
servers are required to have a certificate. The NPS certificate is used by the NPS during the authentication process
to prove its identity to PEAP clients.
This guide provides instructions to configure your wireless clients and your NPS(s) to use PEAP-MS-CHAP v2 for
802.1X authenticated access.
Network Policy Server
Network Policy Server (NPS) allows you to centrally configure and manage network policies by using Remote
Authentication Dial-In User Service (RADIUS) server and RADIUS proxy. NPS is required when you deploy 802.1X
wireless access.
When you configure your 802.1X wireless access points as RADIUS clients in NPS, NPS processes the connection
requests sent by the APs. During connection request processing, NPS performs authentication and authorization.
Authentication determines whether the client has presented valid credentials. If NPS successfully authenticates the
requesting client, then NPS determines whether the client is authorized to make the requested connection, and
either allows or denies the connection. This is explained in more detail as follows:
Authentication
Successful mutual PEAP-MS-CHAP v2 authentication has two main parts:
1. The client authenticates the NPS. During this phase of mutual authentication, the NPS sends its server
certificate to the client computer so that the client can verify the NPS's identity with the certificate. To
successfully authenticate the NPS, the client computer must trust the CA that issued the NPS certificate. The
client trusts this CA when the CA's certificate is present in the Trusted Root Certification Authorities
certificate store on the client computer.
If you deploy your own private CA, the CA certificate is automatically installed in the Trusted Root
Certification Authorities certificate store for the Current User and for the Local Computer when Group Policy
is refreshed on the domain member client computer. If you decide to deploy server certificates from a public
CA, ensure that the public CA certificate is already in the Trusted Root Certification Authorities certificate
store.
2. The NPS authenticates the user. After the client successfully authenticates the NPS, the client sends the user's
password-based credentials to the NPS, which verifies the user's credentials against the user accounts
database in Active Directory Doman Services (AD DS).
If the credentials are valid and authentication succeeds, the NPS begins the authorization phase of processing the
connection request. If the credentials are not valid and authentication fails, NPS sends an Access Reject message
and the connection request is denied.
Authorization
The server running NPS performs authorization as follows:
1. NPS checks for restrictions in the user or computer account dial-in properties in AD DS. Every user and
computer account in Active Directory Users and Computers includes multiple properties, including those
found on the Dial-in tab. On this tab, in Network Access Permission , if the value is Allow access , the
user or computer is authorized to connect to the network. If the value is Deny access , the user or computer
is not authorized to connect to the network. If the value is Control access through NPS Network Policy ,
NPS evaluates the configured network policies to determine whether the user or computer is authorized to
connect to the network.
2. NPS then processes its network policies to find a policy that matches the connection request. If a matching
policy is found, NPS either grants or denies the connection based on that policy's configuration.
If both authentication and authorization are successful, and if the matching network policy grants access, NPS
grants access to the network, and the user and computer can connect to network resources for which they have
permissions.

NOTE
To deploy wireless access, you must configure NPS policies. This guide provides instructions to use the Configure 802.1X
wizard in NPS to create NPS policies for 802.1X authenticated wireless access.

Bootstrap profiles
In 802.1X-authenticated wireless networks, wireless clients must provide security credentials that are authenticated
by a RADIUS server in order to connect to the network. For Protected EAP [PEAP]-Microsoft Challenge Handshake
Authentication Protocol version 2 [MS-CHAP v2], the security credentials are a user name and password. For EAP-
Transport Layer Security [TLS] or PEAP-TLS, the security credentials are certificates, such as client user and
computer certificates or smart cards.
When connecting to a network that is configured to perform PEAP-MS-CHAP v2, PEAP-TLS, or EAP-TLS
authentication, by default, Windows wireless clients must also validate a computer certificate that is sent by the
RADIUS server. The computer certificate that is sent by the RADIUS server for every authentication session is
commonly referred to as a server certificate.
As mentioned previously, you can issue your RADIUS servers their server certificate in one of two ways: from a
commercial CA (such as VeriSign, Inc.,), or from a private CA that you deploy on your network. If the RADIUS server
sends a computer certificate that was issued by a commercial CA that already has a root certificate installed in the
client's Trusted Root Certification Authorities certificate store, then the wireless client can validate the RADIUS
server's computer certificate, regardless of whether the wireless client has joined the Active Directory domain. In
this case the wireless client can connect to the wireless network, and then you can join the computer to the domain.

NOTE
The behavior requiring the client to validate the server certificate can be disabled, but disabling server certificate validation is
not recommended in production environments.

Wireless bootstrap profiles are temporary profiles that are configured in such a way as to enable wireless client
users to connect to the 802.1X-authenticated wireless network before the computer is joined to the domain, and/or
before the user has successfully logged on to the domain by using a given wireless computer for the first time. This
section summarizes what problem is encountered when trying to join a wireless computer to the domain, or for a
user to use a domain-joined wireless computer for the first time to log on to the domain.
For deployments in which the user or IT administrator cannot physically connect a computer to the wired Ethernet
network to join the computer to the domain, and the computer does not have the necessary issuing root CA
certificate installed in its Trusted Root Cer tification Authorities certificate store, you can configure wireless
clients with a temporary wireless connection profile, called a bootstrap profile, to connect to the wireless network.
A bootstrap profile removes the requirement to validate the RADIUS server's computer certificate. This temporary
configuration enables the wireless user to join the computer to the domain, at which time the Wireless Network
(IEEE 802.11) Policies are applied and the appropriate root CA certificate is automatically installed on the computer.
When Group Policy is applied, one or more wireless connection profiles that enforce the requirement for mutual
authentication are applied on the computer; the bootstrap profile is no longer required and is removed. After
joining the computer to the domain and restarting the computer, the user can use a wireless connection to log on
to the domain.
For an overview of the wireless access deployment process using these technologies, see Wireless Access
Deployment Overview.
 Wireless Access Deployment Overview
3/26/2020 • 4 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

The following illustration shows the components that are required to deploy 802.1X authenticated wireless access
with PEAP-MS-CHAP v2.

Wireless access deployment components

The following infrastructure is required for this wireless access deployment:
802.1X -capable Wireless access points
After the required network infrastructure services supporting your wireless local area network are in place, you can
begin the design process for the location of the wireless APs. The wireless AP deployment design process involves
these steps:
Identify the areas of coverage for wireless users. While identifying the areas of coverage, be sure to identify
whether you want to provide wireless service outside the building, and if so, determine specifically where
those external areas are.
Determine how many wireless APs to deploy to ensure adequate coverage.
Determine where to place wireless APs.
 Select the channel frequencies for wireless APs.
Active Directory Domain Services
The following elements of AD DS are required for wireless access deployment.
Users and Computers
Use the Active Directory Users and Computers snap-in to create and manage user accounts, and to create a
wireless security group that includes each domain member to whom you want to grant wireless access.
Wireless Network (IEEE 802.11) Policies
You can use the Wireless Network (IEEE 802.11) Policies extension of Group Policy Management to configure
policies that are applied to wireless computers when they attempt to access the network.
In Group Policy Management Editor, when you right-click Wireless Network (IEEE 802.11) Policies , you have
the following two options for the type of wireless policy that you create.
Create a New Wireless Network Policy for Windows Vista and Later Releases
Create a New Windows XP Policy

TIP
When configuring a new wireless network policy, you have the option to change the name and description of the policy. If
you change the name of the policy, the change is reflected in the Details pane of Group Policy Management Editor and on
the title bar of the wireless network policy dialog box. Regardless of how you rename your policies, the New XP Wireless
Policy will always be listed in Group Policy Management Editor with the Type displaying XP . Other policies are listed with the
Type showing Vista and Later Releases .

The Wireless Network Policy for Windows Vista and Later Releases enables you to configure, prioritize, and
manage multiple wireless profiles. A wireless profile is a collection of connectivity and security settings that are
used to connect to a specific wireless network. When Group Policy is updated on your wireless client computers,
the profiles you create in the Wireless Network Policy are automatically added to the configuration on your
wireless client computers to which the Wireless Network Policy applies.
A l l o w i n g c o n n e c t i o n s t o m u l t i p l e w i r e l e ss n e t w o r k s

If you have wireless clients that are moved across physical locations in your organization, such as between a main
office and a branch office, you might want computers to connect to more than one wireless network. In this
situation, you can configure a wireless profile that contains the specific connectivity and security settings for each
network.
For example, assume your company has one wireless network for the main corporate office, with a service set
identifier (SSID) WlanCorp.
Your branch office also has a wireless network to which you also want to connect. The branch office has the SSID
configured as WlanBranch.
In this scenario, you can configure a profile for each network, and computers or other devices that are used at both
the corporate office and branch office can connect to either of the wireless networks when they are physically in
range of a network's coverage area.
M i x e d - m o d e w i r e l e ss n e t w o r k s

Alternately, assume your network has a mixture of wireless computers and devices that support different security
standards. Perhaps some older computers have wireless adapters that can only use WPA-Enterprise, while newer
devices can use the stronger WPA2-Enterprise standard.
You can create two different profiles that use the same SSID and nearly identical connectivity and security settings.
In one profile, you can set the wireless authentication to WPA2-Enterprise with AES, and in the other profile you can
specify WPA-Enterprise with TKIP.
This is commonly known as a mixed-mode deployment, and it allows computers of different types and wireless
capabilities to share the same wireless network.
Network Policy Server (NPS )
NPS enables you to create and enforce network access policies for connection request authentication and
authorization.
When you use NPS as a RADIUS server, you configure network access servers, such as wireless access points, as
RADIUS clients in NPS. You also configure the network policies that NPS uses to authenticate access clients and
authorize their connection requests.
Wireless client computers
For the purpose of this guide, wireless client computers are computers and other devices that are equipped with
IEEE 802.11 wireless network adapters and that are running Windows client or Windows Server operating systems.
Server computers as wireless clients
By default, the functionality for 802.11 wireless is disabled on computers that are running Windows Server.
To enable wireless connectivity on computers running server operating systems, you must install and enable the
Wireless LAN (WLAN) Service feature by using either Windows PowerShell or the Add Roles and Features Wizard
in Server Manager.
When you install the Wireless L AN Ser vice feature, the new service WL AN AutoConfig is installed in
Ser vices . When installation is complete, you must restart the server.
After the server is restarted, you can access WLAN AutoConfig when you click Star t , Windows Administrative
Tools , and Ser vices .
After install and server restart, the WLAN AutoConfig service is in a stopped state with a startup type of
Automatic . To start the service, double-click WL AN AutoConfig . On the General tab, click Star t , and then click
OK .
The WLAN AutoConfig service enumerates wireless adapters and manages both wireless connections and the
wireless profiles that contain settings that are required to configure the server to connect to a wireless network.
For an overview of wireless access deployment, see Wireless Access Deployment Process.
 Wireless Access Deployment Process
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

The process that you use to deploy wireless access occurs in these stages:

Stage 1 – AP Deployment
Plan, deploy, and configure your APs for wireless client connectivity and for use with NPS. Depending on your
preference and network dependencies, you can either pre-configure settings on your wireless APs prior to
installing them on your network, or you can configure them remotely after installation.

Stage 2 – AD DS Group Configuration

In AD DS, you must create one or more wireless users security groups.
Next, identify the users who are allowed wireless access to the network.
Finally, add the users to the appropriate wireless users security groups that you created.

NOTE
By default, the Network Access Permission setting in user account dial-in properties is configured with the setting
Control access through NPS Network Policy . Unless you have specific reasons to change this setting, it is
recommended that you keep the default. This allows you to control network access through the network policies that you
configure in NPS.

Stage 3 – Group Policy Configuration

Configure the Wireless Network (IEEE 802.11) Policies extension of Group Policy by using the Group Policy
Management Editor Microsoft Management Console (MMC).
To configure domain-member computers using the settings in the wireless network policies, you must apply Group
Policy. When a computer is first joined to the domain, Group Policy is automatically applied. If changes are made to
Group Policy, the new settings are automatically applied:
By Group Policy at pre-determined intervals
If a domain user logs off and then back on to the network
By restarting the client computer and logging on to the domain
You can also force Group Policy to refresh while logged on to a computer by running the command gpupdate at
the command prompt.

Stage 4 – NPS configuration

Use a configuration wizard in NPS to add wireless access points as RADIUS clients, and to create the network
policies that NPS uses when processing connection requests.
When using the wizard to create the network policies, specify PEAP as the EAP type, and the wireless users security
group that was created in the second stage.

Stage 5 – Deploy wireless clients

Use client computers to connect to the network.
For domain member computers that can log on to the wired LAN, the necessary wireless configuration settings are
automatically applied when Group Policy is refreshed.
If you have enabled the setting in Wireless Network (IEEE 802.11) Policies to connect automatically when the
computer is within broadcast range of the wireless network, your wireless, domain-joined computers will then
automatically attempt to connect to the wireless LAN.
To connect to the wireless network, users need only supply their domain user name and password credentials
when prompted by Windows.
To plan your wireless access deployment, see Wireless Access Deployment Planning.
 Wireless Access Deployment Planning
3/26/2020 • 15 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Before you deploy wireless access, you must plan the following items:
Installation of wireless access points (APs) on your network
Wireless client configuration and access
The following sections provide details on these planning steps.

Planning wireless AP installations

When you design your wireless network access solution, you must do the following:
1. Determine what standards your wireless APs must support
2. Determine the coverage areas where you want to provide wireless service
3. Determine where you want to locate wireless APs
Additionally, you must plan an IP address scheme for your wireless AP's and wireless clients. See the section Plan
the configuration of wireless AP's in NPS below for related information.
Verify wireless AP support for standards
For the purposes of consistency and ease of deployment and AP management, it is recommended that you deploy
wireless APs of the same brand and model.
The wireless APs that you deploy must support the following:
IEEE 802.1X
RADIUS authentication
Wireless Authentication and Cipher. Listed in order of most to least preferred:
1. WPA2-Enterprise with AES
2. WPA2-Enterprise with TKIP
3. WPA-Enterprise with AES
4. WPA-Enterprise with TKIP

NOTE
To deploy WPA2, you must use wireless network adapters and wireless APs that also support WPA2. Otherwise, use WPA-
Enterprise.

In addition, to provide enhanced security for the network, the wireless APs must support the following security
options:
DHCP filtering. The wireless AP must filter on IP ports to prevent the transmission of DHCP broadcast
messages in those cases in which the wireless client is configured as a DHCP server. The wireless AP must
 block the client from sending IP packets from UDP port 68 to the network.
DNS filtering. The wireless AP must filter on IP ports to prevent a client from performing as a DNS server.
The wireless AP must block the client from sending IP packets from TCP or UDP port 53 to the network.
Client isolation If your wireless access point provides client isolation capabilities, you should enable the
feature to prevent possible Address Resolution Protocol (ARP) spoofing exploits.
Identify areas of coverage for wireless users
Use architectural drawings of each floor for each building to identify the areas where you want to provide wireless
coverage. For example, identify the appropriate offices, conferences rooms, lobbies, cafeterias, or courtyards.
On the drawings, indicate any devices that interfere with the wireless signals, such as medical equipment, wireless
video cameras, cordless telephones that operate in the 2.4 through 2.5 GHz Industrial, Scientific and Medical (ISM)
range, and Bluetooth-enabled devices.
On the drawing, mark aspects of the building that might interfere with wireless signals; metal objects used in the
construction of a building can affect the wireless signal. For example, the following common objects can interfere
with signal propagation: Elevators, heating and air-conditioning ducts, and concrete support girders.
Refer to your AP manufacturer for information about sources that might cause wireless AP radio frequency
attenuation. Most APs provide testing software that you can use to check for signal strength, error rate, and data
throughput.
Determine where to install wireless APs
On the architectural drawings, locate your wireless APs close enough together to provide ample wireless coverage
but far enough apart that they do not interfere with each other.
The necessary distance between APs depends upon the type of AP and AP antenna, aspects of the building that
block wireless signals, and other sources of interference. You can mark wireless AP placements so that each
wireless AP is not more than 300 feet from any adjacent wireless AP. See the wireless AP manufacturer's
documentation for AP specifications and guidelines for placement.
Temporarily install wireless APs in the locations specified on your architectural drawings. Then, using a laptop
equipped with an 802.11 wireless adapter and the site survey software that is commonly supplied with wireless
adapters, determine the signal strength within each coverage area.
In coverage areas where signal strength is low, position the AP to improve signal strength for the coverage area,
install additional wireless APs to provide the necessary coverage, relocate or remove sources of signal interference.
Update your architectural drawings to indicate the final placement of all wireless APs. Having an accurate AP
placement map will assist later during troubleshooting operations or when you want to upgrade or replace APs.
Plan wireless AP and NPS RADIUS Client configuration
You can use NPS to configure wireless APs individually or in groups.
If you are deploying a large wireless network that includes many APs, it is much easier to configure APs in groups.
To add the APs as RADIUS client groups in NPS, you must configure the APs with these properties.
The wireless APs are configured with IP addresses from the same IP address range.
The wireless APs are all configured with the same shared secret.
Plan the use of PEAP Fast Reconnect
In an 802.1X infrastructure, wireless access points are configured as RADIUS clients to RADIUS servers. When PEAP
fast reconnect is deployed, a wireless client that roams between two or more access points is not required to be
authenticated with each new association.
PEAP fast reconnect reduces the response time for authentication between client and authenticator because the
authentication request is forwarded from the new access point to the NPS that originally performed authentication
and authorization for the client connection request.
Because both the PEAP client and NPS both use previously cached Transport Layer Security (TLS) connection
properties (the collection of which is named the TLS handle), the NPS can quickly determine that the client is
authorized for a reconnect.

IMPORTANT
For fast reconnect to function correctly, the APs must be configured as RADIUS clients of the same NPS.

If the original NPS becomes unavailable, or if the client moves to an access point that is configured as a RADIUS
client to a different RADIUS server, full authentication must occur between the client and the new authenticator.
Wireless AP configuration
The following list summarizes items commonly configured on 802.1X-capable wireless APs:

NOTE
The item names can vary by brand and model and might be different from those in the following list. See your wireless AP
documentation for configuration-specific details.

Ser vice set identifier (SSID) . This is the name of the wireless network (for example, ExampleWlan), and
the name that is advertised to wireless clients. To reduce confusion, the SSID that you choose to advertise
should not match the SSID that is broadcast by any wireless networks that are within reception range of
your wireless network.
In cases in which multiple wireless APs are deployed as part of the same wireless network, configure each
wireless AP with the same SSID. In cases in which multiple wireless APs are deployed as part of the same
wireless network, configure each wireless AP with the same SSID.
In cases where you have a need to deploy different wireless networks to meet specific business needs, your
wireless AP's on one network should broadcast a different SSID than the SSID your other network(s). For
example, if you need a separate wireless network for your employees and guests, you could configure your
wireless APs for the business network with the SSID set to broadcast ExampleWL AN . For your guest
network, you could then set each wireless AP's SSID to broadcast GuestWL AN . In this way your employees
and guests can connect to the intended network without unnecessary confusion.

TIP
Some wireless AP's have the ability to broadcast multiple SSID's to accommodate multi-network deployments.
Wireless AP's that can broadcast multiple SSID's can reduce deployment and operational maintenance costs.

Wireless authentication and encr yption .

Wireless authentication is the security authentication that is used when the wireless client associates with a
wireless access point.
Wireless encryption is the security encryption cipher that is used with wireless authentication to protect the
communications that are sent between the wireless AP and the wireless client.
Wireless AP IP address (static) . On each wireless AP, configure a unique static IP address. If the subnet is
serviced by a DHCP server, ensure that all AP IP addresses fall within a DHCP exclusion range so that the
DHCP server does not try to issue the same IP address to another computer or device. Exclusion ranges are
documented in the procedure "To create and activate a new DHCP Scope" in the Core Network Guide. If you
 are planning to configure APs as RADIUS clients by group in NPS, each AP in the group must have an IP
address from the same IP address range.
DNS name . Some wireless APs can be configured with a DNS name. Configure each wireless AP with a
unique name. For example, if you have a deployed wireless APs in a multi-story building, you might name
the first three wireless APs that are deployed on the third floor AP3-01, AP3-02, and AP3-03.
Wireless AP subnet mask . Configure the mask to designate which portion of the IP address is the
network ID and which portion of the IP address is the host.
AP DHCP ser vice . If your wireless AP has a built-in DHCP service, disable it.
RADIUS shared secret . Use a unique RADIUS shared secret for each wireless AP unless you are planning
to configure NPS RADIUS clients in groups - in which circumstance you must configure all of the APs in the
group with the same shared secret. Shared secrets should be a random sequence of at least 22 characters
long, with both uppercase and lowercase letters, numbers, and punctuation. To ensure randomness, you can
use a random character generation program to create your shared secrets. It is recommended that you
record the shared secret for each wireless AP and store it in a secure location, such as an office safe. When
you configure RADIUS clients in the NPS console you will create a virtual version of each AP. The shared
secret that you configure on each virtual AP in NPS must match the shared secret on the actual, physical AP.
RADIUS ser ver IP address . Type the IP address of the NPS that you want to use to authenticate and
authorize connection requests to this access point.
UDP por t(s) . By default, NPS uses UDP ports 1812 and 1645 for RADIUS authentication messages and
UDP ports 1813 and 1646 for RADIUS accounting messages. It is recommended that you do not change the
default RADIUS UDP ports settings.
VSAs . Some wireless APs require vendor-specific attributes (VSAs) to provide full wireless AP functionality.
DHCP filtering . Configure wireless APs to block wireless clients from sending IP packets from UDP port 68
to the network. See the documentation for your wireless AP to configure DHCP filtering.
DNS filtering . Configure wireless APs to block wireless clients from sending IP packets from TCP or UDP
port 53 to the network. See the documentation for your wireless AP to configure DNS filtering.

Planning wireless client configuration and access

When planning the deployment of 802.1X-authenticated wireless access, you must consider several client-specific
factors:
Planning suppor t for multiple standards .
Determine whether your wireless computers are all using the same version of Windows or whether they are
a mixture of computers running different operating systems. If they are different, ensure that you
understand any differences in standards supported by the operating systems.
Determine whether all of the wireless network adapters on all of the wireless client computers support the
same wireless standards, or whether you need to support varying standards. For example, determine
whether some network adapter hardware drivers support WPA2-Enterprise and AES, while others support
only WPA-Enterprise and TKIP.
Planning client authentication mode . Authentication modes define how Windows clients process
domain credentials. You can select from the following three network authentication modes in the wireless
network policies.
1. User re-authentication . This mode specifies that authentication is always performed by using
security credentials based on the computer's current state. When no users are logged on to the
 computer, authentication is performed by using the computer credentials. When a user is logged on
to the computer, authentication is always performed by using the user credentials.
2. Computer only . Computer only mode specifies that authentication is always performed by using
only the computer credentials.
3. User authentication . User authentication mode specifies that authentication is only performed
when the user is logged on to the computer. When there are no users logged on to the computer,
authentication attempts are not performed.
Planning wireless restrictions . Determine whether you want to provide all of your wireless users with
the same level of access to your wireless network, or whether you want to restrict access for some of your
wireless users. You can apply restrictions in NPS against specific groups of wireless users. For example, you
can define specific days and hours that certain groups are permitted access to the wireless network.
Planning methods for adding new wireless computers . For wireless-capable computers that are
joined to your domain before you deploy your wireless network, if the computer is connected to a segment
of the wired network that is not protected by 802.1X, the wireless configuration settings are automatically
applied after you configure Wireless Network (IEEE 802.11) Policies on the domain controller and after
Group Policy is refreshed on the wireless client.
For computers that are not already joined to your domain, however, you must plan a method to apply the
settings that are required for 802.1X-authenticated access. For example, determine whether you want to join
the computer to the domain by using one of the following methods.
1. Connect the computer to a segment of the wired network that is not protected by 802.1X, then join
the computer to the domain.
2. Provide your wireless users with the steps and settings that they require to add their own wireless
bootstrap profile, which allows them to join the computer to the domain.
3. Assign IT staff to join wireless clients to the domain.
Planning support for multiple standards
The Wireless Network (IEEE 802.11) Policies extension in Group Policy provides a wide range of configuration
options to support a variety of deployment options.
You can deploy wireless APs that are configured with the standards that you want to support, and then configure
multiple wireless profiles in Wireless Network (IEEE 802.11) Policies, with each profile specifying one set of
standards that you require.
For example, if your network has wireless computers that support WPA2-Enterprise and AES, other computers that
support WPA-Enterprise and AES, and other computers that support only WPA-Enterprise and TKIP, you must
determine whether you want to:
Configure a single profile to support all of the wireless computers by using the weakest encryption method that
all of your computers support - in this case, WPA-Enterprise and TKIP.
Configure two profiles to provide the best possible security that is supported by each wireless computer. In this
instance you would configure one profile that specifies the strongest encryption (WPA2-Enterprise and AES),
and one profile that uses the weaker WPA-Enterprise and TKIP encryption. In this example, it is essential that you
place the profile that uses WPA2-Enterprise and AES highest in the preference order. Computers that are not
capable of using WPA2-Enterprise and AES will automatically skip to the next profile in the preference order and
process the profile that specifies WPA-Enterprise and TKIP.
 IMPORTANT
You must place the profile with the most secure standards higher in the ordered list of profiles, because connecting
computers use the first profile that they are capable of using.

Planning restricted access to the wireless network

In many cases, you might want to provide wireless users with varying levels of access to the wireless network. For
example, you might want to allow some users unrestricted access, any hour of the day, every day of the week. For
other users, you might only want to allow access during core hours, Monday through Friday, and deny access on
Saturday and Sunday.
This guide provides instructions to create an access environment that places all of your wireless users in a group
with common access to wireless resources. You create one wireless users security group in the
Active Directory Users and Computers snap-in, and then make every user for whom you want to grant wireless
access a member of that group.
When you configure NPS network policies, you specify the wireless users security group as the object that NPS
processes when determining authorization.
However, if your deployment requires support for varying levels of access you need only do the following:
1. Create more than one Wireless Users Security Group to create additional wireless security groups in Active
Directory Users and Computers. For example, you can create a group that contains users who have full
access, a group for those who only have access during regular working hours, and other groups that fit
other criteria that match your requirements.
2. Add users to the appropriate security groups that you created.
3. Configure additional NPS network policies for each additional wireless security group, and configure the
policies to apply the conditions and constraints that you require for each group.
Planning methods for adding new wireless computers
The preferred method to join new wireless computers to the domain and then log on to the domain is by using a
wired connection to a segment of the LAN that has access to domain controllers, and is not protected by an 802.1X
authenticating Ethernet switch.
In some cases, however, it might not be practical to use a wired connection to join computers to the domain, or, for
a user to use a wired connection for their first log on attempt by using computers that are already joined to the
domain.
To join a computer to the domain by using a wireless connection or for users to log on to the domain the first time
by using a domain-joined computer and a wireless connection, wireless clients must first establish a connection to
the wireless network on a segment that has access to the network domain controllers by using one of the following
methods.
1. A member of the IT staff joins a wireless computer to the domain, and then configures a Single
Sign On bootstrap wireless profile. With this method, an IT administrator connects the wireless
computer to the wired Ethernet network, and then joins the computer to the domain. Then the administrator
distributes the computer to the user. When the user starts the computer, the domain credentials that they
manually specify for the user logon process are used to both establish a connection to the wireless network
and log on to the domain.
2. The user manually configures wireless computer with bootstrap wireless profile, and then joins
the domain. With this method, users manually configure their wireless computers with a bootstrap
wireless profile based on instructions from an IT administrator. The bootstrap wireless profile allows users to
establish a wireless connection, and then join the computer to the domain. After joining the computer to the
 domain and restarting the computer, the user can log on to the domain by using a wireless connection and
their domain account credentials.
To deploy wireless access, see Wireless Access Deployment.
 Wireless Access Deployment
3/26/2020 • 35 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Follow these steps to deploy wireless access:

Deploy and Configure Wireless APs
Create a Wireless Users Security Group
Configure Wireless Network (IEEE 802.11) Policies
Configure NPSs
Join New Wireless Computers to the Domain

Deploy and Configure Wireless APs

Follow these steps to deploy and configure your wireless APs:
Specify Wireless AP Channel Frequencies
Configure Wireless APs

NOTE
The procedures in this guide do not include instructions for cases in which the User Account Control dialog box opens to
request your permission to continue. If this dialog box opens while you are performing the procedures in this guide, and if
the dialog box was opened in response to your actions, click Continue .

Specify Wireless AP Channel Frequencies

When you deploy multiple wireless APs at a single geographical site, you must configure wireless APs that have
overlapping signals to use unique channel frequencies to reduce interference between wireless APs.
You can use the following guidelines to assist you in choosing channel frequencies that do not conflict with other
wireless networks at the geographical location of your wireless network.
If there are other organizations that have offices in close proximity or in the same building as your
organization, identify whether there are any wireless networks owned by those organizations. Find out both
the placement and the assigned channel frequencies of their wireless AP's, because you need to assign
different channel frequencies to your AP's and you need to determine the best location to install your AP's.
Identify overlapping wireless signals on adjacent floors within your own organization. After identifying
overlapping coverage areas outside and within your organization, assign channel frequencies for your
wireless APs, ensuring that any two wireless APs with overlapping coverage are assigned different channel
frequencies.
Configure Wireless APs
Use the following information along with the product documentation provided by the wireless AP manufacturer to
configure your wireless APs.
This procedure enumerates items commonly configured on a wireless AP. The item names can vary by brand and
model and might be different from those in the following list. For specific details, see your wireless AP
documentation.
To configure your wireless APs
SSID . Specify the name of the wireless network(s) (for example, ExampleWLAN). This is the name that is
advertised to wireless clients.
Encr yption . Specify WPA2-Enterprise (preferred) or WPA-Enterprise, and either AES (preferred) or TKIP
encryption cipher, depending on which versions are supported by your wireless client computer network
adapters.
Wireless AP IP address (static) . On each AP, configure a unique static IP address that falls within the
exclusion range of the DHCP scope for the subnet. Using an address that is excluded from assignment by
DHCP prevents the DHCP server from assigning the same IP address to a computer or other device.
Subnet mask . Configure this to match the subnet mask settings of the LAN to which you have connected
the wireless AP.
DNS name . Some wireless APs can be configured with a DNS name. The DNS service on the network can
resolve DNS names to an IP address. On each wireless AP that supports this feature, enter a unique name
for DNS resolution.
DHCP ser vice . If your wireless AP has a built-in DHCP service, disable it.
RADIUS shared secret . Use a unique RADIUS shared secret for each wireless AP unless you are planning
to configure APs as RADIUS Clients in NPS by group. If you plan to configure APs by group in NPS, the
shared secret must be the same for every member of the group. In addition, each shared secret you use
should be a random sequence of at least 22 characters that mixes uppercase and lowercase letters, numbers,
and punctuation. To ensure randomness, you can use a random character generator, such as the random
character generator found in the NPS Configure 802.1X wizard, to create the shared secrets.

TIP
Record the shared secret for each wireless AP and store it in a secure location, such as an office safe. You must know the
shared secret for each wireless AP when you configure RADIUS clients in the NPS.

RADIUS ser ver IP address . Type the IP address of the server running NPS.
UDP por t(s) . By default, NPS uses UDP ports 1812 and 1645 for authentication messages and UDP ports
1813 and 1646 for accounting messages. It is recommended that you use these same UDP ports on your
APs, but if you have a valid reason to use different ports, ensure that you not only configure the APs with the
new port numbers but also reconfigure all of your NPSs to use the same port numbers as the APs. If the APs
and the NPSs are not configured with the same UDP ports, NPS cannot receive or process connection
requests from the APs, and all wireless connection attempts on the network will fail.
VSAs . Some wireless APs require vendor-specific attributes (VSAs) to provide full wireless AP functionality.
VSAs are added in NPS network policy.
DHCP filtering . Configure wireless APs to block wireless clients from sending IP packets from UDP port 68
to the network, as documented by the wireless AP manufacturer.
DNS filtering . Configure wireless APs to block wireless clients from sending IP packets from TCP or UDP
port 53 to the network, as documented by the wireless AP manufacturer.

Create Security Groups for Wireless Users

Follow these steps to create one or more wireless users security groups, and then add users to the appropriate
wireless users security group:
Create a Wireless Users Security Group
Add Users to the Wireless Security Group
Create a Wireless Users Security Group
You can use this procedure to create a wireless security group in the Active Directory Users and Computers
Microsoft Management Console (MMC) snap-in.
Membership in Domain Admins , or equivalent, is the minimum required to perform this procedure.
To create a wireless users security group
1. Click Star t , click Administrative Tools , and then click Active Director y Users and Computers . The
Active Directory Users and Computers snap-in opens. If it is not already selected, click the node for your
domain. For example, if your domain is example.com, click example.com .
2. In the details pane, right-click the folder in which you want to add a new group (for example, right-click
Users ), point to New , and then click Group .
3. In New Object – Group , in Group name , type the name of the new group. For example, type Wireless
Group .
4. In Group scope , select one of the following options:
Domain local
Global
Universal
5. In Group type , select Security .
6. Click OK .
If you need more than one security group for wireless users, repeat these steps to create additional wireless users
groups. Later you can create individual network policies in NPS to apply different conditions and constraints to
each group, providing them with different access permissions and connectivity rules.
Add Users to the Wireless Users Security Group
You can use this procedure to add a user, computer, or group to your wireless security group in the Active Directory
Users and Computers Microsoft Management Console (MMC) snap-in.
Membership in Domain Admins , or equivalent is the minimum required to perform this procedure.
To add users to the wireless security group
1. Click Star t , click Administrative Tools , and then click Active Director y Users and Computers . The
Active Directory Users and Computers MMC opens. If it is not already selected, click the node for your
domain. For example, if your domain is example.com, click example.com .
2. In the details pane, double-click the folder that contains your wireless security group.
3. In the details pane, right-click the wireless security group, and then click Proper ties . The Proper ties dialog
box for the security group opens.
4. On the Members tab, click Add , and then complete one of the following procedures to either add a
computer or add a user or group.
To a d d a u se r o r g r o u p

1. In Enter the object names to select , type the name of the user or group that you want to add, and then
click OK .
2. To assign group membership to other users or groups, repeat step 1 of this procedure.
To a d d a c o m p u t e r

1. Click Object Types . The Object Types dialog box opens.

2. In Object types , select Computers , and then click OK .
3. In Enter the object names to select , type the name of the computer that you want to add, and then click
OK .
4. To assign group membership to other computers, repeat steps 1-3 of this procedure.

Configure Wireless Network (IEEE 802.11) Policies

Follow these steps to configure Wireless Network (IEEE 802.11) Policies Group Policy extension:
Open or Add and Open a Group Policy Object
Activate Default Wireless Network (IEEE 802.11) Policies
Configure the New Wireless Network Policy
Open or Add and Open a Group Policy Object
By default, the Group Policy Management feature is installed on computers running Windows Server 2016 when
the Active Directory Domain Services (AD DS) server role is installed and the server is configured as a domain
controller. The following procedure that describes how to open the Group Policy Management Console (GPMC) on
your domain controller. The procedure then describes how to either open an existing domain-level Group Policy
object (GPO) for editing, or create a new domain GPO and open it for editing.
Membership in Domain Admins , or equivalent, is the minimum required to perform this procedure.
To open or add and open a Group Policy object
1. On your domain controller, click Star t , click Windows Administrative Tools , and then click Group Policy
Management . The Group Policy Management Console opens.
2. In the left pane, double-click your forest. For example, double-click Forest: example.com .
3. In the left pane, double-click Domains , and then double-click the domain for which you want to manage a
Group Policy object. For example, double-click example.com .
4. Do one of the following:
To open an existing domain-level GPO for editing , double click the domain that contains the
Group Policy object that you want to manage, right-click the domain policy you want to manage, such
as the Default Domain Policy, and then click Edit . Group Policy Management Editor opens.
To create a new Group Policy object and open for editing , right-click the domain for which
you want to create a new Group Policy object, and then click Create a GPO in this domain, and
Link it here .
In New GPO , in Name , type a name for the new Group Policy object, and then click OK .
Right-click your new Group Policy object, and then click Edit . Group Policy Management Editor
opens.
In the next section you will use Group Policy Management Editor to create wireless policy.
Activate Default Wireless Network (IEEE 802.11) Policies
This procedure describes how to activate the default Wireless Network (IEEE 802.11) Policies by using the Group
Policy Management Editor (GPME).
 NOTE
After you activate the Windows Vista and Later Releases version of the Wireless Network (IEEE 802.11) Policies or the
Windows XP version, the version option is automatically removed from the list of options when you right-click Wireless
Network (IEEE 802.11) Policies . This occurs because after you select a policy version, the policy is added in the details
pane of the GPME when you select the Wireless Network (IEEE 802.11) Policies node. This state remains unless you
delete the wireless policy, at which time the wireless policy version returns to the right-click menu for Wireless Network
(IEEE 802.11) Policies in the GPME. Additionally, the wireless policies are only listed in the GPME details pane when the
Wireless Network (IEEE 802.11) Policies node is selected.

Membership in Domain Admins , or equivalent, is the minimum required to perform this procedure.
To activate default Wireless Network (IEEE 802.11) Policies
1. Follow the previous procedure, To open or add and open a Group Policy object to open the GPME.
2. In the GPME, in the left pane, double-click Computer Configuration , double-click Policies , double-click
Windows Settings , and then double-click Security Settings .

3. In Security Settings , right-click Wireless Network (IEEE 802.11) Policies , and then click Create a new
Wireless Policy for Windows Vista and Later Releases .
4. The New Wireless Network Policy Proper ties dialog box opens. In Policy Name , type a new name for the
policy or keep the default name. Click OK to save the policy. The default policy is activated and listed in the
details pane of the GPME with the new name you provided or with the default name New Wireless Network
Policy .

5. In the details pane, double-click New Wireless Network Policy to open it.
In the next section you can perform policy configuration, policy processing preference order, and network
permissions.
Configure the New Wireless Network Policy
You can use the procedures in this section to configure Wireless Network (IEEE 802.11) Policy. This policy enables
you to configure security and authentication settings, manage wireless profiles, and specify permissions for
wireless networks that are not configured as preferred networks.
Configure a Wireless Connection Profile for PEAP-MS-CHAP v2
Set the Preference Order for Wireless Connection Profiles
Define Network Permissions
Configure a Wireless Connection Profile for PEAP-MS-CHAP v2
This procedure provides the steps required to configure a PEAP-MS-CHAP v2 wireless profile.
Membership in Domain Admins , or equivalent, is the minimum required to complete this procedure.
To c o n fi g u r e a w i r e l e ss c o n n e c t i o n p r o fi l e fo r P E A P - M S- C H A P v 2

1. In GPME, in the wireless network properties dialog box for the policy that you just created, on the General
tab and in Description , type a brief description for the policy.
2. To specify that WLAN AutoConfig is used to configure wireless network adapter settings, ensure that Use
Windows WL AN AutoConfig ser vice for clients is selected.
3. In Connect to available networks in the order of profiles listed below , click Add , and then select
Infrastructure . The New Profile proper ties dialog box opens.
4. In theNew Profile proper ties dialog box, on the Connection tab, in the Profile Name field, type a new
name for the profile. For example, type Example.com WL AN Profile for Windows 10 .
5. In Network Name(s) (SSID) , type the SSID that corresponds to the SSID configured on your wireless APs,
and then click Add .
If your deployment uses multiple SSIDs and each wireless AP uses the same wireless security settings,
repeat this step to add the SSID for each wireless AP to which you want this profile to apply.
If your deployment uses multiple SSIDs and the security settings for each SSID do not match, configure a
separate profile for each group of SSIDs that use the same security settings. For example, if you have one
group of wireless APs configured to use WPA2-Enterprise and AES, and another group of wireless APs to use
WPA-Enterprise and TKIP, configure a profile for each group of wireless APs.
6. If the default text NEWSSID is present, select it, and then click Remove .
7. If you deployed wireless access points that are configured to suppress the broadcast beacon, select Connect
even if the network is not broadcasting .

NOTE
Enabling this option can create a security risk because wireless clients will probe for and attempt connections to any
wireless network. By default, this setting is not enabled.

8. Click the Security tab, click Advanced , and then configure the following:
a. To configure advanced 802.1X settings, in IEEE 802.1X , select Enforce advanced 802.1X settings .
When the advanced 802.1X settings are enforced, the default values for Max Eapol-Star t Msgs ,
Held Period , Star t Period , and Auth Period are sufficient for typical wireless deployments.
Because of this, you do not need to change the defaults unless you have a specific reason for doing
so.
b. To enable Single Sign On, select Enable Single Sign On for this network .
 c. The remaining default values in Single Sign On are sufficient for typical wireless deployments.
d. In Fast Roaming , if your wireless AP is configured for pre-authentication, select This network uses
pre-authentication .
9. To specify that wireless communications meet FIPS 140-2 standards, select Perform cr yptography in
FIPS 140-2 cer tified mode .
10. Click OK to return to the Security tab. In Select the security methods for this network , in
Authentication , select WPA2-Enterprise if it is supported by your wireless AP and wireless client network
adapters. Otherwise, select WPA-Enterprise .
11. In Encr yption , if supported by your wireless AP and wireless client network adapters, select AES-CCMP . If
you are using access points and wireless network adapters that support 802.11ac, select AES-GCMP .
Otherwise, select TKIP .

NOTE
The settings for both Authentication and Encr yption must match the settings configured on your wireless APs.
The default settings for Authentication Mode , Max Authentication Failures , and Cache user information
for subsequent connections to this network are sufficient for typical wireless deployments.

12. In Select a network authentication method , select Protected EAP (PEAP) , and then click Proper ties .
The Protected EAP Proper ties dialog box opens.
13. In Protected EAP Proper ties , confirm that Verify the ser ver's identity by validating the cer tificate
is selected.
14. In Trusted Root Cer tification Authorities , select the trusted root certification authority (CA) that issued
the server certificate to your NPS.

NOTE
This setting limits the root CAs that clients trust to the selected CAs. If no trusted root CAs are selected, then clients
will trust all root CAs listed in their Trusted Root Certification Authorities certificate store.

15. In the Select Authentication Method list, select Secured password (EAP-MS-CHAP v2) .
16. Click Configure . In the EAP MSCHAPv2 Proper ties dialog box, verify Automatically use my Windows
logon name and password (and domain if any) is selected, and click OK .
17. To enable PEAP Fast Reconnect, ensure that Enable Fast Reconnect is selected.
18. To require server cryptobinding TLV on connection attempts, select Disconnect if ser ver does not
present cr yptobinding TLV .
19. To specify that user identity is masked in phase one of authentication, select Enable Identity Privacy , and
in the textbox, type an anonymous identity name, or leave the textbox blank.

[!NOTES]
The NPS policy for 802.1X Wireless must be created by using NPS Connection Request Policy . If
the NPS policy is created by using NPS Network Policy , then identity privacy will not work.
EAP identity privacy is provided by certain EAP methods where an empty or an anonymous identity
(different from the actual identity) is sent in response to the EAP identity request. PEAP sends the
identity twice during the authentication. In the first phase, the identity is sent in plain text and this
identity is used for routing purposes, not for client authentication. The real identity—used for
 authentication—is sent during the second phase of the authentication, within the secure tunnel that is
established in the first phase. If Enable Identity Privacy checkbox is selected, the username is
replaced with the entry specified in the textbox. For example, assume Enable Identity Privacy is
selected and the identity privacy alias anonymous is specified in the textbox. For a user with a real
identity alias [email protected] , the identity sent in first phase of authentication will be changed
to [email protected] . The realm portion of the 1st phase identity is not modified as it is
used for routing purposes.

20. Click OK to close the Protected EAP Proper ties dialog box.
21. Click OK to close the Security tab.
22. If you want to create additional profiles, click Add , and then repeat the previous steps, making different
choices to customize each profile for the wireless clients and network to which you want the profile applied.
When you are done adding profiles, click OK to close the Wireless Network Policy Properties dialog box.
In the next section you can order the policy profiles for optimum security.
Set the Preference Order for Wireless Connection Profiles
You can use this procedure if you have created multiple wireless profiles in your wireless network policy and you
want to order the profiles for optimal effectiveness and security.
To ensure that wireless clients connect with the highest level of security that they can support, place your most
restrictive policies at the top of the list.
For example, if you have two profiles, one for clients that support WPA2 and one for clients that support WPA,
place the WPA2 profile higher on the list. This ensures that the clients that support WPA2 will use that method for
the connection rather than the less secure WPA.
This procedure provides the steps to specify the order in which wireless connection profiles are used to connect
domain member wireless clients to wireless networks.
Membership in Domain Admins , or equivalent, is the minimum required to complete this procedure.
To se t t h e p r e fe r e n c e o r d e r fo r w i r e l e ss c o n n e c t i o n p r o fi l e s

1. In GPME, in the wireless network properties dialog box for the policy that you just configured, click the
General tab.
2. On the General tab, in Connect to available networks in the order of profiles listed below , select
the profile that you want to move in the list, and then click either the "up arrow" button or “down arrow”
button to move the profile to the desired location in the list.
3. Repeat step 2 for each profile that you want to move in the list.
4. Click OK to save all changes.
In the following section, you can define network permissions for the wireless policy.
Define Network Permissions
You can configure settings on the Network Permissions tab for the domain members to which Wireless Network
(IEEE 802.11) Policies apply.
You can only apply the following settings for wireless networks that are not configured on the General tab in the
Wireless Network Policy Proper ties page:
Allow or deny connections to specific wireless networks that you specify by network type and Service Set
Identifier (SSID)
Allow or deny connections to ad hoc networks
 Allow or deny connections to infrastructure networks
Allow or deny users to view network types (ad hoc or infrastructure) to which they are denied access
Allow or deny users to create a profile that applies to all users
Users can only connect to allowed networks by using Group Policy profiles
Membership in Domain Admins , or equivalent, is the minimum required to complete these procedures.
To a l l o w o r d e n y c o n n e c t i o n s t o sp e c i fi c w i r e l e ss n e t w o r k s

1. In GPME, in the wireless network properties dialog box, click the Network Permissions tab.
2. On the Network Permissions tab, click Add . The New Permissions Entr y dialog box opens.
3. In the New Permission Entr y dialog box, in the Network Name (SSID) field, type the network SSID of
the network for which you want to define permissions.
4. In Network Type , select Infrastructure or Ad hoc .

NOTE
If you are uncertain whether the broadcasting network is an infrastructure or ad hoc network, you can configure two
network permission entries, one for each network type.

5. In Permission , select Allow or Deny .

6. Click OK , to return to the Network Permissions tab.
To sp e c i fy a d d i t i o n a l n e t w o r k p e r m i ssi o n s (O p t i o n a l )

1. On the Network Permissions tab, configure any or all of the following:

To deny your domain members access to ad hoc networks, select Prevent connections to ad-hoc
networks .
To deny your domain members access to infrastructure networks, select Prevent connections to
infrastructure networks .
To allow your domain members to view network types (ad hoc or infrastructure) to which they are
denied access, select Allow user to view denied networks .
To allow users to create profiles that apply to all users, select Allow ever yone to create all user
profiles .
To specify that your users can only connect to allowed networks by using Group Policy profiles, select
Only use Group Policy profiles for allowed networks .

Configure your NPSs

Follow these steps to configure NPSs to perform 802.1X authentication for wireless access:
Register NPS in Active Directory Domain Services
Configure a Wireless AP as an NPS RADIUS Client
Create NPS Policies for 802.1X Wireless using a Wizard
Register NPS in Active Directory Domain Services
You can use this procedure to register a server running Network Policy Server (NPS) in Active Directory Domain
Services (AD DS) in the domain where the NPS is a member. For NPSs to be granted permission to read the dial-in
properties of user accounts during the authorization process, each NPS must be registered in AD DS. Registering
an NPS adds the server to the RAS and IAS Ser vers security group in AD DS.

NOTE
You can install NPS on a domain controller or on a dedicated server. Run the following Windows PowerShell command to
install NPS if you have not yet done so:

Install-WindowsFeature NPAS -IncludeManagementTools

Membership in Domain Admins , or equivalent, is the minimum required to complete this procedure.
To register an NPS in its default domain
1. On your NPS, in Ser ver Manager , click Tools , and then click Network Policy Ser ver . The NPS snap-in
opens.
2. Right-click NPS (Local) , and then click Register Ser ver in Active Director y . The Network Policy
Ser ver dialog box opens.
3. In Network Policy Ser ver , click OK , and then click OK again.
Configure a Wireless AP as an NPS RADIUS Client
You can use this procedure to configure an AP, also known as a network access server (NAS), as a Remote
Authentication Dial-In User Service (RADIUS) client by using the NPS snap-in.

IMPORTANT
Client computers, such as wireless portable computers and other computers running client operating systems, are not
RADIUS clients. RADIUS clients are network access servers—such as wireless access points, 802.1X-capable switches, virtual
private network (VPN) servers, and dial-up servers—because they use the RADIUS protocol to communicate with RADIUS
servers such as NPSs.

Membership in Domain Admins , or equivalent, is the minimum required to complete this procedure.
To add a network access server as a RADIUS client in NPS
1. On your NPS, in Ser ver Manager , click Tools , and then click Network Policy Ser ver . The NPS snap-in
opens.
2. In the NPS snap-in, double-click RADIUS Clients and Ser vers . Right-click RADIUS Clients , and then click
New .
3. In New RADIUS Client , verify that the Enable this RADIUS client check box is selected.
4. In New RADIUS Client , in Friendly name , type a display name for the wireless access point.
For example, if you want to add a wireless access point (AP) named AP-01, type AP-01 .
5. In Address (IP or DNS) , type the IP address or fully qualified domain name (FQDN) for the NAS.
If you enter the FQDN, to verify that the name is correct and maps to a valid IP address, click Verify , and
then in Verify Address , in the Address field, click Resolve . If the FQDN name maps to a valid IP address,
the IP address of that NAS will automatically appear in IP address . If the FQDN does not resolve to an IP
address you will receive a message indicating that no such host is known. If this occurs, verify that you have
the correct AP name and that the AP is powered on and connected to the network.
Click OK to close Verify Address .
6. In New RADIUS Client , in Shared Secret , do one of the following:
 To manually configure a RADIUS shared secret, select Manual , and then in Shared secret , type the
strong password that is also entered on the NAS. Retype the shared secret in Confirm shared
secret .
To automatically generate a shared secret, select the Generate check box, and then click the
Generate button. Save the generated shared secret, and then use that value to configure the NAS so
that it can communicate with the NPS.

IMPORTANT
The RADIUS shared secret that you enter for your virtual AP's in NPS must exactly match the RADIUS shared
secret that is configured on your actual wireless AP's. If you use the NPS option to generate a RADIUS shared
secret, then you must configure the matching actual wireless AP with the RADIUS shared secret that was
generated by NPS.

7. In New RADIUS Client , on the Advanced tab, in Vendor name , specify the NAS manufacturer name. If
you are not sure of the NAS manufacturer name, select RADIUS standard .
8. In Additional Options , if you are using any authentication methods other than EAP and PEAP, and if your
NAS supports the use of the message authenticator attribute, select Access Request messages must
contain the Message-Authenticator attribute .
9. Click OK . Your NAS appears in the list of RADIUS clients configured on the NPS.
Create NPS Policies for 802.1X Wireless Using a Wizard
You can use this procedure to create the connection request policies and network policies required to deploy either
802.1X-capable wireless access points as Remote Authentication Dial-In User Service (RADIUS) clients to the
RADIUS server running Network Policy Server (NPS).
After you run the wizard, the following policies are created:
One connection request policy
One network policy

NOTE
You can run the New IEEE 802.1X Secure Wired and Wireless Connections wizard every time you need to create new policies
for 802.1X authenticated access.

Membership in Domain Admins , or equivalent, is the minimum required to complete this procedure.
Create policies for 802.1X authenticated wireless by using a wizard
1. Open the NPS snap-in. If it is not already selected, click NPS (Local) . If you are running the NPS MMC snap-
in and want to create policies on a remote NPS, select the server.
2. In Getting Star ted , in Standard Configuration , select RADIUS ser ver for 802.1X Wireless or Wired
Connections . The text and links below the text change to reflect your selection.
3. Click Configure 802.1X . The Configure 802.1X wizard opens.
4. On the Select 802.1X Connections Type wizard page, in Type of 802.1X connections , select Secure
Wireless Connections , and in Name , type a name for your policy, or leave the default name Secure
Wireless Connections . Click Next .
5. On the Specify 802.1X Switches wizard page, in RADIUS clients , all 802.1X switches and wireless access
points that you have added as RADIUS Clients in the NPS snap-in are shown. Do any of the following:
 To add additional network access servers (NASs), such as wireless APs, in RADIUS clients , click Add ,
and then in New RADIUS client , enter the information for: Friendly name , Address (IP or DNS) ,
and Shared Secret .
To modify the settings for any NAS, in RADIUS clients , select the AP for which you want to modify
the settings, and then click Edit . Modify the settings as required.
To remove a NAS from the list, in RADIUS clients , select the NAS, and then click Remove .

WARNING
Removing a RADIUS client from within the Configure 802.1X wizard deletes the client from the NPS
configuration. All additions, modifications, and deletions that you make within the Configure 802.1X wizard
to RADIUS clients are reflected in the NPS snap-in, in the RADIUS Clients node under NPS / RADIUS
Clients and Ser vers . For example, if you use the wizard to remove an 802.1X switch, the switch is also
removed from the NPS snap-in.

6. Click Next . On the Configure an Authentication Method wizard page, in Type (based on method of
access and network configuration) , select Microsoft: Protected EAP (PEAP) , and then click
Configure .

TIP
If you receive an error message indicating that a certificate cannot be found for use with the authentication method,
and you have configured Active Directory Certificate Services to automatically issue certificates to RAS and IAS
servers on your network, first ensure that you have followed the steps to Register NPS in Active Directory Domain
Services, then use the following steps to update Group Policy: Click Star t , click Windows System , click Run , and in
Open , type gpupdate , and then press ENTER. When the command returns results indicating that both user and
computer Group Policy have updated successfully, select Microsoft: Protected EAP (PEAP) again, and then click
Configure .
If after refreshing Group Policy you continue to receive the error message indicating that a certificate cannot be
found for use with the authentication method, the certificate is not being displayed because it does not meet the
minimum server certificate requirements as documented in the Core Network Companion Guide: Deploy Server
Certificates for 802.1X Wired and Wireless Deployments. If this happens, you must discontinue NPS configuration,
revoke the certificate issued to your NPS(s), and then follow the instructions to configure a new certificate by using
the server certificates deployment guide.

7. On the Edit Protected EAP Proper ties wizard page, in Cer tificate issued , ensure that the correct NPS
certificate is selected, and then do the following:

NOTE
Verify that the value in Issuer is correct for the certificate selected in Cer tificate issued . For example, the expected
issuer for a certificate issued by a CA running Active Directory Certificate Services (AD CS) named corp\DC1, in the
domain contoso.com, is corp-DC1-CA .

To allow users to roam with their wireless computers between access points without requiring them
to reauthenticate each time they associate with a new AP, select Enable Fast Reconnect .
To specify that connecting wireless clients will end the network authentication process if the RADIUS
server does not present cryptobinding Type-Length-Value (TLV), select Disconnect Clients without
Cr yptobinding .
To modify the policy settings for the EAP type, in EAP Types , click Edit , in EAP MSCHAPv2
 Proper ties , modify the settings as needed, and then click OK .
8. Click OK . The Edit Protected EAP Properties dialog box closes, returning you to the Configure 802.1X
wizard. Click Next .
9. In Specify User Groups , click Add , and then type the name of the security group that you configured for
your wireless clients in the Active Directory Users and Computers snap-in. For example, if you named your
wireless security group Wireless Group, type Wireless Group . Click Next .
10. Click Configure to configure RADIUS standard attributes and vendor-specific attributes for virtual LAN
(VLAN) as needed, and as specified by the documentation provided by your wireless AP hardware vendor.
Click Next .
11. Review the configuration summary details, and then click Finish .
Your NPS policies are now created, and you can move on to joining wireless computers to the domain.

Join New Wireless Computers to the Domain

The easiest method to join new wireless computers to the domain is to physically attach the computer to a
segment of the wired LAN (a segment not controlled by an 802.1X switch) before joining the computer to the
domain. This is easiest because wireless group policy settings are automatically and immediately applied and, if
you have deployed your own PKI, the computer receives the CA certificate and places it in the Trusted Root
Certification Authorities certificate store, allowing the wireless client to trust NPSs with server certs issued by your
CA.
Likewise, after a new wireless computer is joined to the domain, the preferred method for users to log on to the
domain is to perform log on by using a wired connection to the network.
Other domain-join methods
In cases where it is not practical to join computers to the domain by using a wired Ethernet connection, or in cases
where the user cannot log on to the domain for the first time by using a wired connection, you must use an
alternate method.
IT Staff Computer Configuration . A member of the IT staff joins a wireless computer to the domain and
configures a Single Sign On bootstrap wireless profile. With this method, the IT administrator connects the
wireless computer to the wired Ethernet network and joins the computer to the domain. Then the administrator
distributes the computer to the user. When the user starts the computer without using a wired connection, the
domain credentials that they manually specify for the user logon are used to both establish a connection to the
wireless network and to log on to the domain.
For more information, see the section Join the Domain and Log On by using the IT Staff Computer Configuration
Method
Bootstrap Wireless Profile Configuration by Users . The user manually configures the wireless computer
with a bootstrap wireless profile and joins the domain, based on instructions acquired from an IT administrator.
The bootstrap wireless profile allows the user to establish a wireless connection and then join the domain. After
joining the computer to the domain and restarting the computer, the user can log on to the domain by using a
wireless connection and their domain account credentials.
For more information, see the section Join the Domain and Log On by using Bootstrap Wireless Profile
Configuration by Users.
Join the Domain and Log On by using the IT Staff Computer Configuration Method
Domain member users with domain-joined wireless client computers can use a temporary wireless profile to
connect to an 802.1X-authenticated wireless network without first connecting to the wired LAN. This temporary
wireless profile is called a bootstrap wireless profile.
A bootstrap wireless profile requires the user to manually specify their domain user account credentials, and does
not validate the certificate of the Remote Authentication Dial-In User Service (RADIUS) server running Network
Policy Server (NPS).
After wireless connectivity is established, Group Policy is applied on the wireless client computer, and a new
wireless profile is issued automatically. The new policy uses the computer and user account credentials for client
authentication.
Additionally, as part of the PEAP-MS-CHAP v2 mutual authentication using the new profile instead of the bootstrap
profile, the client validates the credentials of the RADIUS server.
After you join the computer to the domain, use this procedure to configure a Single Sign On bootstrap wireless
profile, before distributing the wireless computer to the domain-member user.
To configure a Single Sign On bootstrap wireless profile
1. Create a bootstrap profile by using the procedure in this guide named Configure a Wireless Connection
Profile for PEAP-MS-CHAP v2, and use the following settings:
PEAP-MS-CHAP v2 authentication
Validate RADIUS server certificate disabled
Single Sign On enabled
2. In the properties of the Wireless Network Policy within which you created the new bootstrap profile, on the
General tab, select the bootstrap profile, and then click Expor t to export the profile to a network share, USB
flash drive, or other easily accessible location. The profile is saved as an *.xml file to the location that you
specify.
3. Join the new wireless computer to the domain (for example, through an Ethernet connection that does not
require IEEE 802.1X authentication) and add the bootstrap wireless profile to the computer by using the
netsh wlan add profile command.

NOTE
For more information, see Netsh Commands for Wireless Local Area Network (WLAN) at
http://technet.microsoft.com/library/dd744890.aspx.

4. Distribute the new wireless computer to the user with the procedure to “Log on to the domain using
computers running Windows 10.”
When the user starts the computer, Windows prompts the user to enter their domain user account name and
password. Because Single Sign On is enabled, the computer uses the domain user account credentials to first
establish a connection with the wireless network and then log on to the domain.
Log on to the domain using computers running Windows 10
1. Log off the computer, or restart the computer.
2. Press any key on your keyboard or click on the desktop. The logon screen appears with a local user account
name displayed and a password entry field below the name. Do not log on with the local user account.
3. In the lower left corner of the screen, click Other User . The Other User log on screen appears with two
fields, one for user name and one for password. Below the password field is the text Sign on to: and then
the name of the domain where the computer is joined. For example, if your domain is named example.com,
the text reads Sign on to: EXAMPLE .
4. In User name , type your domain user name.
5. In Password , type your domain password, and then click the arrow, or press ENTER.
 NOTE
If the Other User screen does not include the text Sign on to: and your domain name, you should enter your user name
in the format domain\user. For example, to log on to the domain example.com with an account named User-01 , type
example\User-01 .

Join the Domain and Log On by using Bootstrap Wireless Profile Configuration by Users
With this method, you complete the steps in the General steps section, then you provide your domain-member
users with the instructions about how to manually configure a wireless computer with a bootstrap wireless profile.
The bootstrap wireless profile allows the user to establish a wireless connection and then join the domain. After the
computer is joined to the domain and restarted, the user can log on to the domain through a wireless connection.
General steps
1. Configure a local computer administrator account, in Control Panel , for the user.

IMPORTANT
To join a computer to a domain, the user must be logged on to the computer with the local Administrator account.
Alternatively, the user must provide the credentials for the local Administrator account during the process of joining
the computer to the domain. In addition, the user must have a user account in the domain to which the user wants
to join the computer. During the process of joining the computer to the domain, the user will be prompted for
domain account credentials (user name and password).

2. Provide your domain users with the instructions for configuring a bootstrap wireless profile, as documented
in the following procedure To configure a bootstrap wireless profile .
3. Additionally, provide users with both the local computer credentials (user name and password), and domain
credentials (domain user account name and password) in the form DomainName\UserName, as well as the
procedures to “Join the computer to the domain,” and to “Log on to the domain,” as documented in the
Windows Server 2016 Core Network Guide.
To configure a bootstrap wireless profile
1. Use the credentials provided by your network administrator or IT support professional to log on to the
computer with the local computer's Administrator account.
2. Right-click the network icon on the desktop, and click Open Network and Sharing Center . Network
and Sharing Center opens. In Change your networking settings , click Set up a new connection or
network . The Set Up a Connection or Network dialog box opens.
3. Click Manually connect to a wireless network , and then click Next .
4. In Manually connect to a wireless network , in Network name , type the SSID name of the AP.
5. In Security type , select the setting provided by your administrator.
6. In Encr yption type and Security Key , select or type the settings provided by your administrator.
7. Select Star t this connection automatically , and then click Next .
8. In Successfully added Your Network SSID, click Change connection settings .
9. Click Change connection settings . The Your Network SSID Wireless Network property dialog box opens.
10. Click the Security tab, and then in Choose a network authentication method , select Protected EAP
(PEAP) .
11. Click Settings . The Protected EAP (PEAP) Proper ties page opens.
12. In the Protected EAP (PEAP) Proper ties page, ensure that Validate ser ver cer tificate is not selected,
click OK twice, and then click Close .
13. Windows then attempts to connect to the wireless network. The settings of the bootstrap wireless profile
specify that you must provide your domain credentials. When Windows prompts you for an account name
and password, type your domain account credentials as follows: Domain Name\User Name, Domain
Password.
To j o i n a c o m p u t e r t o t h e d o m a i n

1. Log on to the computer with the local Administrator account.

2. In the search text box, type PowerShell . In search results, right-click Windows PowerShell , and then click
Run as administrator . Windows PowerShell opens with an elevated prompt.
3. In Windows PowerShell, type the following command, and then press ENTER. Ensure that you replace the
variable DomainName with the name of the domain that you want to join.
Add-Computer DomainName
4. When prompted, type your domain user name and password, and click OK .
5. Restart the computer.
6. Follow the instructions in the previous section Log on to the domain using computers running Windows 10.
 Deploy BranchCache Hosted Cache Mode
3/26/2020 • 6 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

The Windows Server 2016 Core Network Guide provides instructions for planning and deploying the core
components required for a fully functioning network and a new Active Directory® domain in a new forest.
This guide explains how to build on the core network by providing instructions for deploying BranchCache in
hosted cache mode in one or more branch offices with a Read-Only Domain Controller where client computers are
running Windows® 10, Windows 8.1, or Windows 8, and are joined to the domain.

IMPORTANT
Do not use this guide if you are planning to deploy or have already deployed a BranchCache hosted cache server that is
running Windows Server 2008 R2. This guide provides instructions for deploying hosted cache mode with a hosted cache
server that is running Windows Server® 2016, Windows Server 2012 R2, or Windows Server 2012.

This guide contains the following sections.

Prerequisites for using this guide
About this guide
What this guide does not provide
Technology overviews
BranchCache Hosted Cache Mode Deployment Overview
BranchCache Hosted Cache Mode Deployment Planning
BranchCache Hosted Cache Mode Deployment
Additional Resources

Prerequisites for using this guide

This is a companion guide to the Windows Server 2016 Core Network Guide. To deploy BranchCache in hosted
cache mode with this guide, you must first do the following.
Deploy a core network in your main office by using the Core Network Guide, or already have the
technologies provided in the Core Network Guide installed and functioning correctly on your network. These
technologies include TCP/IP v4, DHCP, Active Directory Domain Services (AD DS), and DNS.

NOTE
The Windows Server 2016 Core Network Guide is available in the Windows Server 2016 Technical Library.

Deploy BranchCache content servers that are running Windows Server 2016, Windows Server 2012 R2, or
Windows Server 2012 in your main office or in a cloud data center. For information on how to deploy
BranchCache content servers, see Additional Resources.
 Establish wide area network (WAN) connections between your branch office, your main office and, if
appropriate, your Cloud resources, by using a virtual private network (VPN), DirectAccess, or other
connection method.
Deploy client computers in your branch office that are running one of the following operating systems,
which provide BranchCache with support for Background Intelligent Transfer Service (BITS), Hyper Text
Transfer Protocol (HTTP), and Server Message Block (SMB).
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
Windows 8 Enterprise

NOTE
In the following operating systems, BranchCache does not support HTTP and SMB functionality, but does support
BranchCache BITS functionality. - Windows 10 Pro, BITS support only - Windows 8.1 Pro, BITS support only - Windows 8 Pro,
BITS support only

About this guide

This guide is designed for network and system administrators who have followed the instructions in the Windows
Server 2016 Core Network Guide or Windows Server 2012 Core Network Guide to deploy a core network, or for
those who have previously deployed the technologies included in the Core Network Guide, including Active
Directory Domain Services (AD DS), Domain Name Service (DNS), Dynamic Host Configuration Protocol (DHCP),
and TCP/IP v4.
It is recommended that you review the design and deployment guides for each of the technologies that are used in
this deployment scenario. These guides can help you determine whether this deployment scenario provides the
services and configuration that you need for your organization's network.

What this guide does not provide

This guide does not provide conceptual information about BranchCache, including information about BranchCache
modes and capabilities.
This guide does not provide information about how to deploy WAN connections or other technologies in your
branch office, such as DHCP, a RODC, or a VPN server.
In addition, this guide does not provide guidance on the hardware you should use when you deploy a hosted cache
server. It is possible to run other services and applications on your hosted cache server, however you must make
the determination, based on workload, hardware capabilities, and branch office size, whether to install BranchCache
hosted cache server on a particular computer, and how much disk space to allocate for the cache.
This guide does not provide instructions for configuring computers that are running Windows 7. If you have client
computers that are running Windows 7 in your branch offices, you must configure them using procedures that are
different than those provided in this guide for client computers that are running Windows 10, Windows 8.1, and
Windows 8.
In addition, if you have computers running Windows 7, you must configure your hosted cache server with a server
certificate that is issued by a certification authority that client computers trust. (If all of your client computers are
running Windows 10, Windows 8.1, or Windows 8, you do not need to configure the hosted cache server with a
server certificate.)
 IMPORTANT
If your hosted cache servers are running Windows Server 2008 R2, use the Windows Server 2008 R2 BranchCache
Deployment Guide instead of this guide to deploy BranchCache in hosted cache mode. Apply the Group Policy settings that
are described in that guide to all BranchCache clients that are running versions of Windows from Windows 7 to Windows 10.
Computers that are running Windows Server 2008 R2 cannot be configured by using the steps in this guide.

Technology overviews
For this companion guide, BranchCache is the only technology that you need to install and configure. You must run
Windows PowerShell BranchCache commands on your content servers, such as Web and file servers, however you
do not need to change or reconfigure the content servers in any other way. In addition, you must configure client
computers by using Group Policy on your domain controllers that are running AD DS on Windows Server 2016,
Windows Server 2012 R2, or Windows Server 2012.
BranchCache
BranchCache is a wide area network (WAN) bandwidth optimization technology that is included in some editions of
the Windows Server 2016 and Windows 10 operating systems, as well as in some editions of Windows Server
2012 R2, Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008 R2, and Windows 7.
To optimize WAN bandwidth when users access content on remote servers, BranchCache downloads client-
requested content from your main office or hosted cloud content servers and caches the content at branch office
locations, allowing other client computers at branch offices to access the same content locally rather than over the
WAN.
When you deploy BranchCache in hosted cache mode, you must configure client computers in the branch office as
hosted cache mode clients, and then you must deploy a hosted cache server in the branch office. This guide
demonstrates how to deploy your hosted cache server with prehashed and preloaded content from your Web and
file server-based content servers.
Group Policy
Group Policy in Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012 is an infrastructure
used to deliver and apply one or more desired configurations or policy settings to a set of targeted users and
computers within an Active Directory environment.
This infrastructure consists of a Group Policy engine and multiple client-side extensions (CSEs) that are responsible
for reading policy settings on target client computers.
Group Policy is used in this scenario to configure domain member client computers with BranchCache hosted cache
mode.
To continue with this guide, see BranchCache Hosted Cache Mode Deployment Overview.
 BranchCache Hosted Cache Mode Deployment
Overview
3/26/2020 • 4 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

You can use this guide to deploy a BranchCache hosted cache server in a branch office where computers are joined
to a domain. You can use this topic to gain an overview of the BranchCache Hosted Cache Mode deployment
process.
This overview includes the BranchCache infrastructure that you need, as well as a simple step-by-step overview of
deployment.

Hosted Cache Server deployment infrastructure

In this deployment, the hosted cache server is deployed by using service connection points in Active Directory
Domain Services (AD DS), and you have the option with BranchCache in Windows Server 2016, Windows Server
2012 R2, and Windows Server 2012, to prehash the shared content on Web and file based content servers, then
preload the content on hosted cache servers.
The following illustration shows the infrastructure that is required to deploy a BranchCache hosted cache server.

IMPORTANT
Although this deployment depicts content servers in a cloud data center, you can use this guide to deploy a BranchCache
hosted cache server regardless of where you deploy your content servers – in your main office or in a cloud location.

HCS1 in the branch office

You must configure this computer as a hosted cache server. If you choose to prehash content server data so that
you can preload the content on your hosted cache servers, you can import data packages that contain the content
from your Web and file servers.
WEB1 in the cloud data center
WEB1 is a BranchCache-enabled content server. If you choose to prehash content server data so that you can
preload the content on your hosted cache servers, you can prehash the shared content on WEB1, then create a data
package that you copy to HCS1.
FILE1 in the cloud data center
FILE1 is a BranchCache-enabled content server. If you choose to prehash content server data so that you can
preload the content on your hosted cache servers, you can prehash the shared content on FILE1, then create a data
package that you copy to HCS1.
DC1 in the main office
DC1 is a domain controller, and you must configure the Default Domain Policy, or another policy that is more
appropriate for your deployment, with BranchCache Group Policy settings to enable Automatic Hosted Cache
Discovery by Service Connection Point.
When client computers in the branch have Group Policy refreshed and this policy setting is applied, they
automatically locate and begin to use the hosted cache server in the branch office.
Client computers in the branch office
You must refresh Group Policy on client computers to apply new BranchCache Group Policy settings and to allow
clients to locate and use the hosted cache server.

Hosted Cache Server deployment process overview

NOTE
The details of how to perform these steps are provided in the section BranchCache Hosted Cache Mode Deployment.

The process of deploying a BranchCache Hosted Cache Server occurs in these stages:

NOTE
Some of the steps below are optional, such as those steps that demonstrate how to prehash and preload content on hosted
cache servers. When you deploy BranchCache in hosted cache mode, you are not required to prehash content on your Web
and file content servers, to create a data package, and to import the data package in order to preload your hosted cache
servers with content. The steps are noted as optional in this section and in the section BranchCache Hosted Cache Mode
Deployment so that you can skip them if you prefer.

1. On HCS1, use Windows PowerShell commands to configure the computer as a hosted cache server and to
register a Service Connection Point in Active Directory.
2. (Optional) On HCS1, if the BranchCache default values do not match your deployment goals for the server
and the hosted cache, configure the amount of disk space that you want to allocate for the hosted cache.
Also configure the disk location that you prefer for the hosted cache.
3. (Optional) Prehash content on content servers, create data packages, and preload content on the hosted
cache server.
 NOTE
Prehashing and preloading content on your hosted cache server is optional, however if you choose to prehash and
preload, you must perform all of the steps below that are applicable to your deployment. (For example, if you do not
have Web servers, you do not need to perform any of the steps related to prehashing and preloading Web server
content.)

a. On WEB1, prehash Web server content and create a data package.

b. On FILE1, prehash file server content and create a data package.
c. From WEB1 and FILE1, copy the data packages to the hosted cache server HCS1.
d. On HCS1, import the data packages to preload the data cache.
4. On DC1, configure domain joined branch office client computers for hosted cache mode by configuring
Group Policy with BranchCache policy settings.
5. On client computers, refresh Group Policy.
To continue with this guide, see BranchCache Hosted Cache Mode Deployment Planning.
 BranchCache Hosted Cache Mode Deployment
Planning
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

You can use this topic to plan your deployment of BranchCache in Hosted Cache mode.

IMPORTANT
Your hosted cache server must be running Windows Server 2016, Windows Server 2012 R2, or Windows Server 2012.

Before you deploy your hosted cache server, you must plan the following items:
Plan basic server configuration
Plan domain access
Plan the location and size of the hosted cache
Plan the share to which the content server packages are to be copied
Plan prehashing and data package creation on content servers

Plan basic server configuration

If you are planning on using an existing server in your branch office as your hosted cache server, you do not need
to perform this planning step, because the computer is already named and has an IP address configuration.
After you install Windows Server 2016 on your hosted cache server, you must rename the computer and assign
and configure a static IP address for the local computer.

NOTE
In this guide, the hosted cache server is named HCS1, however you should use a server name that is appropriate for your
deployment.

Plan domain access

If you are planning on using an existing server in your branch office as your hosted cache server, you do not need
to perform this planning step, unless the computer is not currently joined to the domain.
To log on to the domain, the computer must be a domain member computer and the user account must be created
in AD DS before the logon attempt. In addition, you must join the computer to the domain with an account that has
the appropriate group membership.

Plan the location and size of the hosted cache

On HCS1, determine where on your hosted cache server you want to locate the hosted cache. For example, decide
the hard disk, volume, and folder location where you plan to store the cache.
In addition, decide what percentage of disk space you want to allocate for the hosted cache.

Plan the share to which the content server packages are to be copied
After you create data packages on your content servers, you must copy them over the network to a share on your
hosted cache server.
Plan the folder location and sharing permissions for the shared folder. In addition, if your content servers host a
large amount of data and the packages that you create will be large files, plan to perform the copy operation
during off\–peak hours so that WAN bandwidth is not consumed by the copy operation during a time when others
need to use the bandwidth for normal business operations.

Plan prehashing and data package creation on content servers

Before you prehash content on your content servers, you must identify the folders and files that contain content
that you want to add to the data package.
In addition, you must plan on the local folder location where you can store the data packages before copying them
to the hosted cache server.
To continue with this guide, see BranchCache Hosted Cache Mode Deployment.
 BranchCache Hosted Cache Mode Deployment
4/7/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

You can use this topic for links to detailed procedural topics that guide you through the BranchCache hosted cache
mode deployment process.
Follow these steps to deploy BranchCache hosted cache mode.
Install the BranchCache Feature and Configure the Hosted Cache Server by Service Connection Point
Move and Resize the Hosted Cache (Optional)
Prehash and Preload Content on the Hosted Cache Server (Optional)
Configure Client Automatic Hosted Cache Discovery by Service Connection Point

NOTE
The procedures in this guide do not include instructions for cases in which the User Account Control dialog box opens to
request your permission to continue. If this dialog box opens while you are performing the procedures in this guide, and if
the dialog box was opened in response to your actions, click Continue .

To continue with this guide, see Install the BranchCache Feature and Configure the Hosted Cache Server by Service
Connection Point.
 Install the BranchCache Feature and Configure the
Hosted Cache Server by Service Connection Point
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

You can use this procedure to install the BranchCache feature on your hosted cache server, HCS1, and to configure
the server to register a Service Connection Point (SCP) in Active Directory Domain Services (AD DS).
When you register hosted cache servers with an SCP in AD DS, the SCP allows client computers that are configured
correctly to automatically discover hosted cache servers by querying AD DS for the SCP. Instructions on how to
configure client computers to perform this action are provided later in this guide.

IMPORTANT
Before you perform this procedure, you must join the computer to the domain and configure the computer with a static IP
address.

To perform this procedure, you must be a member of the Administrators group.

To install the BranchCache feature and configure the hosted cache

server
1. On the server computer, run Windows PowerShell as an Administrator. Type the following command, and
then press ENTER.

Install-WindowsFeature BranchCache

2. To configure the computer as a hosted cache server after the BranchCache feature is installed, and to
register a Service Connection Point in AD DS, type the following command in Windows PowerShell, and
then press ENTER.

Enable-BCHostedServer -RegisterSCP

3. To verify the hosted cache server configuration, type the following command and press ENTER.

Get-BCStatus

The results of the command display status for all aspects of your BranchCache installation. Following are a
few of the BranchCache settings and the correct value for each item:
BranchCacheIsEnabled: True
HostedCacheServerIsEnabled: True
HostedCacheScpRegistrationEnabled: True
4. To prepare for the step of copying your data packages from your content servers to your hosted cache
servers, either identify an existing share on the hosted cache server or create a new folder and share the
folder so that it is accessible from your content servers. After you create your data packages on your content
servers, you will copy the data packages to this shared folder on the hosted cache server.
5. If you are deploying more than one hosted cache server, repeat this procedure on each server.
To continue with this guide, see Move and Resize the Hosted Cache (Optional).
 Move and Resize the Hosted Cache (Optional)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

You can use this procedure to move the hosted cache to the drive and folder that you prefer, and to specify the
amount of disk space that the hosted cache server can use for the hosted cache.
This procedure is optional. If the default cache location
(%windir%\ServiceProfiles\NetworkService\AppData\Local\PeerDistPub) and size – which is 5% of the total hard
disk space – are appropriate for your deployment, you do not need to change them.
You must be a member of the Administrators group to perform this procedure.
To move and resize the hosted cache
1. Open Windows PowerShell with Administrator privileges.
2. Type the following command to move the hosted cache to another location on the local computer, and then
press ENTER.

IMPORTANT
Before running the following command, replace parameter values, such as –Path and –MoveTo, with values that are
appropriate for your deployment.

Set-BCCache -Path C:\datacache –MoveTo D:\datacache

3. Type the following command to resize the hosted cache –specifically the datacache - on the local computer.
Press ENTER.

IMPORTANT
Before running the following command, replace parameter values, such as -Percentage, with values that are
appropriate for your deployment.

Set-BCCache -Percentage 20

4. To verify the hosted cache server configuration, type the following command and press ENTER.

Get-BCStatus

The results of the command display status for all aspects of your BranchCache installation. Following are a
few of the BranchCache settings and the correct value for each item:
DataCache | CacheFileDirectoryPath: Displays the hard disk location that matches the value you
provided with the –MoveTo parameter of the SetBCCache command. For example, if you provided the
value D:\datacache, that value is displayed in the command output.
 DataCache | MaxCacheSizeAsPercentageOfDiskVolume: Displays the number that matches the value
you provided with the –Percentage parameter of the SetBCCache command. For example, if you
provided the value 20, that value is displayed in the command output.
To continue with this guide, see Prehash and Preload Content on the Hosted Cache Server (Optional).
 Prehash and Preload Content on the Hosted Cache
Server (Optional)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

You can use the procedures in this section to prehash content on your content servers, add the content to data
packages, and then preload the content on your hosted cache servers.
These procedures are optional because you are not required to prehash and preload content on your hosted cache
servers.
If you do not preload content, data is added to the hosted cache automatically as clients download it over the WAN
connection.

IMPORTANT
Although these procedures are collectively optional, if you decide to prehash and preload content on your hosted cache
servers, performing both procedures is required.

Create Content Server Data Packages for Web and File Content (Optional)
Import Data Packages on the Hosted Cache Server (Optional)
To continue with this guide, see Create Content Server Data Packages for Web and File Content (Optional).
 Create Content Server Data Packages for Web and
File Content (Optional)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

You can use this procedure to prehash content on Web and file servers, and then create data packages to import on
your hosted cache server.
This procedure is optional because you are not required to prehash and preload content on your hosted cache
servers. If you do not preload content, data is added to the hosted cache automatically as clients download it over
the WAN connection.
This procedure provides instructions for prehashing content on both file servers and Web servers. If you do not
have one of those types of content servers, you do not have to perform the instructions for that content server
type.

IMPORTANT
Before you perform this procedure, you must install and configure BranchCache on your content servers. In addition, if you
plan on changing the server secret on a content server, do so before pre-hashing content – modifying the server secret
invalidates previously-generated hashes.

To perform this procedure, you must be a member of the Administrators group.

To create content server data packages

1. On each content server, locate the folders and files that you want to prehash and add to a data package.
Identify or create a folder where you want to save your data package later in this procedure.
2. On the server computer, open Windows PowerShell with Administrator privileges.
3. Do one or both of the following, depending on the types of content servers that you have:

NOTE
The value for the –Path parameter is the folder where your content is located. You must replace the example values in
the commands below with a valid folder location on your content server that contains data that you want to prehash
and add to a package.

If the content that you want to prehash is on a file server, type the following command, and then
press ENTER.

Publish-BCFileContent -Path D:\share -StageData

If the content that you want to prehash is on a Web server, type the following command, and then
press ENTER.
 Publish-BCWebContent –Path D:\inetpub\wwwroot -StageData

4. Create the data package by running the following command on each of your content servers. Replace the
example value (D:\temp) for the –Destination parameter with the location that you identified or created at
the beginning of this procedure.

Export-BCDataPackage –Destination D:\temp

5. From the content server, access the share on your hosted cache servers where you want to preload content,
and copy the data packages to the shares on the hosted cache servers.
To continue with this guide, see Import Data Packages on the Hosted Cache Server (Optional).
 Import Data Packages on the Hosted Cache Server
(Optional)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

You can use this procedure to import data packages and preload content on your hosted cache servers.
This procedure is optional because you are not required to prehash and preload content on your hosted cache
servers.
If you do not pre-load content, data is added to the hosted cache automatically as clients download it over the WAN
connection.
You must be a member of the Administrators group to perform this procedure.

To import data packages on the hosted cache server

1. On the server computer, open Windows PowerShell with Administrator privileges.
2. Type the following command, replacing the value for the –Path parameter with the folder location where you
have stored your data packages, and then press ENTER.

Import-BCCachePackage –Path D:\temp\PeerDistPackage.zip

3. If you have more than one hosted cache server where you want to preload content, perform this procedure
on each hosted cache server.
To continue with this guide, see Configure Client Automatic Hosted Cache Discovery by Service Connection Point.
 Configure Client Automatic Hosted Cache Discovery
by Service Connection Point
3/26/2020 • 3 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

With this procedure you can use Group Policy to enable and configure BranchCache hosted cache mode on
domain-joined computers that are running the following BranchCache-capable Windows operating systems.
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
Windows 8 Enterprise

NOTE
To configure domain-joined computers that are running Windows Server 2008 R2 or Windows 7, see the Windows Server
2008 R2 BranchCache Deployment Guide.

Membership in Domain Admins , or equivalent is the minimum required to perform this procedure.
To use Group Policy to configure clients for hosted cache mode
1. On a computer upon which the Active Directory Domain Services server role is installed, open Server
Manager, select the Local Server, click Tools , and then click Group Policy Management . The Group Policy
Management console opens.
2. In the Group Policy Management console, expand the following path: Forest: corp.contoso.com, Domains ,
corp.contoso.com, Group Policy Objects , where corp.contoso.com is the name of the domain where the
BranchCache client computer accounts that you want to configure are located.
3. Right-click Group Policy Objects , and then click New . The New GPO dialog box opens. In Name , type a
name for the new Group Policy object (GPO). For example, if you want to name the object BranchCache
Client Computers, type BranchCache Client Computers . Click OK .
4. In the Group Policy Management console, ensure that Group Policy Objects is selected, and in the details
pane right-click the GPO that you just created. For example, if you named your GPO BranchCache Client
Computers, right-click BranchCache Client Computers . Click Edit . The Group Policy Management Editor
console opens.
5. In the Group Policy Management Editor console, expand the following path: Computer Configuration ,
Policies , Administrative Templates: Policy definitions (ADMX files) retrieved from the local
computer , Network , BranchCache .
6. Click BranchCache , and then in the details pane, double-click Turn on BranchCache . The Turn on
BranchCache dialog box opens.
7. In the Turn on BranchCache dialog box, click Enabled , and then click OK .
8. In the Group Policy Management Editor console, ensure that BranchCache is still selected, and then in the
details pane double-click Enable Automatic Hosted Cache Discover y by Ser vice Connection Point .
 The policy setting dialog box opens.
9. In the Enable Automatic Hosted Cache Discover y by Ser vice Connection Point dialog box, click
Enabled , and then click OK .
10. To enable client computers to download and cache content from BranchCache file server-based content
servers: In the Group Policy Management Editor console, ensure that BranchCache is still selected, and then
in the details pane double-click BranchCache for network files . The Configure BranchCache for
network files dialog box opens.
11. In the Configure BranchCache for network files dialog box, click Enabled . In Options , type a numeric
value, in milliseconds, for the maximum round trip network latency time, and then click OK .

NOTE
By default, client computers cache content from file servers if the round trip network latency is longer than 80
milliseconds.

12. To configure the amount of hard disk space allocated on each client computer for the BranchCache cache: In
the Group Policy Management Editor console, ensure that BranchCache is still selected, and then in the
details pane double-click Set percentage of disk space used for client computer cache . The Set
percentage of disk space used for client computer cache dialog box opens. Click Enabled , and then
in Options type a numeric value that represents the percentage of hard disk space used on each client
computer for the BranchCache cache. Click OK .
13. To specify the default age, in days, for which segments are valid in the BranchCache data cache on client
computers: In the Group Policy Management Editor console, ensure that BranchCache is still selected, and
then in the details pane double-click Set age for segments in the data cache . The Set age for
segments in the data cache dialog box opens. Click Enabled , and then in the details pane type the
number of days that you prefer. Click OK .
14. Configure additional BranchCache policy settings for client computers as appropriate for your deployment.
15. Refresh Group Policy on branch office client computers by running the command gpupdate /force , or by
rebooting the client computers.
Your BranchCache Hosted Cache mode deployment is now complete.
For additional information on the technologies in this guide, see Additional Resources.
 BranchCache Additional Resources
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012

For more information about the technologies that are discussed in this guide, see the following resources:
BranchCache in Windows Server 2016
Install and Configure Content Servers
BranchCache Network Shell and Windows PowerShell Commands
Group Policy Overview for Windows Server 2012 R2
Windows Server 2008 R2 BranchCache Deployment Guide
 BranchCache
4/7/2020 • 31 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This topic, which is intended for Information Technology (IT) professionals, provides overview information about
BranchCache, including BranchCache modes, features, capabilities, and the BranchCache functionality that is
available in different operating systems.

NOTE
In addition to this topic, the following BranchCache documentation is available.
BranchCache Network Shell and Windows PowerShell Commands
BranchCache Deployment Guide

Who will be interested in BranchCache?

If you are a system administrator, network or storage solution architect, or other IT professional, BranchCache might
interest you under the following circumstances:
You design or support IT infrastructure for an organization that has two or more physical locations and a
wide area network (WAN) connection from the branch offices to the main office.
You design or support IT infrastructure for an organization that has deployed cloud technologies, and a WAN
connection is used by workers to access data and applications at remote locations.
You want to optimize WAN bandwidth usage by reducing the amount of network traffic between branch
offices and the main office.
You have deployed or are planning on deploying content servers at your main office that match the
configurations that are described in this topic.
The client computers in your branch offices are running Windows 10, Windows 8.1, Windows 8, or Windows
7.
This topic includes the following sections:
What is BranchCache?
BranchCache modes
BranchCache-enabled content servers
BranchCache and the cloud
Content information versions
How BranchCache handles content updates in files
BranchCache installation guide
Operating system versions for BranchCache
BranchCache security
 Content flow and processes
Cache Security

What is BranchCache?
BranchCache is a wide area network (WAN) bandwidth optimization technology that is included in some editions of
the Windows Server 2016 and Windows 10 operating systems, as well as in some editions of Windows Server
2012 R2, Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008 R2 and Windows 7. To optimize
WAN bandwidth when users access content on remote servers, BranchCache fetches content from your main office
or hosted cloud content servers and caches the content at branch office locations, allowing client computers at
branch offices to access the content locally rather than over the WAN.
At branch offices, content is stored either on servers that are configured to host the cache or, when no server is
available in the branch office, on client computers that are running Windows 10, Windows 8.1, Windows 8 or
Windows 7. After a client computer requests and receives content from the main office and the content is cached at
the branch office, other computers at the same branch office can obtain the content locally rather than downloading
the content from the content server over the WAN link.
When subsequent requests for the same content are made by client computers, the clients download content
information from the server instead of the actual content. Content information consists of hashes that are
calculated using chunks of the original content, and are extremely small compared to the content in the original
data. Client computers then use the content information to locate the content from a cache in the branch office,
whether the cache is located on a client computer or on a server. Client computers and servers also use content
information to secure cached content so that it cannot be accessed by unauthorized users.
BranchCache increases end user productivity by improving content query response times for clients and servers in
branch offices, and can also help improve network performance by reducing traffic over WAN links.

BranchCache modes
BranchCache has two modes of operation: distributed cache mode and hosted cache mode.
When you deploy BranchCache in distributed cache mode, the content cache at a branch office is distributed among
client computers.
When you deploy BranchCache in hosted cache mode, the content cache at a branch office is hosted on one or
more server computers, which are called hosted cache servers.

NOTE
You can deploy BranchCache using both modes, however only one mode can be used per branch office. For example, if you
have two branch offices, one which has a server and one which does not, you can deploy BranchCache in hosted cache mode
in the office that contains a server, while deploying BranchCache in distributed cache mode in the office that contains only
client computers.

In the following illustration, BranchCache is deployed in both modes.

Distributed cache mode is best suited for small branch offices that do not contain a local server for use as a hosted
cache server. Distributed cache mode allows you to deploy BranchCache with no additional hardware in branch
offices.
If the branch office where you want to deploy BranchCache contains additional infrastructure, such as one or more
servers that are running other workloads, deploying BranchCache in hosted cache mode is beneficial for the
following reasons:
Increased cache availability
Hosted cache mode increases the cache efficiency because content is available even if the client that originally
requested and cached the data is offline. Because the hosted cache server is always available, more content is
cached, providing greater WAN bandwidth savings, and BranchCache efficiency is improved.
Centralized caching for multiple -subnet branch offices
Distributed cache mode operates on a single subnet. At a multiple-subnet branch office that is configured for
distributed cache mode, a file downloaded to one subnet cannot be shared with client computers on other subnets.
Because of this, clients on other subnets, unable to discover that the file has already been downloaded, get the file
from the main office content server, using WAN bandwidth in the process.
When you deploy hosted cache mode, however, this is not the case - all clients in a multiple-subnet branch office
can access a single cache, which is stored on the hosted cache server, even if the clients are on different subnets. In
addition, BranchCache in Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012 provides the
ability to deploy more than one hosted cache server per branch office.
Cau t i on

If you use BranchCache for SMB caching of files and folders, do not disable Offline Files. If you disable Offline Files,
BranchCache SMB caching does not function correctly.

BranchCache-enabled content servers

When you deploy BranchCache, the source content is stored on BranchCache-enabled content servers in your main
office or in a cloud data center. The following types of content servers are supported by BranchCache:
 NOTE
Only source content - that is, content that client computers initially obtain from a BranchCache-enabled content server - is
accelerated by BranchCache. Content that client computers obtain directly from other sources, such as Web servers on the
Internet or Windows Update, is not cached by client computers or hosted cache servers and then shared with other
computers in the branch office. If you want to accelerate Windows Update content, however, you can install a Windows Server
Update Services (WSUS) application server at your main office or cloud data center and configure it as a BranchCache content
server.

Web servers
Supported Web servers include computers that are running Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012, or Windows Server 2008 R2 that have the Web Server (IIS) server role installed and that
use Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTPS).
In addition, the Web server must have the BranchCache feature installed.
File servers
Supported file servers include computers that are running Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012, or Windows Server 2008 R2 that have the File Services server role and the BranchCache for
Network Files role service installed.
These file servers use Server Message Block (SMB) to exchange information between computers. After you
complete installation of your file server, you must also share folders and enable hash generation for shared folders
by using Group Policy or Local Computer Policy to enable BranchCache.
Application servers
Supported application servers include computers that are running Windows Server 2016, Windows Server 2012
R2, Windows Server 2012, or Windows Server 2008 R2 with Background Intelligent Transfer Service (BITS) installed
and enabled.
In addition, the application server must have the BranchCache feature installed. As examples of application servers,
you can deploy Microsoft Windows Server Update Services (WSUS) and Microsoft Endpoint Configuration
Manager Branch Distribution Point servers as BranchCache content servers.

BranchCache and the cloud

The cloud has enormous potential to reduce operational expenses and achieve new levels of scale, but moving
workloads away from the people who depend on them can increase networking costs and hurt productivity. Users
expect high performance and don't care where their applications and data are hosted.
BranchCache can improve the performance of networked applications and reduce bandwidth consumption with a
shared cache of data. It improves productivity in branch offices and in headquarters, where workers are using
servers that are deployed in the cloud.
Because BranchCache does not require new hardware or network topology changes, it is an excellent solution for
improving communication between office locations and both public and private clouds.

NOTE
Because some Web proxies cannot process non-standard Content-Encoding headers, it is recommended that you use
BranchCache with Hyper Text Transfer Protocol Secure (HTTPS) and not HTTP.

======= For more information about cloud technologies in Windows Server 2016, see Software Defined
Networking (SDN).
Content information versions
There are two versions of content information:
Content information that is compatible with computers running Windows Server 2008 R2 and Windows 7 is
called version 1, or V1. With V1 BranchCache file segmentation, file segments are larger than in V2 and are
of fixed size. Because of large fixed segment sizes, when a user makes a change that modifies the file length,
not only is the segment with the change invalidated, but all of the segments to the end of the file are
invalidated. The next call for the changed file by another user in the branch office therefore results in reduced
WAN bandwidth savings because the changed content and all content after the change are sent over the
WAN link.
Content information that is compatible with computers running Windows Server 2016, Windows 10,
Windows Server 2012 R2, Windows 8.1, Windows Server 2012, and Windows 8 is called version 2, or V2. V2
content information uses smaller, variable-sized segments that are more tolerant to changes within a file.
This increases the probability that segments from an older version of the file can be reused when users
access an updated version, causing them to retrieve only the changed portion of the file from the content
server, and using less WAN bandwidth.
The following table provides information on the content information version that is used depending upon which
client, content server, and hosted cache server operating systems you are using in your BranchCache deployment.

NOTE
In the table below, the acronym "OS" means operating system.

C O N T EN T IN F O RM AT IO N
C L IEN T O S C O N T EN T SERVER O S H O ST ED C A C H E SERVER O S VERSIO N

Windows Server 2008 R2 Windows Server 2012 or Windows Server 2012 or V1

and Windows 7 later later; none for distributed
cache mode

Windows Server 2012 or Windows Server 2008 R2 Windows Server 2012 or V1

later; Windows 8 or later later; none for distributed
cache mode

Windows Server 2012 or Windows Server 2012 or Windows Server 2008 R2 V1

later; Windows 8 or later later

Windows Server 2012 or Windows Server 2012 or Windows Server 2012 or V2

later; Windows 8 or later later later; none for distributed
cache mode

When you have content servers and hosted cache servers that are running Windows Server 2016, Windows Server
2012 R2, and Windows Server 2012, they use the content information version that is appropriate based on the
operating system of the BranchCache client that requests information.
When computers running Windows Server 2012 and Windows 8 or later operating systems request content, the
content and hosted cache servers use V2 content information; when computers running Windows Server 2008 R2
and Windows 7 request content, the content and hosted cache servers use V1 content information.
 IMPORTANT
When you deploy BranchCache in distributed cache mode, clients that use different content information versions do not share
content with each other. For example, a client computer running Windows 7 and a client computer running Windows 10 that
are installed in the same branch office do not share content with each other.

How BranchCache handles content updates in files

When branch office users modify or update the contents of documents, their changes are written directly to the
content server in the main office without BranchCache's involvement. This is true whether the user downloaded the
document from the content server or obtained it from either a hosted or distributed cache in the branch office.
When the modified file is requested by a different client in a branch office, the new segments of the file are
downloaded from the main office server and added to the distributed or hosted cache in that branch. Because of
this, branch office users always receive the most recent versions of cached content.

BranchCache installation guide

You can use Server Manager in Windows Server 2016 to install either the BranchCache feature or the BranchCache
for Network Files role service of the File Services server role. You can use the following table to determine whether
to install the role service or the feature.

IN STA L L T H IS B RA N C H C A C H E
F UN C T IO N A L IT Y C O M P UT ER LO C AT IO N EL EM EN T

Content server (BITS-based application Main office or cloud data center BranchCache feature
server)

Content server (Web server) Main office or cloud data center BranchCache feature

Content server (file server using the Main office or cloud data center BranchCache for Network Files role
SMB protocol) service of the File Services server role

Hosted cache server Branch office BranchCache feature with hosted cache
server mode enabled

BranchCache-enabled client computer Branch office No installation needed; just enable

BranchCache and a BranchCache mode
(distributed or hosted) on the client

To install either the role service or the feature, open Server Manager and select the computers where you want to
enable BranchCache functionality. In Server Manager, click Manage , and then click Add Roles and Features . The
Add Roles and Features wizard opens. As you run the wizard, make the following selections:
On the wizard page Select Installation Type , select Role-based or Feature-based Installation .
On the wizard page Select Ser ver Roles , if you are installing a BranchCache-enabled file server, expand
File and Storage Ser vices and File and iSCSI Ser vices , and then select BranchCache for Network
Files . To save disk space, you can also select the Data Deduplication role service, and then continue
through the wizard to installation and completion. If you do not want to install a BranchCache-enabled file
server, do not install the File and Storage Services role with the BranchCache for Network Files role service.
On the wizard page Select features , if you are installing a content server that is not a file server or you are
installing a hosted cache server, select BranchCache , and then continue through the wizard to installation
and completion. If you do not want to install a content server other than a file server or a hosted cache
 server, do not install the BranchCache feature.

Operating system versions for BranchCache

Following is a list of operating systems that support different types of BranchCache functionality.
Operating systems for BranchCache client computer functionality
The following operating systems provide BranchCache with support for Background Intelligent Transfer Service
(BITS), Hyper Text Transfer Protocol (HTTP), and Server Message Block (SMB).
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
Windows 8 Enterprise
Windows 7 Enterprise
Windows 7 Ultimate
In the following operating systems, BranchCache does not support HTTP and SMB functionality, but does support
BranchCache BITS functionality.
Windows 10 Pro, BITS support only
Windows 8.1 Pro, BITS support only
Windows 8 Pro, BITS support only
Windows 7 Pro, BITS support only

NOTE
BranchCache is not available by default in the Windows Server 2008 or Windows Vista operating systems. On these operating
systems, however, if you download and install the Windows Management Framework update, BranchCache functionality is
available for the Background Intelligent Transfer Service (BITS) protocol only. For more information, and to download Windows
Management Framework, see Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0) at
https://go.microsoft.com/fwlink/?LinkId=188677.

Operating systems for BranchCache content server functionality

You can use the Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012 families of operating
systems as BranchCache content servers.
In addition, the Windows Server 2008 R2 family of operating systems can be used as BranchCache content servers,
with the following exceptions:
BranchCache is not supported in Server Core installations of Windows Server 2008 R2 Enterprise with
Hyper-V.
BranchCache is not supported in Server Core installations of Windows Server 2008 R2 Datacenter with
Hyper-V.
Operating systems for BranchCache hosted cache server functionality
You can use the Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012 families of operating
systems as BranchCache hosted cache servers.
In addition, the following Windows Server 2008 R2 operating systems can be used as BranchCache hosted cache
servers:
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Enterprise with Hyper-V
Windows Server 2008 R2 Enterprise Server Core Installation
Windows Server 2008 R2 Enterprise Server Core Installation with Hyper-V
Windows Server 2008 R2 for Itanium-Based Systems
Windows Server 2008 R2 Datacenter
Windows Server 2008 R2 Datacenter with Hyper-V
Windows Server 2008 R2 Datacenter Server Core Installation with Hyper-V

BranchCache Security
BranchCache implements a secure-by-design approach that works seamlessly alongside your existing network
security architectures, without the requirement for additional equipment or complex additional security
configuration.
BranchCache is non-invasive and does not alter any Windows authentication or authorization processes. After you
deploy BranchCache, authentication is still performed using domain credentials, and the way in which authorization
with Access Control Lists (ACLs) functions is unchanged. In addition, other configurations continue to function just
as they did before BranchCache deployment.
The BranchCache security model is based on the creation of metadata, which takes the form of a series of hashes.
These hashes are also called content information.
After content information is created, it is used in BranchCache message exchanges rather than the actual data, and it
is exchanged using the supported protocols (HTTP, HTTPS, and SMB).
Cached data is kept encrypted and cannot be accessed by clients that do not have permission to access content
from the original source. Clients must be authenticated and authorized by the original content source before they
can retrieve content metadata, and must possess content metadata to access the cache in the local office.
How BranchCache generates content information
Because content information is created from multiple elements, the value of the content information is always
unique. These elements are:
The actual content (such as Web pages or shared files) from which the hashes are derived.
Configuration parameters, such as the hashing algorithm and block size. To generate content information,
the content server divides the content into segments and then subdivides those segments into blocks.
BranchCache uses secure cryptographic hashes to identify and verify each block and segment, supporting
the SHA256 hash algorithm.
A server secret. All content servers must be configured with a server secret, which is a binary value of
arbitrary length.

NOTE
The use of a server secret ensures that client computers are not able to generate the content information themselves. This
prevents malicious users from using brute force attacks with BranchCache-enabled client computers to guess minor changes
in content across versions in situations in which the client had access to a previous version but does not have access to the
current version.
Content information details
BranchCache uses the server secret as a key in order to derive a content-specific hash that is sent to authorized
clients. Applying a hashing algorithm to the combined server secret and the Hash of Data generates this hash.
This hash is called the segment secret. BranchCache uses segment secrets to secure communications. In addition,
BranchCache creates a Block Hash List, which is list of hashed data blocks, and the Hash of Data, which is generated
by hashing the Block Hash List.
The content information includes the following:
The Block Hash List:
BlockHashi = Hash(dataBlocki) 1<=i<=n

The Hash of Data (HoD):

HoD = Hash(BlockHashList)

Segment Secret (Kp):

Kp = HMAC(Ks, HoD)

BranchCache uses the Peer Content Caching protocol and the Retrieval Framework protocol to implement the
processes that are required to ensure the secure caching and retrieval of data between content caches.
In addition, BranchCache handles content information with the same degree of security that it uses when handling
and transmitting the actual content itself.

Content flow and processes

The flow of content information and actual content is divided into four phases:
1. BranchCache processes: Request content
2. BranchCache processes: Locate content
3. BranchCache processes: Retrieve content
4. BranchCache processes: Cache content
The following sections describe these phases.

BranchCache processes: Request content

In the first phase, the client computer in the branch office requests content, such as a file or a Web page, from a
content server in a remote location, such as a main office. The content server verifies that the client computer is
authorized to receive the requested content. If the client computer is authorized and both content server and client
are BranchCache-enabled, the content server generates content information.
The content server then sends the content information to the client computer using the same protocol as would
have been used for the actual content.
For example, if the client computer requested a Web page over HTTP, the content server sends the content
information using HTTP. Because of this, the wire-level security guarantees of the content and the content
information are identical.
After the initial portion of content information (Hash of Data + Segment Secret) is received, the client computer
performs the following actions:
Uses the Segment Secret (Kp) as the encryption key (Ke).
 Generates the Segment ID (HoHoDk) from the HoD and Kp:
HoHoDk = HMAC(Kp, HoD + C), where C is the ASCII string "MS_P2P_CACHING" with NUL terminator.

The primary threat at this layer is the risk to the Segment Secret, however BranchCache encrypts the content data
blocks to protect the Segment Secret. BranchCache does this by using the encryption key that is derived from the
Segment Secret of the content segment within which the content blocks are located.
This approach ensures that an entity that is not in possession of the server secret cannot discover the actual content
in a data block. The Segment Secret is treated with the same degree of security as the plaintext segment itself,
because knowledge of the Segment Secret for a given segment enables an entity to obtain the segment from peers
and then decrypt it. Knowledge of the Server Secret does not immediately yield any particular plaintext but can be
used to derive certain types of data from the cipher text and then to possibly expose some partially known data to a
brute-force guessing attack. The server secret, therefore, should be kept confidential.

BranchCache processes: Locate content

After the content information is received by the client computer, the client uses the Segment ID to locate the
requested content in the local branch office cache, whether that cache is distributed between client computers or is
located on a hosted cache server.
If the client computer is configured for hosted cache mode, it is configured with the computer name of the hosted
cache server and contacts that server to retrieve the content.
If the client computer is configured for distributed cache mode, however, the content might be stored across
multiple caches on multiple computers in the branch office. The client computer must discover where the content is
located before the content is retrieved.
When they are configured for distributed cache mode, client computers locate content by using a discovery
protocol that is based on the Web Services Dynamic Discovery (WS-Discovery) protocol. Clients send WS-
Discovery multicast Probe messages to discover cached content over the network. Probe messages include the
Segment ID, which enables clients to check whether the requested content matches the content stored in their
cache. Clients that receive the initial Probe message reply to the querying client with unicast Probe-Match messages
if the Segment ID matches content that is cached locally.
The success of the WS-Discovery process depends on the fact that the client that is performing the discovery has
the correct content information, which was provided by the content server, for the content that it is requesting.
The main threat to data during the Request content phase is information disclosure, because access to the content
information implies authorized access to content. To mitigate this risk, the discovery process does not reveal the
content information, other than the Segment ID, which does not reveal anything about the plaintext segment that
contains the content.
In addition, another client computer run by a malicious user on the same network subnet can see the BranchCache
discovery traffic to the original content source going through the router.
If the requested content is not found in the branch office, the client requests the content directly from the content
server across the WAN link.
After the content is received, it is added to the local cache, either on the client computer or on a hosted cache server.
In this case, the content information prevents a client or hosted cache server from adding to the local cache any
content that does not match the hashes. The process of verifying content by matching hashes ensures that only
valid content is added to the cache, and the integrity of the local cache is protected.

BranchCache processes: Retrieve content

After a client computer locates the desired content on the content host, which is either a hosted cache server or a
distributed cache mode client computer, the client computer begins the process of retrieving the content.
First the client computer sends a request to the content host for the first block that it requires. The request contains
the Segment ID and block range that identify the desired content. Because only one block is returned, the block
range contains only a single block. (Requests for multiple blocks are currently not supported.) The client also stores
the request in its local Outstanding Request List.
Upon receiving a valid request message from a client, the content host checks whether the block specified in the
request exists in the content host's content cache.
If the content host is in possession of the content block, then the content host sends a response that contains the
Segment ID, the Block ID, the encrypted data block, and the initialization vector that is used for encrypting the block.
If the content host is not in possession of the content block, the content host sends an empty response message.
This informs the client computer that the content host does not have the requested block. An empty response
message contains the Segment ID and Block ID of the requested block, along with a zero-sized data block.
When the client computer receives the response from the content host, the client verifies that the message
corresponds to a request message in its Outstanding Request List. (The Segment ID and block index must match
that of an outstanding request.)
If this verification process is unsuccessful and the client computer does not have a corresponding request message
in its Outstanding Request List, the client computer discards the message.
If this verification process is successful and the client computer has a corresponding request message in its
Outstanding Request List, the client computer decrypts the block. The client then validates the decrypted block
against the appropriate block hash from the content information that the client initially obtained from the original
content server.
If the block validation is successful, the decrypted block is stored in the cache.
This process is repeated until the client has all of the required blocks.

NOTE
If the complete segments of content do not exist on one computer, the retrieval protocol retrieves and assembles content
from a combination of sources: a set of distributed cache mode client computers, a hosted cache server, and - if the branch
office caches do not contain the complete content - the original content server in the main office.

Before BranchCache sends content information or content, the data is encrypted. BranchCache encrypts the block in
the response message. In Windows 7, the default encryption algorithm that BranchCache uses is AES-128, the
encryption key is Ke, and the key size is 128 bits, as dictated by the encryption algorithm.
BranchCache generates an initialization vector that is suitable for the encryption algorithm and uses the encryption
key to encrypt the block. BranchCache then records the encryption algorithm and the initialization vector in the
message.
Servers and clients never exchange, share, or send each other the encryption key. The client receives the encryption
key from the content server that hosts the source content. Then, using the encryption algorithm and initialization
vector it received from the server, it decrypts the block. There is no other explicit authentication or authorization
built into the download protocol.
Security threats
The primary security threats at this layer include:
Tampering with data:
A client serving data to a requester tampers with the data. The BranchCache security model uses hashes to
 confirm that neither the client nor the server has altered the data.
Information disclosure:
BranchCache sends encrypted content to any client that specifies the appropriate Segment ID. Segment IDs
are public, so any client can receive encrypted content. However, if a malicious user obtains encrypted
content, they must know the encryption key to decrypt the content. The upper layer protocol performs
authentication and then gives the content information to the authenticated and authorized client. The
security of the content information is equivalent to the security provided to the content itself, and
BranchCache never exposes the content information.
An attacker sniffs the wire to obtain the content. BranchCache encrypts all transfers between clients by using
AES128 where the secret key is Ke, preventing data from being sniffed from the wire. Content information
that is downloaded from the content server is protected in exactly the same way as the data itself would have
been and is hence no more or less protected from information disclosure than if BranchCache had not been
used at all.
Denial of Service:
A client is overwhelmed by requests for data. BranchCache protocols incorporate queue management
counters and timers to prevent clients from being overloaded.

BranchCache processes: Cache content

On distributed cache mode client computers and hosted cache servers that are located in branch offices, content
caches are built up over time as content is retrieved over WAN links.
When client computers are configured with hosted cache mode, they add content to their own local cache and also
offer data to the hosted cache server. The Hosted Cache Protocol provides a mechanism for clients to inform the
hosted cache server about content and segment availability.
To upload content to the hosted cache server, the client informs the server that it has a segment that is available.
The hosted cache server then retrieves all of the content information that is associated with the offered segment,
and downloads the blocks within the segment that it actually needs. This process is repeated until the client has no
more segments to offer the hosted cache server.
To update the hosted cache server by using the Hosted Cache Protocol, the following requirements must be met:
The client computer is required to have a set of blocks within a segment that it can offer to the hosted cache
server. The client must supply content information for the offered segment; this is comprised of the Segment
ID, the segment Hash of Data, the Segment Secret, and a list of all block hashes that are contained within the
segment.
For hosted cache servers that are running Windows Server 2008 R2, a hosted cache server certificate and
associated private key are required, and the certification authority (CA) that issued the certificate must be
trusted by client computers in the branch office. This allows the client and server to participate successfully
in HTTPS Server authentication.

IMPORTANT
Hosted cache servers that are running Windows Server 2016, Windows Server 2012 R2 , or Windows Server 2012 do
not require a hosted cache server certificate and associated private key.

The client computer is configured with the computer name of the hosted cache server and the Transmission
Control Protocol (TCP) port number upon which the hosted cache server is listening for BranchCache traffic.
The hosted cache server's certificate is bound to this port. The computer name of the hosted cache server
can be a fully qualified domain name (FQDN), if the hosted cache server is a domain member computer; or it
 can be the NetBIOS name of the computer if the hosted cache server is not a domain member.
The client computer actively listens for incoming block requests. The port on which it is listening is passed as
part of the offer messages from the client to the hosted cache server. This enables the hosted cache server to
use BranchCache protocols to connect to the client computer to retrieve data blocks in the segment.
The hosted cache server starts to listen for incoming HTTP requests when it is initialized.
If the hosted cache server is configured to require client computer authentication, both the client and the
hosted cache server are required to support HTTPS authentication.
Hosted cache mode cache population
The process of adding content to the hosted cache server's cache in a branch office begins when the client sends an
INITIAL_OFFER_MESSAGE, which includes the Segment ID. The Segment ID in the INITIAL_OFFER_MESSAGE request
is used to retrieve the corresponding segment Hash of Data, list of block hashes, and the Segment Secret from the
hosted cache server's block cache. If the hosted cache server already has all the content information for a particular
segment, the response to the INITIAL_OFFER_MESSAGE will be OK, and no request to download blocks occurs.
If the hosted cache server does not have all of the offered data blocks that are associated with the block hashes in
the segment, the response to the INITIAL_OFFER_MESSAGE is INTERESTED. The client then sends a
SEGMENT_INFO_MESSAGE that describes the single segment that is being offered. The hosted cache server
responds with an OK message and initiates the download of the missing blocks from the offering client computer.
The segment Hash of Data, list of block hashes, and the segment secret are used to ensure that the content that is
being downloaded has not been tampered with or otherwise altered. The downloaded blocks are then added to the
hosted cache server's block cache.

Cache Security
This section provides information on how BranchCache secures cached data on client computers and on hosted
cache servers.
Client computer cache security
The greatest threat to data stored in the BranchCache is tampering. If an attacker can tamper with content and
content information that is stored in the cache, then it might be possible to use this to try and launch an attack
against the computers that are using BranchCache. Attackers can initiate an attack by inserting malicious software
in place of other data. BranchCache mitigates this threat by validating all content using block hashes found in the
content information. If an attacker attempts to tamper with this data, it is discarded and is replaced with valid data
from the original source.
A secondary threat to data stored in the BranchCache is information disclosure. In distributed cache mode, the client
caches only the content that it has requested itself; however, that data is stored in clear text, and might be at risk. To
help restrict cache access to the BranchCache Service only, the local cache is protected by file system permissions
that are specified in an ACL.
Although the ACL is effective in preventing unauthorized users from accessing the cache, it is possible for a user
with administrative privileges to gain access to the cache by manually changing the permissions that are specified
in the ACL. BranchCache does not protect against the malicious use of an administrative account.
Data that is stored in the content cache is not encrypted, so if data leakage is a concern, you can use encryption
technologies such as BitLocker or the Encrypting File System (EFS). The local cache that is used by BranchCache
does not increase the information disclosure threat borne by a computer in the branch office; the cache contains
only copies of files that reside unencrypted elsewhere on the disk.
Encrypting the entire disk is particularly important in environments in which the physical security of the clients is
difficult to ensure. For example, encrypting the entire disk helps to secure sensitive data on mobile computers that
might be removed from the branch office environment.
Hosted cache server cache security
In hosted cache mode, the greatest threat to the security of the hosted cache server is information disclosure.
BranchCache in a hosted cache environment behaves in a similar manner to distributed cache mode, with file
system permission protecting the cached data. The difference is that the hosted cache server stores all of the
content that any BranchCache-enabled computer in the branch office requests, rather than just the data that a single
client requests. The consequences of unauthorized intrusion into this cache could be much more serious, because
much more data is at risk.
In a hosted cache environment where the hosted cache server is running Windows Server 2008 R2, the use of
encryption technologies such as BitLocker or EFS is advisable if any of the clients in the branch office can access
sensitive data across the WAN link. It is also necessary to prevent physical access to the hosted cache, because disk
encryption works only when the computer is turned off when the attacker gains physical access. If the computer is
turned on or is in sleep mode, then disk encryption offers little protection.

NOTE
Hosted cache servers that are running Windows Server 2016, Windows Server 2012 R2, or Windows Server 2012 encrypt all
data in the cache by default, so the use of additional encryption technologies is not required.

Even if a client is configured in hosted cache mode, it will still cache data locally, and you might want to take steps to
protect the local cache in addition to the cache on the hosted cache server.
 BranchCache Network Shell and Windows PowerShell
Commands
4/7/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

In Windows Server 2016, you can configure and manage BranchCache by using either Windows PowerShell or the
Network Shell (Netsh) commands for BranchCache.
In future versions of Windows, Microsoft might remove the netsh functionality for BranchCache. Microsoft
recommends that you transition to Windows PowerShell if you currently use netsh to configure and manage
BranchCache and other networking technologies.
Windows PowerShell and netsh command references are at the following locations. Although both command
references were published for operating systems earlier than Windows Server 2016, these references are accurate
for this operating system.
Netsh Commands for BranchCache in Windows Server 2008 R2
BranchCache Cmdlets in Windows PowerShell

TIP
To view a list of Windows PowerShell commands for BranchCache at the Windows PowerShell prompt, type
Get-Command -Module BranchCache at the Windows PowerShell prompt, and then press ENTER.
 BranchCache Deployment Guide
3/26/2020 • 5 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this guide to learn how to deploy BranchCache in Windows Server 2016.
In addition to this topic, this guide contains the following sections.
Choosing a BranchCache Design
Deploy BranchCache

BranchCache Deployment Overview

BranchCache is a wide area network (WAN) bandwidth optimization technology that is included in some editions of
Windows Server 2016, Windows Server® 2012 R2, Windows Server® 2012, Windows Server® 2008 R2, and
related Windows client operating systems.
To optimize WAN bandwidth, BranchCache copies content from your main office content servers and caches the
content at branch office locations, allowing client computers at branch offices to access the content locally rather
than over the WAN.
At branch offices, content is cached either on servers that are running the BranchCache feature of Windows Server
2016, Windows Server 2012 R2 , Windows Server 2012 , or Windows Server 2008 R2 - or, if there are no servers
available in the branch office, content is cached on client computers that are running Windows 10®, Windows®
8.1, Windows 8, or Windows 7® .
After a client computer requests and receives content from the main office or cloud datacenter and the content is
cached at the branch office, other computers at the same branch office can obtain the content locally rather than
contacting the content server over the WAN link.
Benefits of deploying BranchCache
BranchCache caches file, web, and application content at branch office locations, allowing client computers to
access data using the local area network (LAN) rather than accessing the content over slow WAN connections.
BranchCache reduces both WAN traffic and the time that is required for branch office users to open files on the
network. BranchCache always provides users with the most recent data, and it protects the security of your content
by encrypting the caches on the hosted cache server and on client computers.
What this guide provides
This deployment guide allows you to deploy BranchCache in the following modes:
Distributed cache mode. In this mode, branch office client computers download content from the content
servers in the main office or cloud, and then cache the content for other computers in the same branch
office. Distributed cache mode does not require a server computer in the branch office.
Hosted cache mode. In this mode, branch office client computers download content from the content servers
in the main office or cloud, and a hosted cache server retrieves the content from the clients. The hosted
cache server then caches the content for other client computers.
This guide also provides instructions on how to deploy three types of content servers. Content servers contain the
source content that is downloaded by branch office client computers, and one or more content server is required to
deploy BranchCache in either mode. The content server types are:
Web ser ver-based content ser vers . These content servers send content to BranchCache client
computers using the HTTP and HTTPS protocols. These content servers must be running Windows Server
2016, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 versions that support
BranchCache and upon which the BranchCache feature is installed.
BITS-based application ser vers . These content servers send content to BranchCache client computers
using the Background Intelligent Transfer Service (BITS). These content servers must be running Windows
Server 2016, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 versions that
support BranchCache and upon which the BranchCache feature is installed.
File ser ver-based content ser vers . These content servers must be running Windows Server 2016,
Windows Server 2012 R2 , Windows Server 2012 , or Windows Server 2008 R2 versions that support
BranchCache and upon which the File Services server role is installed. In addition, the BranchCache for
network files role service of the File Services server role must be installed and configured. These content
servers send content to BranchCache client computers using the Server Message Block (SMB) protocol.
For more information, see Operating system versions for BranchCache.
BranchCache deployment requirements
Following are the requirements for deploying BranchCache by using this guide.
File and Web content ser vers must be running one of the following operating systems to provide
BranchCache functionality: Windows Server 2016, Windows Server 2012 R2 , Windows Server 2012 , or
Windows Server 2008 R2 . Windows 8 and later clients continue to see benefits from BranchCache when
accessing content servers that are running Windows Server 2008 R2 , however they are unable to make use
of the new chunking and hashing technologies in Windows Server 2016, Windows Server 2012 R2, and
Windows Server 2012.
Client computers must be running Windows 10, Windows 8.1, or Windows 8 to make use of the most
recent deployment model and the chunking and hashing improvements that were introduced with Windows
Server 2012 .
Hosted cache ser vers must be running Windows Server 2016, Windows Server 2012 R2, or Windows
Server 2012 to make use of the deployment improvements and scale features described in this document. A
computer that is running one of these operating systems that is configured as a hosted cache server can
continue to serve client computers that are running Windows 7 , but to do so, it must be equipped with a
certificate that is suitable for Transport Layer Security (TLS), as described in the Windows Server 2008 R2
and Windows 7 BranchCache Deployment Guide.
An Active Director y domain is required to take advantage of Group Policy and hosted cache automatic
discovery, but a domain is not required to use BranchCache. You can configure individual computers by
using Windows PowerShell. In addition, it is not required that your domain controllers are running Windows
Server 2012 or later to utilize new BranchCache Group Policy settings; you can import the BranchCache
administrative templates onto domain controllers that are running earlier operating systems, or you can
author the group policy objects remotely on other computers that are running Windows 10, Windows
Server 2016, Windows 8.1, Windows Server 2012 R2, Windows 8, or Windows Server 2012.
Active Director y sites are used to limit the scope of hosted cache servers that are automatically
discovered. To automatically discover a hosted cache server, both the client and server computers must
belong to the same site. BranchCache is designed to have a minimal impact on clients and servers and does
not impose additional hardware requirements beyond those needed to run their respective operating
systems.
BranchCache histor y and documentation
BranchCache was first introduced in Windows 7® and Windows Server® 2008 R2, and was improved in
Windows Server 2012, Windows 8, and later operating systems.

NOTE
If you are deploying BranchCache in operating systems other than Windows Server 2016, the following documentation
resources are available.
For information about BranchCache in Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2,
see BranchCache Overview.
For information about BranchCache in Windows 7 and Windows Server 2008 R2, see BranchCache for Windows Server
2008 R2.
 Choosing a BranchCache Design
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn about BranchCache modes and to select the best modes for your deployment.
You can use this guide to deploy BranchCache in the following modes and mode combinations.
All branch offices are configured for distributed cache mode.
All branch offices are configured for hosted cache mode and have a hosted cache server on site.
Some branch offices are configured for distributed cache mode and some branch offices have a hosted
cache server on site and are configured for hosted cache mode.
The following illustration depicts a dual mode installation, with one branch office configured for distributed cache
mode and one branch office configured for hosted cache mode.

Before you deploy BranchCache, select the mode you prefer for each branch office in your organization.
 Deploy BranchCache
4/7/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

The following sections provide information about deploying BranchCache in distributed and hosted cache modes.
Install and Configure Content Servers
Deploy Hosted Cache Servers (Optional)
Prehashing and Preloading Content on Hosted Cache Servers (Optional)
Configure BranchCache Client Computers

NOTE
The procedures in this guide do not include instructions for those cases in which the User Account Control dialog box
opens to request your permission to continue. If this dialog box opens while you are performing the procedures in this guide,
and if the dialog box was opened in response to your actions, click Continue .
 Install and Configure Content Servers
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

When you deploy BranchCache in distributed cache mode or hosted cache mode, you must deploy one or more
content servers at your main office or in the cloud. Content servers that are Web servers or application servers use
the BranchCache feature. Content servers that are file servers use the BranchCache for network files role service of
the File Services server role in Windows Server 2016.
See the following topics to deploy content servers.
Install Content Servers that Use the BranchCache Feature
Install File Services Content Servers
 Install Content Servers that Use the BranchCache
Feature
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

To deploy content servers that are Secure Hypertext Transfer Protocol (HTTPS) Web servers, Hypertext Transfer
Protocol (HTTP) Web servers, and Background Intelligent Transfer service (BITS)-based application servers, such as
Windows Server Update Services (WSUS) and Microsoft Endpoint Configuration Manager branch distribution site
system servers, you must install the BranchCache feature, start the BranchCache service, and (for WSUS servers
only) perform additional configuration steps.
See the following topics to deploy content servers.
Install the BranchCache Feature
Configure Windows Server Update Services (WSUS) Content Servers
 Install the BranchCache Feature
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to install the BranchCache feature and start the BranchCache service on a computer
running Windows Server® 2016, Windows Server 2012 R2, or Windows Server 2012.
Membership in Administrators or equivalent is the minimum required to perform this procedure.
Before you perform this procedure, it is recommended that you install and configure your BITS-based application
or Web server.

NOTE
To perform this procedure by using Windows PowerShell, run Windows PowerShell as an Administrator, type the following
commands at the Windows PowerShell prompt, and then press ENTER.
Install-WindowsFeature BranchCache

Restart-Computer

To install and enable the BranchCache feature

1. In Server Manager, click Manage , and then click Add Roles and Features . The Add Roles and Features
wizard opens. Click Next .
2. In Select installation type , ensure that Role-based or feature-based installation is selected, and then
click Next .
3. In Select destination ser ver , ensure that the correct server is selected, and then click Next .
4. In Select ser ver roles , click Next .
5. In Select features , click BranchCache , and then click Next .
6. In Confirm installation selections , click Install . In Installation progress , the BranchCache feature
installation proceeds. When installation is complete, click Close .
After you install the BranchCache feature, the BranchCache service - also called the PeerDistSvc - is enabled, and
the start type is Automatic.
 Configure Windows Server Update Services (WSUS)
Content Servers
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

After installing the BranchCache feature and starting the BranchCache service, WSUS servers must be configured
to store update files on the local computer.
When you configure WSUS servers to store update files on the local computer, both the update metadata and the
update files are downloaded by and stored directly upon the WSUS server. This ensures that BranchCache client
computers receive Microsoft product update files from the WSUS server rather than directly from the Microsoft
Update Web site.
For more information about WSUS synchronization, see Setting up Update Synchronizations
 Install File Services Content Servers
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

To deploy content servers that are running the File Services server role, you must install the BranchCache for
network files role service of the File Services server role. In addition, you must enable BranchCache on file shares
according to your requirements.
During the configuration of the content server, you can allow BranchCache publication of content for all file shares
or you can select a subset of file shares to publish.

NOTE
When you deploy a BranchCache enabled file server or Web server as a content server, content information is now calculated
offline, well before a BranchCache client requests a file. Because of this improvement, you do not need to configure hash
publication for content servers, as you did in the previous version of BranchCache.
This automatic hash generation provides faster performance and more bandwidth savings, because content information is
ready for the first client that requests the content, and calculations have already been performed.

See the following topics to deploy content servers.

Configure the File Services server role
Enable Hash Publication for File Servers
Enable BranchCache on a File Share (Optional)
 Configure the File Services server role
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can deploy BranchCache file server-based content servers on computers running Windows Server 2016 and
the File Services server role with the BranchCache for network files role service installed.
To install a BranchCache content server on a computer that does not already have File Services installed, see
Install a New File Server as a Content Server.
To install a BranchCache content server on a computer that is already configured with the File Services
server role, see Configure an Existing File Server as a Content Server.
 Install a New File Server as a Content Server
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to install the File Services server role and the BranchCache for Network Files role
service on a computer running Windows Server 2016.
Membership in Administrators , or equivalent is the minimum required to perform this procedure.

NOTE
To perform this procedure by using Windows PowerShell, run Windows PowerShell as an Administrator, type the following
commands at the Windows PowerShell prompt, and then press ENTER.
Install-WindowsFeature FS-BranchCache -IncludeManagementTools

Restart-Computer

To install the Data Deduplication role service, type the following command, and then press ENTER.
Install-WindowsFeature FS-Data-Deduplication -IncludeManagementTools

To install File Services and the BranchCache for network files role service
1. In Server Manager, click Manage , and then click Add Roles and Features . The Add Roles and Features
Wizard opens. In Before you begin , click Next .
2. In Select installation type , ensure that Role-based or feature-based installation is selected, and then
click Next .
3. In Select destination ser ver , ensure that the correct server is selected, and then click Next .
4. In Select ser ver roles , in Roles , note that the File And Storage Ser vices role is already installed; click
the arrow to the left of the role name to expand the selection of role services, and then click the arrow to the
left of File and iSCSI Ser vices .
5. Select the check boxes for File Ser ver and BranchCache for Network Files .

TIP
It is recommended that you also select the check box for Data Deduplication .

Click Next .
6. In Select features , click Next .
7. In Confirm installation selections , review your selections, and then click Install . The Installation
progress pane is displayed during installation. When installation is complete, click Close .
 Configure an Existing File Server as a Content Server
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to install the BranchCache for Network Files role service of the File Services server
role on a computer running Windows Server 2016.

IMPORTANT
If the File Services server role is not already installed, do not follow this procedure. Instead, see Install a New File Server as a
Content Server.

Membership in Administrators , or equivalent is the minimum required to perform this procedure.

NOTE
To perform this procedure by using Windows PowerShell, run Windows PowerShell as an Administrator, type the following
commands at the Windows PowerShell prompt, and then press ENTER.
Install-WindowsFeature FS-BranchCache -IncludeManagementTools

To install the Data Deduplication role service, type the following command, and then press ENTER.
Install-WindowsFeature FS-Data-Deduplication -IncludeManagementTools

To install the BranchCache for Network Files role service

1. In Server Manager, click Manage , and then click Add Roles and Features . The Add Roles and Features
wizard opens. Click Next .
2. In Select installation type , ensure that Role-based or feature-based installation is selected, and then
click Next .
3. In Select destination ser ver , ensure that the correct server is selected, and then click Next .
4. In Select ser ver roles , in Roles , note that the File And Storage Ser vices role is already installed; click
the arrow to the left of the role name to expand the selection of role services, and then click the arrow to the
left of File and iSCSI Ser vices .
5. Select the check box for BranchCache for Network Files .

TIP
If you have not already done so, it is recommended that you also select the check box for Data Deduplication .

Click Next .
6. In Select features , click Next .
7. In Confirm installation selections , review your selections, and then click Install . The Installation
progress pane is displayed during installation. When installation is complete, click Close .
 Enable Hash Publication for File Servers
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can enable BranchCache hash publication on one file server or on multiple file servers.
To enable hash publication on one file server using local computer Group Policy, see Enable Hash Publication
for Non-Domain Member File Servers.
To enable hash publication on multiple file servers using domain Group Policy, see Enable Hash Publication
for Domain Member File Servers.

NOTE
If you have multiple file servers and you want to enable hash publication per share, rather than enabling hash publication for
all shares, you can use the instructions in the topic Enable Hash Publication for Non-Domain Member File Servers.
 Enable Hash Publication for Non-Domain Member
File Servers
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to configure hash publication for BranchCache using local computer Group Policy on a
file server that is running Windows Server 2016 with the BranchCache for Network Files role service of the File
Services server role installed.
This procedure is intended for use on a non-domain member file server. If you perform this procedure on a domain
member file server and you also configure BranchCache using domain Group Policy, domain Group Policy settings
override local Group Policy settings.
Membership in Administrators , or equivalent is the minimum required to perform this procedure.

NOTE
If you have one or more domain member file servers, you can add them to an organizational unit (OU) in Active Directory
Domain Services and then use Group Policy to configure hash publication for all of the file servers at one time, rather than
individually configuring each file server. For more information, see Enable Hash Publication for Domain Member File Servers.

To enable hash publication for one file server

1. Open Windows PowerShell, type mmc , and then press ENTER. The Microsoft Management Console (MMC)
opens.
2. In the MMC, on the File menu, click Add/Remove Snap-in . The Add or Remove Snap-ins dialog box
opens.
3. In Add or Remove Snap-ins , in Available snap-ins , double-click Group Policy Object Editor . The
Group Policy Wizard opens with the Local Computer object selected. Click Finish , and then click OK .
4. In the Local Group Policy Editor MMC, expand the following path: Local Computer Policy , Computer
Configuration , Administrative Templates , Network , Lanman Ser ver . Click Lanman Ser ver .
5. In the details pane, double-click Hash Publication for BranchCache . The Hash Publication for
BranchCache dialog box opens.
6. In the Hash Publication for BranchCache dialog box, click Enabled .
7. In Options , click Allow hash publication for all shared folders , and then click one of the following:
a. To enable hash publication for all shared folders on this computer, click Allow hash publication for
all shared folders .
b. To enable hash publication only for shared folders for which BranchCache is enabled, click Allow
hash publication only for shared folders on which BranchCache is enabled .
c. To disallow hash publication for all shared folders on the computer even if BranchCache is enabled on
the file shares, click Disallow hash publication on all shared folders .
8. Click OK .
 Enable Hash Publication for Domain Member File
Servers
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

When you're using Active Directory Domain Services (AD DS), you can use domain Group Policy to enable
BranchCache hash publication for multiple file servers. To do so, you must create an organizational unit (OU), add
file servers to the OU, create a BranchCache hash publication Group Policy Object (GPO), and then configure the
GPO.
See the following topics to enable hash publication for multiple file servers.
Create the BranchCache File Servers Organizational Unit
Move File Servers to the BranchCache File Servers Organizational Unit
Create the BranchCache Hash Publication Group Policy Object
Configure the BranchCache Hash Publication Group Policy Object
 Create the BranchCache File Servers Organizational
Unit
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to create an organizational unit (OU) in Active Directory Domain Services (AD DS) for
BranchCache file servers.
Membership in Domain Admins , or equivalent is the minimum required to perform this procedure.
To create the BranchCache file servers organizational unit
1. On a computer where AD DS is installed, in Server Manager, click Tools , and then click Active Director y
Users and Computers . The Active Directory Users and Computers console opens.
2. In the Active Directory Users and Computers console, right-click the domain to which you want to add an
OU. For example, if your domain is named example.com, right click example.com . Point to New , and then
click Organizational Unit . The New Object - Organizational Unit dialog box opens.
3. In the New Object - Organizational Unit dialog box, in Name , type a name for the new OU. For example,
if you want to name the OU BranchCache file servers, type BranchCache file ser vers , and then click OK .
 Move File Servers to the BranchCache File Servers
Organizational Unit
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to add BranchCache file servers to an organizational unit (OU) in Active Directory
Domain Services (AD DS).
Membership in Domain Admins , or equivalent is the minimum required to perform this procedure.

NOTE
You must create a BranchCache file servers OU in the Active Directory Users and Computers console before you add
computer accounts to the OU with this procedure. For more information, see Create the BranchCache File Servers
Organizational Unit.

To move file servers to the BranchCache file servers organizational unit

1. On a computer where AD DS is installed, in Server Manager, click Tools , and then click Active Director y
Users and Computers . The Active Directory Users and Computers console opens.
2. In the Active Directory Users and Computers console, locate the computer account for a BranchCache file
server, left-click to select the account, and then drag and drop the computer account on the BranchCache file
servers OU that you previously created. For example, if you previously created an OU named BranchCache
file ser vers , drag and drop the computer account on the BranchCache file ser vers OU.
3. Repeat the previous step for each BranchCache file server in the domain that you want to move to the OU.
 Create the BranchCache Hash Publication Group
Policy Object
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to create the BranchCache hash publication Group Policy Object (GPO).
Membership in Domain Admins , or equivalent is the minimum required to perform this procedure.

NOTE
Before performing this procedure, you must create the BranchCache file servers organizational unit and move file servers into
the OU. For more information, see Enable Hash Publication for Domain Member File Servers.

To create the BranchCache hash publication Group Policy Object

1. Open Windows PowerShell, type mmc , and then press ENTER. The Microsoft Management Console (MMC)
opens.
2. In the MMC, on the File menu, click Add/Remove Snap-in . The Add or Remove Snap-ins dialog box
opens.
3. In Add or Remove Snap-ins , in Available snap-ins , double-click Group Policy Management , and then
click OK .
4. In the Group Policy Management MMC, expand the path to the BranchCache file servers OU that you
previously created. For example, if your forest is named example.com, your domain is named example1.com,
and your OU is named BranchCache file servers, expand the following path: Group Policy Management ,
Forest: example.com , Domains , example1.com , BranchCache file ser vers .
5. Right-click BranchCache file ser vers , and then click Create a GPO in this domain, and Link it here .
The New GPO dialog box opens. In Name , type a name for the new GPO. For example, if you want to name
the object BranchCache Hash Publication, type BranchCache Hash Publication . Click OK .
 Configure the BranchCache Hash Publication Group
Policy Object
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to configure the BranchCache hash publication Group Policy Object (GPO) so that all file
servers that you added to your OU have the same hash publication policy setting applied to them.
Membership in Domain Admins , or equivalent is the minimum required to perform this procedure.

NOTE
Before performing this procedure, you must create the BranchCache file servers organizational unit, move file servers into the
OU, and create the BranchCache hash publication GPO. For more information, see Enable Hash Publication for Domain
Member File Servers.

To configure the BranchCache hash publication Group Policy Object

1. Run Windows PowerShell as an Administrator, type mmc , and then press ENTER. The Microsoft
Management Console (MMC) opens.
2. In the MMC, on the File menu, click Add/Remove Snap-in . The Add or Remove Snap-ins dialog box
opens.
3. In Add or Remove Snap-ins , in Available snap-ins , double-click Group Policy Management , and then
click OK .
4. In the Group Policy Management MMC, expand the path to the BranchCache hash publication GPO that you
previously created. For example, if your forest is named example.com, your domain is named example1.com,
and your GPO is named BranchCache Hash Publication , expand the following path: Group Policy
Management , Forest: example.com , Domains , example1.com , Group Policy Objects , BranchCache
Hash Publication .
5. Right-click the BranchCache Hash Publication GPO and click Edit . The Group Policy Management Editor
console opens.
6. In the Group Policy Management Editor console, expand the following path: Computer Configuration ,
Policies , Administrative Templates , Network , Lanman Ser ver .
7. In the Group Policy Management Editor console, click Lanman Ser ver . In the details pane, double-click
Hash Publication for BranchCache . The Hash Publication for BranchCache dialog box opens.
8. In the Hash Publication for BranchCache dialog box, click Enabled .
9. In Options , click Allow hash publication for all shared folders , and then click one of the following:
a. To enable hash publication for all shared folders for all file servers that you added to the OU, click
Allow hash publication for all shared folders .
b. To enable hash publication only for shared folders for which BranchCache is enabled, click Allow
hash publication only for shared folders on which BranchCache is enabled .
 c. To disallow hash publication for all shared folders on the computer even if BranchCache is enabled on
the file shares, click Disallow hash publication on all shared folders .
10. Click OK .

NOTE
In most cases, you must save the MMC console and refresh the view to display the configuration changes you have made.
 Enable BranchCache on a File Share (Optional)
4/7/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to enable BranchCache on a file share.

IMPORTANT
You do not need to perform this procedure if you configure the hash publication setting with the value Allow hash
publication for all shared folders .

Membership in Administrators , or equivalent is the minimum required to perform this procedure.

To enable BranchCache on a file share
1. Open Windows PowerShell, type mmc , and then press ENTER. The Microsoft Management Console (MMC)
opens.
2. In the MMC, on the File menu, click Add/Remove Snap-in . The Add or Remove Snap-ins dialog box
opens.
3. In Add or Remove Snap-ins , in Available snap-ins , double-click Shared Folders . The Shared Folders
Wizard opens with the Local Computer object selected. Configure the View that you prefer, click Finish , and
then click OK .
4. Double-click Shared Folders (Local) , and then click Shares .
5. In the details pane, right-click a share, and then click Proper ties . The share's Proper ties dialog box opens.
6. In the Proper ties dialog box, on the General tab, click Offline Settings . The Offline Settings dialog box
opens.
7. Ensure that Only the files and programs that users specify are available offline is selected, and then
click Enable BranchCache .
8. Click OK twice.
 Deploy Hosted Cache Servers (Optional)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to install and configure BranchCache hosted cache servers that are located in branch
offices where you want to deploy BranchCache hosted cache mode. With BranchCache in Windows Server 2016,
you can deploy multiple hosted cache servers in one branch office.

IMPORTANT
This step is optional because distributed cache mode does not require a hosted cache server computer in branch offices. If
you are not planning on deploying hosted cache mode in any branch offices, you do not need to deploy a hosted cache
server, and you do not need to perform the steps in this procedure.

You must be a member of Administrators , or equivalent to perform this procedure.

To install and configure a hosted cache server
1. On the computer that you want to configure as a hosted cache server, run the following command at a
Windows PowerShell prompt to install the BranchCache feature.
Install-WindowsFeature BranchCache -IncludeManagementTools

2. Configure the computer as a hosted cache server by using one of the following commands:
To configure a non-domain joined computer as a hosted cache server, type the following command at
the Windows PowerShell prompt, and then press ENTER.
Enable-BCHostedServer

To configure a domain joined computer as a hosted cache server, and to register a service connection
point in Active Directory for automatic hosted cache server discovery by client computers, type the
following command at the Windows PowerShell prompt, and then press ENTER.
Enable-BCHostedServer -RegisterSCP

3. To verify the correct configuration of the hosted cache server, type the following command at the Windows
PowerShell prompt, and then press ENTER.
Get-BCStatus

NOTE
After you run this command, in the section HostedCacheSer verConfiguration , the value for
HostedCacheSer verIsEnabled is True . If you configured a domain joined hosted cache server to register a service
connection point (SCP) in Active Directory, the value for HostedCacheScpRegistrationEnabled is True .
 Prehashing and Preloading Content on Hosted Cache
Servers (Optional)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to force the creation of content information - also called hashes - on BranchCache-
enabled Web and file servers. You can also gather the data on file and web servers into packages that can be
transferred to remote hosted cache servers. This provides you with the ability to preload content on remote hosted
cache servers so that data is available for the first client access.
You must be a member of Administrators , or equivalent to perform this procedure.
To prehash content and preload the content on hosted cache servers
1. Log on to the file or Web server that contains the data that you wish to preload, and identify the folders and
files that you wish to load on one or more remote hosted cache servers.
2. Run Windows PowerShell as an Administrator. For each folder and file, run either the Publish-BCFileContent
command or the Publish-BCWebContent command, depending on the type of content server, to trigger hash
generation and to add data to a data package.
3. After all the data has been added to the data package, export it by using the Export-BCCachePackage
command to produce a data package file.
4. Move the data package file to the remote hosted cache servers by using your choice of file transfer
technology. FTP, SMB, HTTP, DVD and portable hard disks are all viable transports.
5. Import the data package file on the remote hosted cache servers by using the Import-BCCachePackage
command.
 Configure BranchCache Client Computers
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use the following topics to configure domain member and non-domain member client computers as
BranchCache distributed cache or hosted cache mode clients.
Use Group Policy to Configure Domain Member Client Computers
Use Windows PowerShell to Configure Non-Domain Member Client Computers
Configure Firewall Rules for Non-Domain Members to Allow BranchCache Traffic
Verify Client Computer Settings
 Use Group Policy to Configure Domain Member
Client Computers
3/26/2020 • 4 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

In this section, you create a Group Policy Object for all of the computers in your organization, configure domain
member client computers with distributed cache mode or hosted cache mode, and configure Windows Firewall
with Advanced Security to allow BranchCache traffic.
This section contains the following procedures.
1. To create a Group Policy Object and configure BranchCache modes
2. To configure Windows Firewall with Advanced Security Inbound Traffic Rules
3. To configure Windows Firewall with Advanced Security Outbound Traffic Rules

TIP
In the following procedure, you are instructed to create a Group Policy Object in the Default Domain Policy, however, you can
create the object in an organizational unit (OU) or other container that is appropriate for your deployment.

You must be a member of Domain Admins , or equivalent to perform these procedures.

To create a Group Policy Object and configure BranchCache modes

1. On a computer upon which the Active Directory Domain Services server role is installed, in Server Manager,
click Tools , and then click Group Policy Management . The Group Policy Management console opens.
2. In the Group Policy Management console, expand the following path: Forest: example.com, Domains ,
example.com, Group Policy Objects , where example.com is the name of the domain where the
BranchCache client computer accounts that you want to configure are located.
3. Right-click Group Policy Objects , and then click New . The New GPO dialog box opens. In Name , type a
name for the new Group Policy Object (GPO). For example, if you want to name the object BranchCache
Client Computers, type BranchCache Client Computers . Click OK .
4. In the Group Policy Management console, ensure that Group Policy Objects is selected, and in the details
pane right-click the GPO that you just created. For example, if you named your GPO BranchCache Client
Computers, right-click BranchCache Client Computers . Click Edit . The Group Policy Management Editor
console opens.
5. In the Group Policy Management Editor console, expand the following path: Computer Configuration ,
Policies , Administrative Templates: Policy definitions (ADMX files) retrieved from the local
computer , Network , BranchCache .
6. Click BranchCache , and then in the details pane, double-click Turn on BranchCache . The policy setting
dialog box opens.
7. In the Turn on BranchCache dialog box, click Enabled , and then click OK .
 8. To enable BranchCache distributed cache mode, in the details pane, double-click Set BranchCache
Distributed Cache mode . The policy setting dialog box opens.
9. In the Set BranchCache Distributed Cache mode dialog box, click Enabled , and then click OK .
10. If you have one or more branch offices where you are deploying BranchCache in hosted cache mode, and
you have deployed hosted cache servers in those offices, double-click Enable Automatic Hosted Cache
Discover y by Ser vice Connection Point . The policy setting dialog box opens.
11. In the Enable Automatic Hosted Cache Discover y by Ser vice Connection Point dialog box, click
Enabled , and then click OK .

NOTE
When you enable both the Set BranchCache Distributed Cache mode and the Enable Automatic Hosted
Cache Discover y by Ser vice Connection Point policy settings, client computers operate in BranchCache
distributed cache mode unless they find a hosted cache server in the branch office, at which point they operate in
hosted cache mode.

12. Use the procedures below to configure firewall settings on client computers by using Group Policy.

To configure Windows Firewall with Advanced Security Inbound Traffic

Rules
1. In the Group Policy Management console, expand the following path: Forest: example.com, Domains ,
example.com, Group Policy Objects , where example.com is the name of the domain where the
BranchCache client computer accounts that you want to configure are located.
2. In the Group Policy Management console, ensure that Group Policy Objects is selected, and in the details
pane right-click the BranchCache client computers GPO that you created previously. For example, if you
named your GPO BranchCache Client Computers, right-click BranchCache Client Computers . Click Edit .
The Group Policy Management Editor console opens.
3. In the Group Policy Management Editor console, expand the following path: Computer Configuration ,
Policies , Windows Settings , Security Settings , Windows Firewall with Advanced Security ,
Windows Firewall with Advanced Security - LDAP , Inbound Rules .
4. Right-click Inbound Rules , and then click New Rule . The New Inbound Rule Wizard opens.
5. In Rule Type , click Predefined , expand the list of choices, and then click BranchCache - Content
Retrieval (Uses HTTP) . Click Next .
6. In Predefined Rules , click Next .
7. In Action , ensure that Allow the connection is selected, and then click Finish .

IMPORTANT
You must select Allow the connection for the BranchCache client to be able to receive traffic on this port.

8. To create the WS-Discovery firewall exception, again right-click Inbound Rules , and then click New Rule .
The New Inbound Rule Wizard opens.
9. In Rule Type , click Predefined , expand the list of choices, and then click BranchCache - Peer Discover y
(Uses WSD) . Click Next .
10. In Predefined Rules , click Next .
11. In Action , ensure that Allow the connection is selected, and then click Finish .

IMPORTANT
You must select Allow the connection for the BranchCache client to be able to receive traffic on this port.

To configure Windows Firewall with Advanced Security Outbound Traffic

Rules
1. In the Group Policy Management Editor console, right-click Outbound Rules , and then click New Rule . The
New Outbound Rule Wizard opens.
2. In Rule Type , click Predefined , expand the list of choices, and then click BranchCache - Content
Retrieval (Uses HTTP) . Click Next .
3. In Predefined Rules , click Next .
4. In Action , ensure that Allow the connection is selected, and then click Finish .

IMPORTANT
You must select Allow the connection for the BranchCache client to be able to send traffic on this port.

5. To create the WS-Discovery firewall exception, again right-click Outbound Rules , and then click New Rule .
The New Outbound Rule Wizard opens.
6. In Rule Type , click Predefined , expand the list of choices, and then click BranchCache - Peer Discover y
(Uses WSD) . Click Next .
7. In Predefined Rules , click Next .
8. In Action , ensure that Allow the connection is selected, and then click Finish .

IMPORTANT
You must select Allow the connection for the BranchCache client to be able to send traffic on this port.
 Use Windows PowerShell to Configure Non-Domain
Member Client Computers
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to manually configure a BranchCache client computer for distributed cache mode or
hosted cache mode.

NOTE
If you have configured BranchCache client computers using Group Policy, the Group Policy settings override any manual
configuration of client computers to which the policies are applied.

Membership in Administrators , or equivalent is the minimum required to perform this procedure.

To enable BranchCache distributed or hosted cache mode
1. On the BranchCache client computer that you want to configure, run Windows PowerShell as an
Administrator, and then do one of the following.
To configure the client computer for BranchCache distributed cache mode, type the following
command, and then press ENTER.
Enable-BCDistributed

To configure the client computer for BranchCache hosted cache mode, type the following command,
and then press ENTER.
Enable-BCHostedClient

TIP
If you want to specify the available hosted cache servers, use the -ServerNames parameter with a comma
separated list of your hosted cache servers as the parameter value. For example, if you have two hosted cache
servers named HCS1 and HCS2, configure the client computer for hosted cache mode with the following
command.
Enable-BCHostedClient -ServerNames HCS1,HCS2
 Configure Firewall Rules for Non-Domain Members
to Allow BranchCache Traffic
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use the information in this topic to configure third party firewall products and to manually configure a
client computer with firewall rules that allow BranchCache to run in distributed cache mode.

NOTE
If you have configured BranchCache client computers using Group Policy, the Group Policy settings override any manual
configuration of client computers to which the policies are applied.
If you have deployed BranchCache with DirectAccess, you can use the settings in this topic to configure IPsec rules to
allow BranchCache traffic.

Membership in Administrators , or equivalent is the minimum required to make these configuration changes.

[MS-PCCRD]: Peer Content Caching and Retrieval Discovery Protocol

Distributed cache clients must allow inbound and outbound MS-PCCRD traffic, which is carried in the Web Services
Dynamic Discovery (WS-Discovery) protocol.
Firewall settings must allow multicast traffic in addition to inbound and outbound traffic. You can use the following
settings to configure firewall exceptions for distributed cache mode.
IPv4 multicast: 239.255.255.250
IPv6 multicast: FF02::C
Inbound traffic: Local port: 3702, Remote port: ephemeral
Outbound traffic: Local port: ephemeral, Remote port: 3702
Program: %systemroot%\system32\svchost.exe (BranchCache Service [PeerDistSvc])

[MS-PCCRR]: Peer Content Caching and Retrieval: Retrieval Protocol

Distributed cache clients must allow inbound and outbound MS-PCCRR traffic, which is carried in the HTTP 1.1
protocol as documented in request for comments (RFC) 2616.
Firewall settings must allow inbound and outbound traffic. You can use the following settings to configure firewall
exceptions for distributed cache mode.
Inbound traffic: Local port: 80, Remote port: ephemeral
Outbound traffic: Local port: ephemeral, Remote port: 80
 Verify Client Computer Settings
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this procedure to verify that the client computer is correctly configured for BranchCache.

NOTE
This procedure includes steps for manually updating Group Policy and for restarting the BranchCache service. You do not
need to perform these actions if you reboot the computer, as they will occur automatically in this circumstance.

You must be a member of Administrators , or equivalent to perform this procedure.

To verify BranchCache client computer settings
1. To refresh Group Policy on the client computer whose BranchCache configuration you want to verify, run
Windows PowerShell as an Administrator, type the following command, and then press ENTER.
gpupdate /force

2. For client computers that are configured in hosted cache mode and are configured to automatically discover
hosted cache servers by service connection point, run the following commands to stop and restart the
BranchCache service.
net stop peerdistsvc

net start peerdistsvc

3. Inspect the current BranchCache operational mode by running the following command.
Get-BCStatus

4. In Windows PowerShell, review the output of the Get-BCStatus command.

The value for BranchCacheIsEnabled should be True .
In ClientSettings , the value for CurrentClientMode should be DistributedClient or
HostedCacheClient , depending on the mode that you configured using this guide.
In ClientSettings , if you configured hosted cache mode and provided the names of your hosted cache
servers during configuration, or if the client has automatically located hosted cache servers using service
connection points, HostedCacheSer verList should have a value that is the same as the name or names of
your hosted cache servers. For example, if your hosted cache server is named HCS1 and your domain is
corp.contoso.com, the value for HostedCacheSer verList is HCS1.corp.contoso.com .
5. If any of the BranchCache settings listed above do not have the correct values, use the steps in this guide to
verify the Group Policy or Local Computer Policy settings, as well as the firewall exceptions, that you
configured, and ensure that they are correct. In addition, either restart the computer or follow the steps in
this procedure to refresh Group Policy and restart the BranchCache service.
 DirectAccess
4/7/2020 • 2 minutes to read • Edit Online

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

In Windows Server 2016, DirectAccess and VPN is a role service of the Remote Access server role.
DirectAccess allows connectivity for remote users to organization network resources without the need for
traditional Virtual Private Network (VPN) connections.
DirectAccess documentation is now located in the Remote access and server management section of the Windows
Server 2016 table of contents, under Remote Access. For more information, see DirectAccess.
 Domain Name System (DNS)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Domain Name System (DNS) is one of the industry-standard suite of protocols that comprise TCP/IP, and together
the DNS Client and DNS Server provide computer name-to-IP address mapping name resolution services to
computers and users.

NOTE
In addition to this topic, the following DNS content is available.
What's New in DNS Client
What's New in DNS Server
DNS Policy Scenario Guide
Video: Windows Server 2016: DNS management in IPAM

In Windows Server 2016, DNS is a server role that you can install by using Server Manager or Windows
PowerShell commands. If you are installing a new Active Directory forest and domain, DNS is automatically
installed with Active Directory as the Global Catalogue server for the forest and domain.
Active Directory Domain Services (AD DS) uses DNS as its domain controller location mechanism. When any of the
principal Active Directory operations is performed, such as authentication, updating, or searching, computers use
DNS to locate Active Directory domain controllers. In addition, domain controllers use DNS to locate each other.
The DNS Client service is included in all client and server versions of the Windows operating system, and is
running by default upon operating system installation. When you configure a TCP/IP network connection with the
IP address of a DNS server, the DNS Client queries the DNS server to discover domain controllers, and to resolve
computer names to IP addresses. For example, when a network user with an Active Directory user account logs in
to an Active Directory domain, the DNS Client service queries the DNS server to locate a domain controller for the
Active Directory domain. When the DNS server responds to the query and provides the domain controller's IP
address to the client, the client contacts the domain controller and the authentication process can begin.
The Windows Server 2016 DNS Server and DNS Client services use the DNS protocol that is included in the TCP/IP
protocol suite. DNS is part of the application layer of the TCP/IP reference model, as shown in the following
illustration.
 What's New in DNS Client in Windows Server 2016
6/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This topic describes the Domain Name System (DNS) client functionality that is new or changed in Windows 10
and Windows Server 2016 and later versions of these operating systems.

Updates to DNS Client

DNS Client ser vice binding : In Windows 10, the DNS Client service offers enhanced support for computers
with more than one network interface. For multi-homed computers, DNS resolution is optimized in the following
ways:
When a DNS server that is configured on a specific interface is used to resolve a DNS query, the DNS Client
service will bind to this interface before sending the DNS query.
By binding to a specific interface, the DNS client can clearly specify the interface where name resolution
occurs, enabling applications to optimize communications with the DNS client over this network interface.
If the DNS server that is used is designated by a Group Policy setting from the Name Resolution Policy Table
(NRPT), the DNS Client service does not bind to a specific interface.

NOTE
Changes to the DNS Client service in Windows 10 are also present in computers running Windows Server 2016 and later
versions.

Additional References
What's New in DNS Server in Windows Server 2016
 What's New in DNS Server in Windows Server
6/26/2020 • 8 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This topic describes the Domain Name System (DNS) server functionality that is new or changed in Windows
Server 2016.
In Windows Server 2016, DNS Server offers enhanced support in the following areas.

F UN C T IO N A L IT Y N EW O R IM P RO VED DESC RIP T IO N

DNS Policies New You can configure DNS policies to

specify how a DNS server responds to
DNS queries. DNS responses can be
based on client IP address (location),
time of the day, and several other
parameters. DNS policies enable
location-aware DNS, traffic
management, load balancing, split-brain
DNS, and other scenarios.

Response Rate Limiting (RRL) New You can enable response rate limiting
on your DNS servers. By doing this, you
avoid the possibility of malicious
systems using your DNS servers to
initiate a denial of service attack on a
DNS client.

DNS-based Authentication of Named New You can use TLSA (Transport Layer
Entities (DANE) Security Authentication) records to
provide information to DNS clients that
state what CA they should expect a
certificate from for your domain name.
This prevents man-in-the-middle
attacks where someone might corrupt
the DNS cache to point to their own
website, and provide a certificate they
issued from a different CA.

Unknown record support New You can add records which are not
explicitly supported by the Windows
DNS server using the unknown record
functionality.

IPv6 root hints New You can use the native IPV6 root hints
support to perform internet name
resolution using the IPV6 root servers.

Windows PowerShell Support Improved New Windows PowerShell cmdlets are

available for DNS Server.

DNS Policies
You can use DNS Policy for Geo-Location based traffic management, intelligent DNS responses based on the time
of day, to manage a single DNS server configured for split-brain deployment, applying filters on DNS queries, and
more. The following items provide more detail about these capabilities.
Application Load Balancing. When you have deployed multiple instances of an application at different
locations, you can use DNS policy to balance the traffic load between the different application instances,
dynamically allocating the traffic load for the application.
Geo-Location Based Traffic Management. You can use DNS Policy to allow primary and secondary
DNS servers to respond to DNS client queries based on the geographical location of both the client and the
resource to which the client is attempting to connect, providing the client with the IP address of the closest
resource.
Split Brain DNS. With split-brain DNS, DNS records are split into different Zone Scopes on the same DNS
server, and DNS clients receive a response based on whether the clients are internal or external clients. You
can configure split-brain DNS for Active Directory integrated zones or for zones on standalone DNS
servers.
Filtering. You can configure DNS policy to create query filters that are based on criteria that you supply.
Query filters in DNS policy allow you to configure the DNS server to respond in a custom manner based on
the DNS query and DNS client that sends the DNS query.
Forensics. You can use DNS policy to redirect malicious DNS clients to a non-existent IP address instead of
directing them to the computer they are trying to reach.
Time of day based redirection. You can use DNS policy to distribute application traffic across different
geographically distributed instances of an application by using DNS policies that are based on the time of
day.
You can also use DNS policies for Active Directory integrated DNS zones.
For more information, see the DNS Policy Scenario Guide.

Response Rate Limiting

You can configure RRL settings to control how to respond to requests to a DNS client when your server receives
several requests targeting the same client. By doing this, you can prevent someone from sending a Denial of
Service (Dos) attack using your DNS servers. For instance, a bot net can send requests to your DNS server using
the IP address of a third computer as the requestor. Without RRL, your DNS servers might respond to all the
requests, flooding the third computer. When you use RRL, you can configure the following settings:
Responses per second . This is the maximum number of times the same response will be given to a client
within one second.
Errors per second . This is the maximum number of times an error response will be sent to the same client
within one second.
Window . This is the number of seconds for which responses to a client will be suspended if too many
requests are made.
Leak rate . This is how frequently the DNS server will respond to a query during the time responses are
suspended. For instance, if the server suspends responses to a client for 10 seconds, and the leak rate is 5,
the server will still respond to one query for every 5 queries sent. This allows the legitimate clients to get
responses even when the DNS server is applying response rate limiting on their subnet or FQDN.
TC rate . This is used to tell the client to try connecting with TCP when responses to the client are
suspended. For instance, if the TC rate is 3, and the server suspends responses to a given client, the server
will issue a request for TCP connection for every 3 queries received. Make sure the value for TC rate is lower
 than the leak rate, to give the client the option to connect via TCP before leaking responses.
Maximum responses . This is the maximum number of responses the server will issue to a client while
responses are suspended.
White list domains . This is a list of domains to be excluded from RRL settings.
White list subnets . This is a list of subnets to be excluded from RRL settings.
White list ser ver interfaces . This is a list of DNS server interfaces to be excluded from RRL settings.

DANE support
You can use DANE support (RFC 6394 and 6698) to specify to your DNS clients what CA they should expect
certificates to be issued from for domains names hosted in your DNS server. This prevents a form of man-in-the-
middle attack where someone is able to corrupt a DNS cache and point a DNS name to their own IP address.
For instance, imagine you host a secure website that uses SSL at www.contoso.com by using a certificate from a
well-known authority named CA1. Someone might still be able to get a certificate for www.contoso.com from a
different, not-so-well-known, certificate authority named CA2. Then, the entity hosting the fake www.contoso.com
website might be able to corrupt the DNS cache of a client or server to point www.contoto.com to their fake site.
The end user will be presented a certificate from CA2, and may simply acknowledge it and connect to the fake site.
With DANE, the client would make a request to the DNS server for contoso.com asking for the TLSA record and
learn that the certificate for www.contoso.com was issues by CA1. If presented with a certificate from another CA,
the connection is aborted.

Unknown record support

An "Unknown Record" is an RR whose RDATA format is not known to the DNS server. The newly added support for
unknown record (RFC 3597) types means that you can add the unsupported record types into the Windows DNS
server zones in the binary on-wire format. The windows caching resolver already has the ability to process
unknown record types. Windows DNS server will not do any record specific processing for the unknown records,
but will send it back in responses if queries are received for it.

IPv6 root hints

The IPV6 root hints, as published by IANA, have been added to the windows DNS server. The internet name
queries can now use IPv6 root servers for performing name resolutions.

Windows PowerShell support

The following new Windows PowerShell cmdlets and parameters are introduced in Windows Server 2016.
Add-DnsSer verRecursionScope . This cmdlet creates a new recursion scope on the DNS server.
Recursion scopes are used by DNS policies to specify a list of forwarders to be used in a DNS query.
Remove-DnsSer verRecursionScope . This cmdlet removes existing recursion scopes.
Set-DnsSer verRecursionScope . This cmdlet changes the settings of an existing recursion scope.
Get-DnsSer verRecursionScope . This cmdlet retrieves information about existing recursion scopes.
Add-DnsSer verClientSubnet . This cmdlet creates a new DNS client subnet. Subnets are used by DNS
policies to identify where a DNS client is located.
Remove-DnsSer verClientSubnet . This cmdlet removes existing DNS client subnets.
Set-DnsSer verClientSubnet . This cmdlet changes the settings of an existing DNS client subnet.
 Get-DnsSer verClientSubnet . This cmdlet retrieves information about existing DNS client subnets.
Add-DnsSer verQuer yResolutionPolicy . This cmdlet creates a new DNS query resolution policy. DNS
query resolution policies are used to specify how, or if, a query is responded to, based on different criteria.
Remove-DnsSer verQuer yResolutionPolicy . This cmdlet removes existing DNS policies.
Set-DnsSer verQuer yResolutionPolicy . This cmdlet changes the settings of an existing DNS policy.
Get-DnsSer verQuer yResolutionPolicy . This cmdlet retrieves information about existing DNS policies.
Enable-DnsSer verPolicy . This cmdlet enables existing DNS policies.
Disable-DnsSer verPolicy . This cmdlet disables existing DNS policies.
Add-DnsSer verZoneTransferPolicy . This cmdlet creates a new DNS server zone transfer policy. DNS
zone transfer policies specify whether to deny or ignore a zone transfer based on different criteria.
Remove-DnsSer verZoneTransferPolicy . This cmdlet removes existing DNS server zone transfer policies.
Set-DnsSer verZoneTransferPolicy . This cmdlet changes settings of an existing DNS server zone transfer
policy.
Get-DnsSer verResponseRateLimiting . This cmdlet retrieves RRL settings.
Set-DnsSer verResponseRateLimiting . This cmdlet changes RRL settigns.
Add-DnsSer verResponseRateLimitingExceptionlist . This cmdlet creates an RRL exception list on the
DNS server.
Get-DnsSer verResponseRateLimitingExceptionlist . This cmdlet retrieves RRL excception lists.
Remove-DnsSer verResponseRateLimitingExceptionlist . This cmdlet removes an existing RRL
exception list.
Set-DnsSer verResponseRateLimitingExceptionlist . This cmdlet changes RRL exception lists.
Add-DnsSer verResourceRecord . This cmdlet was updated to support unknown record type.
Get-DnsSer verResourceRecord . This cmdlet was updated to support unknown record type.
Remove-DnsSer verResourceRecord . This cmdlet was updated to support unknown record type.
Set-DnsSer verResourceRecord . This cmdlet was updated to support unknown record type
For more information, see the following Windows Server 2016 Windows PowerShell command reference topics.
DnsServer Module
DnsClient Module

Additional References
What's New in DNS Client
 DNS Policy Scenario Guide
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This guide is intended for use by DNS, network, and systems administrators.
DNS Policy is a new feature for DNS in Windows Server® 2016. You can use this guide to learn how to use DNS
policy to control how a DNS server processes name resolution queries based on different parameters that you
define in policies.
This guide contains DNS policy overview information, as well as specific DNS policy scenarios that provide you
with instructions on how to configure DNS server behavior to accomplish your goals, including geo-location based
traffic management for primary and secondary DNS servers, application high availability, split-brain DNS, and
more.
This guide contains the following sections.
DNS Policies Overview
Use DNS Policy for Geo-Location Based Traffic Management with Primary Servers
Use DNS Policy for Geo-Location Based Traffic Management with Primary-Secondary Deployments
Use DNS Policy for Intelligent DNS Responses Based on the Time of Day
DNS Responses Based on Time of Day with an Azure Cloud App Server
Use DNS Policy for Split-Brain DNS Deployment
Use DNS Policy for Split-Brain DNS in Active Directory
Use DNS Policy for Applying Filters on DNS Queries
Use DNS Policy for Application Load Balancing
Use DNS Policy for Application Load Balancing With Geo-Location Awareness
 DNS Policies Overview
3/26/2020 • 11 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn about DNS Policy, which is new in Windows Server 2016. You can use DNS Policy for
Geo-Location based traffic management, intelligent DNS responses based on the time of day, to manage a single
DNS server configured for split-brain deployment, applying filters on DNS queries, and more. The following items
provide more detail about these capabilities.
Application Load Balancing. When you have deployed multiple instances of an application at different
locations, you can use DNS policy to balance the traffic load between the different application instances,
dynamically allocating the traffic load for the application.
Geo-Location Based Traffic Management. You can use DNS Policy to allow primary and secondary DNS
servers to respond to DNS client queries based on the geographical location of both the client and the
resource to which the client is attempting to connect, providing the client with the IP address of the closest
resource.
Split Brain DNS. With split-brain DNS, DNS records are split into different Zone Scopes on the same DNS
server, and DNS clients receive a response based on whether the clients are internal or external clients. You
can configure split-brain DNS for Active Directory integrated zones or for zones on standalone DNS servers.
Filtering. You can configure DNS policy to create query filters that are based on criteria that you supply.
Query filters in DNS policy allow you to configure the DNS server to respond in a custom manner based on
the DNS query and DNS client that sends the DNS query.
Forensics. You can use DNS policy to redirect malicious DNS clients to a non-existent IP address instead of
directing them to the computer they are trying to reach.
Time of day based redirection. You can use DNS policy to distribute application traffic across different
geographically distributed instances of an application by using DNS policies that are based on the time of
day.

New Concepts
In order to create policies to support the scenarios listed above, it is necessary to be able to identify groups of
records in a zone, groups of clients on a network, among other elements. These elements are represented by the
following new DNS objects:
Client subnet: a client subnet object represents an IPv4 or IPv6 subnet from which queries are submitted
to a DNS server. You can create subnets to later define policies to be applied based on what subnet the
requests come from. For instance, in a split brain DNS scenario, the request for resolution for a name such
as www.microsoft.com can be answered with an internal IP address to clients from internal subnets, and a
different IP address to clients in external subnets.
Recursion scope: recursion scopes are unique instances of a group of settings that control recursion on a
DNS server. A recursion scope contains a list of forwarders and specifies whether recursion is enabled. A
DNS server can have many recursion scopes. DNS server recursion policies allow you to choose a recursion
scope for a set of queries. If the DNS server is not authoritative for certain queries, DNS server recursion
policies allow you to control how to resolve those queries. You can specify which forwarders to use and
whether to use recursion.
 Zone scopes: a DNS zone can have multiple zone scopes, with each zone scope containing their own set of
DNS records. The same record can be present in multiple scopes, with different IP addresses. Also, zone
transfers are done at the zone scope level. That means that records from a zone scope in a primary zone will
be transferred to the same zone scope in a secondary zone.

Types of Policy
DNS Policies are divided by level and type. You can use Query Resolution Policies to define how queries are
processed, and Zone Transfer Policies to define how zone transfers occur. You can apply Each policy type at the
server level or the zone level.
Query Resolution Policies
You can use DNS Query Resolution Policies to specify how incoming resolution queries are handled by a DNS
server. Every DNS Query Resolution Policy contains the following elements:

F IEL D DESC RIP T IO N P O SSIB L E VA L UES

Name Policy name - Up to 256 characters

- Can contain any character valid for a
file name

State Policy state - Enable (default)

- Disabled

Level Policy level - Server

- Zone

Processing order Once a query is classified by level and - Numeric value

applies on, the server finds the first - Unique value per policy containing the
policy for which the query matches the same level and applies on value
criteria and applies it to query

Action Action to be performed by DNS server - Allow (default for zone level)
- Deny (default on server level)
- Ignore

Criteria Policy condition (AND/OR) and list of - Condition operator (AND/OR)

criterion to be met for policy to be - List of criteria (see the criterion table
applied below)

Scope List of zone scopes and weighted values - List of zone scopes (by name) and
per scope. Weighted values are used for weights
load balancing distribution. For
instance, if this list includes datacenter1
with a weight of 3 and datacenter2 with
a weight of 5 the server will respond
with a record from datacentre1 three
times out of eight requests

NOTE
Server level policies can only have the values Deny or Ignore as an action.

The DNS policy criteria field is composed of two elements:

 NAME DESC RIP T IO N SA M P L E VA L UES

Client Subnet Name of a predefined client subnet. - EQ,Spain,France - resolves to true if

Used to verify the subnet from which the subnet is identified as either Spain
the query was sent. or France
- NE,Canada,Mexico - resolves to
true if the client subnet is any subnet
other than Canada and Mexico

Transpor t Protocol Transport protocol used in the query. - EQ,TCP

Possible entries are UDP and TCP - EQ,UDP

Internet Protocol Network protocol used in the query. - EQ,IPv4

Possible entries are IPv4 and IPv6 - EQ,IPv6

Ser ver Interface IP address IP address for the incoming DNS server - EQ,10.0.0.1
network interface - EQ,192.168.1.1

FQDN FQDN of record in the query, with the - EQ,www.contoso.com - resolves to

possibility of using a wild card true only the if the query is trying to
resolve the www.contoso.com FQDN
-
EQ,*.contoso.com,*.woodgrove.co
m - resolves to true if the query is for
any record ending in
contoso.comORwoodgrove.com

Quer y Type Type of record being queried (A, SRV, - EQ,TXT,SRV - resolves to true if the
TXT) query is requesting a TXT OR SRV
record
- EQ,MX - resolves to true if the query
is requesting an MX record

Time of Day Time of day the query is received - EQ,10:00-12:00,22:00-23:00 -

resolves to true if the query is received
between 10 AM and noon, OR between
10PM and 11PM

Using the table above as a starting point, the table below could be used to define a criterion that is used to match
queries for any type of records but SRV records in the contoso.com domain coming from a client in the 10.0.0.0/24
subnet via TCP between 8 and 10 PM through interface 10.0.0.3:

NAME VA L UE

Client Subnet EQ,10.0.0.0/24

Transport Protocol EQ,TCP

Server Interface IP address EQ,10.0.0.3

FQDN EQ,*.contoso.com

Query Type NE,SRV

Time of Day EQ,20:00-22:00

You can create multiple query resolution policies of the same level, as long as they have a different value for the
processing order. When multiple policies are available, the DNS server processes incoming queries in the following
manner:

Recursion Policies
Recursion policies are a special type of server level policies. Recursion policies control how the DNS server
performs recursion for a query. Recursion policies apply only when query processing reaches the recursion path.
You can choose a value of DENY or IGNORE for recursion for a set of queries. Alternatively, you can choose a set of
forwarders for a set of queries.
You can use recursion policies to implement a Split-brain DNS configuration. In this configuration, the DNS server
performs recursion for a set of clients for a query, while the DNS server does not perform recursion for other
clients for that query.
Recursion policies contains the same elements a regular DNS query resolution policy contains, along with the
elements in the table below:

NAME DESC RIP T IO N

Apply on recursion Specifies that this policy should only be used for recursion.

Recursion Scope Name of the recursion scope.

NOTE
Recursion policies can only be created at the server level.

Zone Transfer Policies

Zone transfer policies control whether a zone transfer is allowed or not by your DNS server. You can create policies
for zone transfer at either the server level or the zone level. Server level policies apply on every zone transfer
query that occurs on the DNS server. Zone level policies apply only on the queries on a zone hosted on the DNS
server. The most common use for zone level policies is to implement blocked or safe lists.

NOTE
Zone transfer policies can only use DENY or IGNORE as actions.

You can use the server level zone transfer policy below to deny a zone transfer for the contoso.com domain from a
given subnet:

Add-DnsServerZoneTransferPolicy -Name DenyTransferOfContosoToFabrikam -Zone contoso.com -Action DENY -

ClientSubnet "EQ,192.168.1.0/24"

You can create multiple zone transfer policies of the same level, as long as they have a different value for the
processing order. When multiple policies are available, the DNS server processes incoming queries in the following
manner:
Managing DNS Policies
You can create and manage DNS Policies by using PowerShell. The examples below go through different sample
scenarios that you can configure through DNS Policies:
Traffic Management
You can direct traffic based on an FQDN to different servers depending on the location of the DNS client. The
example below shows how to create traffic management policies to direct the customers from a certain subnet to a
North American datacenter and from another subnet to a European datacenter.

Add-DnsServerClientSubnet -Name "NorthAmericaSubnet" -IPv4Subnet "172.21.33.0/24"

Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "172.17.44.0/24"
Add-DnsServerZoneScope -ZoneName "Contoso.com" -Name "NorthAmericaZoneScope"
Add-DnsServerZoneScope -ZoneName "Contoso.com" -Name "EuropeZoneScope"
Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "www" -IPv4Address "172.17.97.97" -ZoneScope
"EuropeZoneScope"
Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "www" -IPv4Address "172.21.21.21" -ZoneScope
"NorthAmericaZoneScope"
Add-DnsServerQueryResolutionPolicy -Name "NorthAmericaPolicy" -Action ALLOW -ClientSubnet
"eq,NorthAmericaSubnet" -ZoneScope "NorthAmericaZoneScope,1" -ZoneName "Contoso.com"
Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -
ZoneScope "EuropeZoneScope,1" -ZoneName contoso.com

The first two lines of the script create client subnet objects for North America and Europe. The two lines after that
create a zone scope within the contoso.com domain, one for each region. The two lines after that create a record in
each zone that associates ww.contoso.com to different IP address, one for Europe, another one for North America.
Finally, the last lines of the script create two DNS Query Resolution Policies, one to be applied to the North America
subnet, another to the Europe subnet.
Block queries for a domain
You can use a DNS Query Resolution Policy to block queries to a domain. The example below blocks all queries to
treyresearch.net:

Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"

Block queries from a subnet

You can also block queries coming from a specific subnet. The script below creates a subnet for 172.0.33.0/24 and
then creates a policy to ignore all queries coming from that subnet:

Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet 172.0.33.0/24

Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicyMalicious06" -Action IGNORE -ClientSubnet
"EQ,MaliciousSubnet06"

Allow recursion for internal clients

You can control recursion by using a DNS Query Resolution Policy. The sample below can be used to enable
recursion for internal clients, while disabling it for external clients in a split brain scenario.

Set-DnsServerRecursionScope -Name . -EnableRecursion $False

Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope
"InternalClients" -ServerInterfaceIP "EQ,10.0.0.34"

The first line in the script changes the default recursion scope, simply named as "." (dot) to disable recursion. The
second line creates a recursion scope named InternalClients with recursion enabled. And the third line creates a
policy to apply the newly create recursion scope to any queries coming in through a server interface that has
10.0.0.34 as an IP address.
Create a server level zone transfer policy
You can control zone transfer in a more granular form by using DNS Zone Transfer policies. The sample script
below can be used to allow zone transfers for any server on a given subnet:

Add-DnsServerClientSubnet -Name "AllowedSubnet" -IPv4Subnet 172.21.33.0/24

Add-DnsServerZoneTransferPolicy -Name "NorthAmericaPolicy" -Action IGNORE -ClientSubnet "ne,AllowedSubnet"

The first line in the script creates a subnet object named AllowedSubnet with the IP block 172.21.33.0/24. The
second line creates a zone transfer policy to allow zone transfers to any DNS server on the subnet previously
created.
Create a zone level zone transfer policy
You can also create zone level zone transfer policies. The example below ignores any request for a zone transfer for
contoso.com coming in from a server interface that has an IP address of 10.0.0.33:

Add-DnsServerZoneTransferPolicy -Name "InternalTransfers" -Action IGNORE -ServerInterfaceIP "eq,10.0.0.33" -

PassThru -ZoneName "contoso.com"

DNS Policy Scenarios

For information on how to use DNS policy for specific scenarios, see the following topics in this guide.
Use DNS Policy for Geo-Location Based Traffic Management with Primary Servers
Use DNS Policy for Geo-Location Based Traffic Management with Primary-Secondary Deployments
Use DNS Policy for Intelligent DNS Responses Based on the Time of Day
DNS Responses Based on Time of Day with an Azure Cloud App Server
Use DNS Policy for Split-Brain DNS Deployment
Use DNS Policy for Split-Brain DNS in Active Directory
Use DNS Policy for Applying Filters on DNS Queries
Use DNS Policy for Application Load Balancing
Use DNS Policy for Application Load Balancing With Geo-Location Awareness

Using DNS Policy on Read-Only Domain Controllers

DNS Policy is compatible with Read-Only Domain Controllers. Do note that a restart of the DNS Server service is
required for new DNS Policies to be loaded on Read-Only Domain Controllers. This is not necessary on writable
domain controllers.
 Use DNS Policy for Geo-Location Based Traffic
Management with Primary Servers
3/26/2020 • 8 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn how to configure DNS Policy to allow primary DNS servers to respond to DNS client
queries based on the geographical location of both the client and the resource to which the client is attempting to
connect, providing the client with the IP address of the closest resource.

IMPORTANT
This scenario illustrates how to deploy DNS policy for geo-location based traffic management when you are using only
primary DNS servers. You can also accomplish geo-location based traffic management when you have both primary and
secondary DNS servers. If you have a primary-secondary deployment, first complete the steps in this topic, and then
complete the steps that are provided in the topic Use DNS Policy for Geo-Location Based Traffic Management with Primary-
Secondary Deployments.

With new DNS policies, you can create a DNS policy that allows the DNS server to respond to a client query asking
for the IP address of a Web server. Instances of the Web server might be located in different datacenters at
different physical locations. DNS can assess the client and Web server locations, then respond to the client request
by providing the client with a Web server IP address for a Web server that is physically located closer to the client.
You can use the following DNS policy parameters to control the DNS server responses to queries from DNS
clients.
Client Subnet . Name of a predefined client subnet. Used to verify the subnet from which the query was sent.
Transpor t Protocol . Transport protocol used in the query. Possible entries are UDP and TCP .
Internet Protocol . Network protocol used in the query. Possible entries are IPv4 and IPv6 .
Ser ver Interface IP address . IP address of the network interface of the DNS server which received the DNS
request.
FQDN . The Fully Qualified Domain Name (FQDN) of the record in the query, with the possibility of using a wild
card.
Quer y Type . Type of record being queried (A, SRV, TXT, etc.).
Time of Day . Time of day the query is received.
You can combine the following criteria with a logical operator (AND/OR) to formulate policy expressions. When
these expressions match, the policies are expected to perform one of the following actions.
Ignore . The DNS server silently drops the query.
Deny . The DNS server responds that query with a failure response.
Allow . The DNS server responds back with traffic managed response.

Geo-Location Based Traffic Management Example

Following is an example of how you can use DNS policy to achieve traffic redirection on the basis of the physical
location of the client that performs a DNS query.
This example uses two fictional companies - Contoso Cloud Services, which provides web and domain hosting
solutions; and Woodgrove Food Services, which provides food delivery services in multiple cities across the globe,
and which has a Web site named woodgrove.com.
Contoso Cloud Services has two datacenters, one in the U.S. and another in Europe. The European datacenter hosts
a food ordering portal for woodgrove.com.
To ensure that woodgrove.com customers get a responsive experience from their website, Woodgrove wants
European clients directed to the European datacenter and American clients directed to the U.S. datacenter.
Customers located elsewhere in the world can be directed to either of the datacenters.
The following illustration depicts this scenario.

How the DNS name resolution process works

During the name resolution process, the user tries to connect to www.woodgrove.com. This results in a DNS name
resolution request that is sent to the DNS server that is configured in the Network Connection properties on the
user's computer. Typically, this is the DNS server provided by the local ISP acting as a caching resolver, and is
referred as the LDNS.
If the DNS name is not present in the local cache of LDNS, the LDNS server forwards the query to the DNS server
that is authoritative for woodgrove.com. The authoritative DNS server responds with the requested record
(www.woodgrove.com) to the LDNS server, which in turn caches the record locally before sending it to the user's
computer.
Because Contoso Cloud Services uses DNS Server policies, the authoritative DNS server that hosts contoso.com is
configured to return geo-location based traffic managed responses. This results in the direction of European
Clients to the European datacenter and the direction of American Clients to the U.S. datacenter, as depicted in the
illustration.
In this scenario, the authoritative DNS server usually sees the name resolution request coming from the LDNS
server and, very rarely, from the user's computer. Because of this, the source IP address in the name resolution
request as seen by the authoritative DNS server is that of the LDNS server and not that of the user's computer.
However, using the IP address of the LDNS server when you configure geo-location based query responses
provides a fair estimate of the geo-location of the user, because the user is querying the DNS server of his local
ISP.
 NOTE
DNS policies utilize the sender IP in the UDP/TCP packet that contains the DNS query. If the query reaches the primary
server through multiple resolver/LDNS hops, the policy will consider only the IP of the last resolver from which the DNS
server receives the query.

How to configure DNS Policy for Geo-Location Based Query Responses

To configure DNS policy for geo-location based query responses, you must perform the following steps.
1. Create the DNS Client Subnets
2. Create the Scopes of the Zone
3. Add Records to the Zone Scopes
4. Create the Policies

NOTE
You must perform these steps on the DNS server that is authoritative for the zone you want to configure. Membership in
DnsAdmins , or equivalent, is required to perform the following procedures.

The following sections provide detailed configuration instructions.

IMPORTANT
The following sections include example Windows PowerShell commands that contain example values for many parameters.
Ensure that you replace example values in these commands with values that are appropriate for your deployment before
you run these commands.

Create the DNS Client Subnets

The first step is to identify the subnets or IP address space of the regions for which you want to redirect traffic. For
example, if you want to redirect traffic for the U.S. and Europe, you need to identify the subnets or IP address
spaces of these regions.
You can obtain this information from Geo-IP maps. Based on these Geo-IP distributions, you must create the "DNS
Client Subnets." A DNS Client Subnet is a logical grouping of IPv4 or IPv6 subnets from which queries are sent to a
DNS server.
You can use the following Windows PowerShell commands to create DNS Client Subnets.

Add-DnsServerClientSubnet -Name "USSubnet" -IPv4Subnet "192.0.0.0/24"

Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "141.1.0.0/24"

For more information, see Add-DnsServerClientSubnet.

Create Zone Scopes
After the client subnets are configured, you must partition the zone whose traffic you want to redirect into two
different zone scopes, one scope for each of the DNS Client Subnets that you have configured.
For example, if you want to redirect traffic for the DNS name www.woodgrove.com, you must create two different
zone scopes in the woodgrove.com zone, one for the U.S. and one for Europe.
A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope
containing its own set of DNS records. The same record can be present in multiple scopes, with different IP
addresses or the same IP addresses.

NOTE
By default, a zone scope exists on the DNS zones. This zone scope has the same name as the zone and legacy DNS
operations work on this scope.

You can use the following Windows PowerShell commands to create zone scopes.

Add-DnsServerZoneScope -ZoneName "woodgrove.com" -Name "USZoneScope"

Add-DnsServerZoneScope -ZoneName "woodgrove.com" -Name "EuropeZoneScope"

For more information, see Add-DnsServerZoneScope.

Add Records to the Zone Scopes
Now you must add the records representing the web server host into the two zone scopes.
For example, USZoneScope and EuropeZoneScope . In USZoneScope, you can add the record
www.woodgrove.com with the IP address 192.0.0.1, which is located in a U.S. datacenter; and in EuropeZoneScope
you can add the same record (www.woodgrove.com) with the IP address 141.1.0.1 in the European datacenter.
You can use the following Windows PowerShell commands to add records to the zone scopes.

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "192.0.0.1" -ZoneScope

"USZoneScope

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "141.1.0.1" -ZoneScope

"EuropeZoneScope"

In this example, you must also use the following Windows PowerShell commands to add records into the default
zone scope to ensure that the rest of the world can still access the woodgrove.com web server from either of the
two datacenters.

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "192.0.0.1"

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "141.1.0.1"

The ZoneScope parameter is not included when you add a record in the default scope. This is the same as adding
records to a standard DNS zone.
For more information, see Add-DnsServerResourceRecord.
Create the Policies
After you have created the subnets, the partitions (zone scopes), and you have added records, you must create
policies that connect the subnets and partitions, so that when a query comes from a source in one of the DNS
client subnets, the query response is returned from the correct scope of the zone. No policies are required for
mapping the default zone scope.
You can use the following Windows PowerShell commands to create a DNS policy that links the DNS Client
Subnets and the zone scopes.
 Add-DnsServerQueryResolutionPolicy -Name "USPolicy" -Action ALLOW -ClientSubnet "eq,USSubnet" -ZoneScope
"USZoneScope,1" -ZoneName "woodgrove.com"

Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -

ZoneScope "EuropeZoneScope,1" -ZoneName "woodgrove.com"

For more information, see Add-DnsServerQueryResolutionPolicy.

Now the DNS server is configured with the required DNS policies to redirect traffic based on geo-location.
When the DNS server receives name resolution queries, the DNS server evaluates the fields in the DNS request
against the configured DNS policies. If the source IP address in the name resolution request matches any of the
policies, the associated zone scope is used to respond to the query, and the user is directed to the resource that is
geographically closest to them.
You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
 Use DNS Policy for Geo-Location Based Traffic
Management with Primary-Secondary Deployments
3/26/2020 • 8 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn how to create DNS policy for geo-location based traffic management when your
DNS deployment includes both primary and secondary DNS servers.
The previous scenario, Use DNS Policy for Geo-Location Based Traffic Management with Primary Servers, provided
instructions for configuring DNS policy for geo-location based traffic management on a primary DNS server. In
the Internet infrastructure, however, the DNS servers are widely deployed in a primary-secondary model, where
the writable copy of a zone is stored on select and secure primary servers, and read-only copies of the zone are
kept on multiple secondary servers.
The secondary servers use the zone transfer protocols Authoritative Transfer (AXFR) and Incremental Zone
Transfer (IXFR) to request and receive zone updates that include new changes to the zones on the primary DNS
servers.

NOTE
For more information about AXFR, see the Internet Engineering Task Force (IETF) Request for Comments 5936. For more
information about IXFR, see the Internet Engineering Task Force (IETF) Request for Comments 1995.

Primary-Secondary Geo-Location Based Traffic Management Example

Following is an example of how you can use DNS policy in a primary-secondary deployment to achieve traffic
redirection on the basis of the physical location of the client that performs a DNS query.
This example uses two fictional companies - Contoso Cloud Services, which provides web and domain hosting
solutions; and Woodgrove Food Services, which provides food delivery services in multiple cities across the globe,
and which has a Web site named woodgrove.com.
To ensure that woodgrove.com customers get a responsive experience from their website, Woodgrove wants
European clients directed to the European datacenter and American clients directed to the U.S. datacenter.
Customers located elsewhere in the world can be directed to either of the datacenters.
Contoso Cloud Services has two datacenters, one in the U.S. and another in Europe, upon which Contoso hosts its
food ordering portal for woodgrove.com.
The Contoso DNS deployment includes two secondary servers: Secondar ySer ver1 , with the IP address 10.0.0.2;
and Secondar ySer ver2 , with the IP address 10.0.0.3. These secondary servers are acting as name servers in the
two different regions, with SecondaryServer1 located in Europe and SecondaryServer2 located in the U.S.
There is a primary writable zone copy on Primar ySer ver (IP address 10.0.0.1), where the zone changes are made.
With regular zone transfers to the secondary servers, the secondary servers are always up to date with any new
changes to the zone on the PrimaryServer.
The following illustration depicts this scenario.
How the DNS Primary-Secondary System Works
When you deploy geo-location based traffic management in a primary-secondary DNS deployment, it is
important to understand how normal primary-secondary zone transfers occur before learning about zone scope
level transfers. The following sections provide information on zone and zone scope level transfers.
Zone transfers in a DNS primary-secondary deployment
Zone scope level transfers in a DNS primary-secondary deployment
Zone transfers in a DNS primary-secondary deployment
You can create a DNS primary-secondary deployment and synchronize zones with the following steps.
1. When you install DNS, the primary zone is created on the primary DNS server.
2. On the secondary server, create the zones and specify the primary servers.
3. On the primary servers, you can add the secondary servers as trusted secondaries on the primary zone.
4. The secondary zones make a full zone transfer request (AXFR) and receive the copy of the zone.
5. When needed, the primary servers send notifications to the secondary servers about zone updates.
6. Secondary servers make an incremental zone transfer request (IXFR). Because of this, the secondary servers
remain synchronized with the primary server.
Zone scope level transfers in a DNS primary-secondary deployment
The traffic management scenario requires additional steps to partition the zones into different zone scopes.
Because of this, additional steps are required to transfer the data inside the zone scopes to the secondary servers,
and to transfer policies and DNS Client Subnets to the secondary servers.
After you configure your DNS infrastructure with primary and secondary servers, zone scope level transfers are
performed automatically by DNS, using the following processes.
To ensure the Zone scope level transfer, DNS servers use the Extension Mechanisms for DNS (EDNS0) OPT RR. All
zone transfer (AXFR or IXFR) requests from the zones with scopes originate with an EDNS0 OPT RR, whose option
ID is set to "65433" by default. For more information about EDNSO, see the IETF Request for Comments 6891.
The value of the OPT RR is the zone scope name for which the request is being sent. When a primary DNS server
receives this packet from a trusted secondary server, it interprets the request as coming for that zone scope.
If the primary server has that zone scope it responds with the transfer (XFR) data from that scope. The response
contains an OPT RR with the same option ID "65433" and value set to the same zone scope. The secondary servers
receive this response, retrieve the scope information from the response, and update that particular scope of the
zone.
After this process, the primary server maintains a list of trusted secondaries which have sent such a zone scope
request for notifications.
For any further update in a zone scope, an IXFR notification is sent to the secondary servers, with the same OPT
RR. The zone scope receiving that notification makes the IXFR request containing that OPT RR and the same
process as described above follows.

How to configure DNS Policy for Primary-Secondary Geo-Location

Based Traffic Management
Before you begin, ensure that you have completed all of the steps in the topic Use DNS Policy for Geo-Location
Based Traffic Management with Primary Servers, and your primary DNS server is configured with zones, zone
scopes, DNS Client Subnets, and DNS policy.

NOTE
The instructions in this topic to copy DNS Client Subnets, zone scopes, and DNS policies from DNS primary servers to DNS
secondary servers are for your initial DNS setup and validation. In the future you might want to change the DNS Client
Subnets, zone scopes, and policies settings on the primary server. In this circumstance, you can create automation scripts to
keep the secondary servers synchronized with the primary server.

To configure DNS policy for primary-secondary geo-location based query responses, you must perform the
following steps.
Create the Secondary Zones
Configure the Zone Transfer Settings on the Primary Zone
Copy the DNS Client Subnets
Create the Zone Scopes on the Secondary Server
Configure DNS policy
The following sections provide detailed configuration instructions.

IMPORTANT
The following sections include example Windows PowerShell commands that contain example values for many parameters.
Ensure that you replace example values in these commands with values that are appropriate for your deployment before
you run these commands.
Membership in DnsAdmins , or equivalent, is required to perform the following procedures.

Create the Secondary Zones

You can create the secondary copy of the zone you want to replicate to SecondaryServer1 and SecondaryServer2
(assuming the cmdlets are being executed remotely from a single management client).
For example, you can create the secondary copy of www.woodgrove.com on SecondaryServer1 and
SecondarySesrver2.
You can use the following Windows PowerShell commands to create the secondary zones.
 Add-DnsServerSecondaryZone -Name "woodgrove.com" -ZoneFile "woodgrove.com.dns" -MasterServers 10.0.0.1 -
ComputerName SecondaryServer1

Add-DnsServerSecondaryZone -Name "woodgrove.com" -ZoneFile "woodgrove.com.dns" -MasterServers 10.0.0.1 -

ComputerName SecondaryServer2

For more information, see Add-DnsServerSecondaryZone.

Configure the Zone Transfer Settings on the Primary Zone
You must configure the primary zone settings so that:
1. Zone transfers from the primary server to the specified secondary servers are allowed.
2. Zone update notifications are sent by the primary server to the secondary servers.
You can use the following Windows PowerShell commands to configure the zone transfer settings on the primary
zone.

NOTE
In the following example command, the parameter -Notify specifies that the primary server will send notifications about
updates to the select list of secondaries.

Set-DnsServerPrimaryZone -Name "woodgrove.com" -Notify Notify -SecondaryServers "10.0.0.2,10.0.0.3" -

SecureSecondaries TransferToSecureServers -ComputerName PrimaryServer

For more information, see Set-DnsServerPrimaryZone.

Copy the DNS Client Subnets
You must copy the DNS Client Subnets from the primary server to the secondary servers.
You can use the following Windows PowerShell commands to copy the subnets to the secondary servers.

Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-DnsServerClientSubnet -ComputerName

SecondaryServer1

Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-DnsServerClientSubnet -ComputerName

SecondaryServer2

For more information, see Add-DnsServerClientSubnet.

Create the Zone Scopes on the Secondary Server
You must create the zone scopes on the secondary servers. In DNS, the zone scopes also start requesting XFRs
from the primary server. With any change on the zone scopes on the primary server, a notification that contains
the zone scope information is sent to the secondary servers. The secondary servers can then update their zone
scopes with incremental change.
You can use the following Windows PowerShell commands to create the zone scopes on the secondary servers.
 Get-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName
"woodgrove.com" -ComputerName SecondaryServer1 -ErrorAction Ignore

Get-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName PrimaryServer|Add-DnsServerZoneScope -ZoneName

"woodgrove.com" -ComputerName SecondaryServer2 -ErrorAction Ignore

NOTE
In these example commands, the -ErrorAction Ignore parameter is included, because a default zone scope exists on every
zone. The default zone scope cannot be created or deleted. Pipelining will result in an attempt to create that scope and it will
fail. Alternatively, you can create the non-default zone scopes on two secondary zones.

For more information, see Add-DnsServerZoneScope.

Configure DNS policy
After you have created the subnets, the partitions (zone scopes), and you have added records, you must create
policies that connect the subnets and partitions, so that when a query comes from a source in one of the DNS
client subnets, the query response is returned from the correct scope of the zone. No policies are required for
mapping the default zone scope.
You can use the following Windows PowerShell commands to create a DNS policy that links the DNS Client
Subnets and the zone scopes.

$policy = Get-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName PrimaryServer

$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName SecondaryServer1

$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName SecondaryServer2

For more information, see Add-DnsServerQueryResolutionPolicy.

Now the secondary DNS servers are configured with the required DNS policies to redirect traffic based on geo-
location.
When the DNS server receives name resolution queries, the DNS server evaluates the fields in the DNS request
against the configured DNS policies. If the source IP address in the name resolution request matches any of the
policies, the associated zone scope is used to respond to the query, and the user is directed to the resource that is
geographically closest to them.
You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
 Use DNS Policy for Intelligent DNS Responses Based
on the Time of Day
3/26/2020 • 8 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn how to distribute application traffic across different geographically distributed
instances of an application by using DNS policies that are based on the time of day.
This scenario is useful in situations where you want to direct traffic in one time zone to alternate application
servers, such as Web servers, that are located in another time zone. This allows you to load balance traffic across
application instances during peak time periods when your primary servers are overloaded with traffic.
Example of Intelligent DNS Responses Based on the Time of Day
Following is an example of how you can use DNS policy to balance application traffic based on the time of day.
This example uses one fictional company, Contoso Gift Services, which provides online gifting solutions across the
globe through their Web site, contosogiftservices.com.
The contosogiftservices.com Web site is hosted in two datacenters, one in Seattle (North America) and another in
Dublin (Europe). The DNS servers are configured for sending geo-location aware responses using DNS policy. With
a recent surge in business, contosogiftservices.com has a higher number of visitors every day, and some of the
customers have reported service availability issues.
Contoso Gift Services performs a site analysis, and discovers that every evening between 6 PM and 9 PM local
time, there is a surge in the traffic to the Web servers. The Web servers cannot scale to handle the increased traffic
at these peak hours, resulting in denial of service to customers. The same peak hour traffic overload happens in
both the European and American datacenters. At other times of day, the servers handle traffic volumes that are
well below their maximum capability.
To ensure that contosogiftservices.com customers get a responsive experience from the Web site, Contoso Gift
Services wants to redirect some Dublin traffic to the Seattle application servers between 6 PM and 9 PM in Dublin;
and they want to redirect some Seattle traffic to the Dublin application servers between 6 PM and 9 PM in Seattle.
The following illustration depicts this scenario.
How Intelligent DNS Responses Based on Time of Day Works
When the DNS server is configured with time of day DNS policy, between 6 PM and 9 PM at each geographical
location, the DNS server does the following.
Answers the first four queries it receives with the IP address of the Web server in the local datacenter.
Answers the fifth query it receives with the IP address of the Web server in the remote datacenter.
This policy-based behavior offloads twenty per cent of the local Web server's traffic load to the remote Web server,
easing the strain on the local application server and improving site performance for customers.
During off-peak hours, the DNS servers perform normal geo-locations based traffic management. In addition, DNS
clients that send queries from locations other than North America or Europe, the DNS server load balances the
traffic across the Seattle and Dublin datacenters.
When multiple DNS policies are configured in DNS, they are an ordered set of rules, and they are processed by
DNS from highest priority to lowest priority. DNS uses the first policy that matches the circumstances, including
time of day. For this reason, more specific policies should have higher priority. If you create time of day policies and
give them high priority in the list of policies, DNS processes and uses these policies first if they match the
parameters of the DNS client query and the criteria defined in the policy. If they don't match, DNS moves down the
list of policies to process the default policies until it finds a match.
For more information about policy types and criteria, see DNS Policies Overview.
How to Configure DNS Policy for Intelligent DNS Responses Based on Time of Day
To configure DNS policy for time of day application load balancing based query responses, you must perform the
following steps.
Create the DNS Client Subnets
Create the Zone Scopes
Add Records to the Zone Scopes
Create the DNS Policies
 NOTE
You must perform these steps on the DNS server that is authoritative for the zone you want to configure. Membership in
DnsAdmins , or equivalent, is required to perform the following procedures.

The following sections provide detailed configuration instructions.

IMPORTANT
The following sections include example Windows PowerShell commands that contain example values for many parameters.
Ensure that you replace example values in these commands with values that are appropriate for your deployment before you
run these commands.

Create the DNS Client Subnets

The first step is to identify the subnets or IP address space of the regions for which you want to redirect traffic. For
example, if you want to redirect traffic for the U.S. and Europe, you need to identify the subnets or IP address
spaces of these regions.
You can obtain this information from Geo-IP maps. Based on these Geo-IP distributions, you must create the "DNS
Client Subnets." A DNS Client Subnet is a logical grouping of IPv4 or IPv6 subnets from which queries are sent to a
DNS server.
You can use the following Windows PowerShell commands to create DNS Client Subnets.

Add-DnsServerClientSubnet -Name "AmericaSubnet" -IPv4Subnet "192.0.0.0/24, 182.0.0.0/24"

Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "141.1.0.0/24, 151.1.0.0/24"

For more information, see Add-DnsServerClientSubnet.

Create the Zone Scopes
After the client subnets are configured, you must partition the zone whose traffic you want to redirect into two
different zone scopes, one scope for each of the DNS Client Subnets that you have configured.
For example, if you want to redirect traffic for the DNS name www.contosogiftservices.com, you must create two
different zone scopes in the contosogiftservices.com zone, one for the U.S. and one for Europe.
A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope
containing its own set of DNS records. The same record can be present in multiple scopes, with different IP
addresses or the same IP addresses.

NOTE
By default, a zone scope exists on the DNS zones. This zone scope has the same name as the zone, and legacy DNS
operations work on this scope.

You can use the following Windows PowerShell commands to create zone scopes.

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "SeattleZoneScope"

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DublinZoneScope"

For more information, see Add-DnsServerZoneScope.
Add Records to the Zone Scopes
Now you must add the records representing the web server host into the two zone scopes.
For example, in SeattleZoneScope , the record www.contosogiftser vices.com is added with IP address
192.0.0.1, which is located in a Seattle datacenter. Similarly, in DublinZoneScope , the record
www.contosogiftser vices.com is added with IP address 141.1.0.3 in the Dublin datacenter
You can use the following Windows PowerShell commands to add records to the zone scopes.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.0.0.1" -

ZoneScope "SeattleZoneScope

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "141.1.0.3" -

ZoneScope "DublinZoneScope"

The ZoneScope parameter is not included when you add a record in the default scope. This is the same as adding
records to a standard DNS zone.
For more information, see Add-DnsServerResourceRecord.
Create the DNS Policies
After you have created the subnets, the partitions (zone scopes), and you have added records, you must create
policies that connect the subnets and partitions, so that when a query comes from a source in one of the DNS
client subnets, the query response is returned from the correct scope of the zone. No policies are required for
mapping the default zone scope.
After you configure these DNS policies, the DNS server behavior is as follows:
1. European DNS clients receive the IP address of the Web server in the Dublin datacenter in their DNS query
response.
2. American DNS clients receive the IP address of the Web server in the Seattle datacenter in their DNS query
response.
3. Between 6 PM and 9 PM in Dublin, 20% of the queries from European clients receive the IP address of the Web
server in the Seattle datacenter in their DNS query response.
4. Between 6 PM and 9 PM in Seattle, 20% of the queries from the American clients receive the IP address of the
Web server in the Dublin datacenter in their DNS query response.
5. Half of the queries from the rest of the world receive the IP address of the Seattle datacenter and the other half
receive the IP address of the Dublin datacenter.
You can use the following Windows PowerShell commands to create a DNS policy that links the DNS Client
Subnets and the zone scopes.

NOTE
In this example, the DNS server is in the GMT time zone, so the peak hour time periods must be expressed in the equivalent
GMT time.
 Add-DnsServerQueryResolutionPolicy -Name "America6To9Policy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -
ZoneScope "SeattleZoneScope,4;DublinZoneScope,1" -TimeOfDay "EQ,01:00-04:00" -ZoneName
"contosogiftservices.com" -ProcessingOrder 1

Add-DnsServerQueryResolutionPolicy -Name "Europe6To9Policy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -

ZoneScope "SeattleZoneScope,1;DublinZoneScope,4" -TimeOfDay "EQ,17:00-20:00" -ZoneName
"contosogiftservices.com" -ProcessingOrder 2

Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -

ZoneScope "SeattleZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 3

Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -

ZoneScope "DublinZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 4

Add-DnsServerQueryResolutionPolicy -Name "RestOfWorldPolicy" -Action ALLOW --ZoneScope

"DublinZoneScope,1;SeattleZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 5

For more information, see Add-DnsServerQueryResolutionPolicy.

Now the DNS server is configured with the required DNS policies to redirect traffic based on geo-location and
time of day.
When the DNS server receives name resolution queries, the DNS server evaluates the fields in the DNS request
against the configured DNS policies. If the source IP address in the name resolution request matches any of the
policies, the associated zone scope is used to respond to the query, and the user is directed to the resource that is
geographically closest to them.
You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
 DNS Responses Based on Time of Day with an Azure
Cloud App Server
3/26/2020 • 6 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn how to distribute application traffic across different geographically distributed
instances of an application by using DNS policies that are based on the time of day.
This scenario is useful in situations where you want to direct traffic in one time zone to alternate application
servers, such as Web servers that are hosted on Microsoft Azure, that are located in another time zone. This allows
you to load balance traffic across application instances during peak time periods when your primary servers are
overloaded with traffic.

NOTE
To learn how to use DNS policy for intelligent DNS responses without using Azure, see Use DNS Policy for Intelligent DNS
Responses Based on the Time of Day.

Example of Intelligent DNS Responses Based on the Time of Day with

Azure Cloud App Server
Following is an example of how you can use DNS policy to balance application traffic based on the time of day.
This example uses one fictional company, Contoso Gift Services, which provides online gifting solutions across the
globe through their Web site, contosogiftservices.com.
The contosogiftservices.com web site is hosted only at a single on-premises datacenter in Seattle (with public IP
192.68.30.2).
The DNS server is also located in the on-premises datacenter.
With a recent surge in business, contosogiftservices.com has a higher number of visitors every day, and some of
the customers have reported service availability issues.
Contoso Gift Services performs a site analysis, and discovers that every evening between 6 PM and 9 PM local
time, there is a surge in the traffic to the Seattle Web server. The Web server cannot scale to handle the increased
traffic at these peak hours, resulting in denial of service to customers.
To ensure that contosogiftservices.com customers get a responsive experience from the Web site, Contoso Gift
Services decides that during these hours it will rent a virtual machine (VM) on Microsoft Azure to host a copy of its
Web server.
Contoso Gift Services gets a public IP address from Azure for the VM (192.68.31.44) and develops the automation
to deploy the Web Server every day on Azure between 5-10 PM, allowing for a one hour contingency period.

NOTE
For more information about Azure VMs, see Virtual Machines documentation
The DNS servers are configured with zone scopes and DNS policies so that between 5-9 PM every day, 30% of
queries are sent to the instance of the Web server that is running in Azure.
The following illustration depicts this scenario.

How Intelligent DNS Responses Based on Time of Day with Azure App
Server Works
This article demonstrates how to configure the DNS server to answer DNS queries with two different application
server IP addresses - one web server is in Seattle and the other is in an Azure datacenter.
After the configuration of a new DNS policy that is based on the peak hours of 6 PM to 9 PM in Seattle, the DNS
server sends seventy per cent of the DNS responses to clients containing the IP address of the Seattle Web server,
and thirty per cent of the DNS responses to clients containing the IP address of the Azure Web server, thereby
directing client traffic to the new Azure Web server, and preventing the Seattle Web server from becoming
overloaded.
At all other times of day, the normal query processing takes place and responses are sent from default zone scope
which contains a record for the web server in the on-premises datacenter.
The TTL of 10 minutes on the Azure record ensures that the record is expired from the LDNS cache before the VM
is removed from Azure. One of the benefits of such scaling is that you can keep your DNS data on-premises, and
keep scaling out to Azure as demand requires.

How to Configure DNS Policy for Intelligent DNS Responses Based on

Time of Day with Azure App Server
To configure DNS policy for time of day application load balancing based query responses, you must perform the
following steps.
Create the Zone Scopes
 Add Records to the Zone Scopes
Create the DNS Policies

NOTE
You must perform these steps on the DNS server that is authoritative for the zone you want to configure. Membership in
DnsAdmins, or equivalent, is required to perform the following procedures.

The following sections provide detailed configuration instructions.

IMPORTANT
The following sections include example Windows PowerShell commands that contain example values for many parameters.
Ensure that you replace example values in these commands with values that are appropriate for your deployment before you
run these commands.

Create the Zone Scopes

A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope
containing its own set of DNS records. The same record can be present in multiple scopes, with different IP
addresses or the same IP addresses.

NOTE
By default, a zone scope exists on the DNS zones. This zone scope has the same name as the zone, and legacy DNS
operations work on this scope.

You can use the following example command to create a zone scope to host the Azure records.

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "AzureZoneScope"

For more information, see Add-DnsServerZoneScope

Add Records to the Zone Scopes
The next step is to add the records representing the Web server host into the zone scopes.
In AzureZoneScope, the record www.contosogiftservices.com is added with IP address 192.68.31.44, which is
located in the Azure public cloud.
Similarly, in the default zone scope (contosogiftservices.com), a record (www.contosogiftservices.com) is added
with IP address 192.68.30.2 of the Web server running in the Seattle on-premises datacenter.
In the second cmdlet below, the –ZoneScope parameter is not included. Because of this, the records are added in
the default ZoneScope.
In addition, the TTL of the record for Azure VMs is kept at 600s (10 mins) so that the LDNS do not cache it for a
longer time - which would interfere with load balancing. Also, the Azure VMs are available for 1 extra hour as a
contingency to ensure that even clients with cached records are able to resolve.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.68.31.44" -

ZoneScope "AzureZoneScope" –TimeToLive 600

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.68.30.2"

For more information, see Add-DnsServerResourceRecord.
Create the DNS Policies
After the zone scopes are created, you can create DNS policies that distribute the incoming queries across these
scopes so that the following occurs.
1. From 6 PM to 9 PM daily, 30% of clients receive the IP address of the Web server in the Azure datacenter in the
DNS response, while 70% of clients receive the IP address of the Seattle on-premises Web server.
2. At all other times, all the clients receive the IP address of the Seattle on-premises Web server.
The time of the day has to be expressed in local time of the DNS server.
You can use the following example command to create the DNS policy.

Add-DnsServerQueryResolutionPolicy -Name "Contoso6To9Policy" -Action ALLOW -ZoneScope

"contosogiftservices.com,7;AzureZoneScope,3" –TimeOfDay “EQ,18:00-21:00” -ZoneName "contosogiftservices.com" –
ProcessingOrder 1

For more information, see Add-DnsServerQueryResolutionPolicy.

Now the DNS server is configured with the required DNS policies to redirect traffic to the Azure Web server based
on time of day.
Note the expression:
-ZoneScope "contosogiftservices.com,7;AzureZoneScope,3" –TimeOfDay “EQ,18:00-21:00”

This expression configures the DNS server with a ZoneScope and weight combination that instructs the DNS
server to send the IP address of the Seattle Web server seventy per cent of the time, while sending the IP address
of the Azure Web server thirty per cent of the time.
You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
 Use DNS Policy for Split-Brain DNS Deployment
3/26/2020 • 8 minutes to read • Edit Online

Applies to: Windows Server 2016

You can use this topic to learn how to configure DNS policy in Windows Server® 2016 for split-brain DNS
deployments, where there are two versions of a single zone - one for the internal users on your organization
intranet, and one for the external users, who are typically users on the Internet.

NOTE
For information on how to use DNS Policy for split-brain DNS deployment with Active Directory integrated DNS Zones, see
Use DNS Policy for Split-Brain DNS in Active Directory.

Previously, this scenario required that DNS administrators maintain two different DNS servers, each providing
services to each set of users, internal and external. If only a few records inside the zone were split-brained or both
instances of the zone (internal and external) were delegated to the same parent domain, this became a
management conundrum.
Another configuration scenario for split-brain deployment is Selective Recursion Control for DNS name resolution.
In some circumstances, the Enterprise DNS servers are expected to perform recursive resolution over the Internet
for the internal users, while they also must act as authoritative name servers for external users, and block recursion
for them.
This topic contains the following sections.
Example of DNS Split-Brain Deployment
Example of DNS Selective Recursion Control

Example of DNS Split-Brain Deployment

Following is an example of how you can use DNS policy to accomplish the previously described scenario of split-
brain DNS.
This section contains the following topics.
How DNS Split-Brain Deployment Works
How to Configure DNS Split-Brain Deployment
This example uses one fictional company, Contoso, which maintains a career Web site at www.career.contoso.com.
The site has two versions, one for the internal users where internal job postings are available. This internal site is
available at the local IP address 10.0.0.39.
The second version is the public version of the same site, which is available at the public IP address 65.55.39.10.
In the absence of DNS policy, the administrator is required to host these two zones on separate Windows Server
DNS servers and manage them separately.
Using DNS policies these zones can now be hosted on the same DNS server.
The following illustration depicts this scenario.
How DNS Split-Brain Deployment Works
When the DNS server is configured with the required DNS policies, each name resolution request is evaluated
against the policies on the DNS server.
The server Interface is used in this example as the criteria to differentiate between the internal and external clients.
If the server interface upon which the query is received matches any of the policies, the associated zone scope is
used to respond to the query.
So, in our example, the DNS queries for www.career.contoso.com that are received on the private IP (10.0.0.56)
receive a DNS response that contains an internal IP address; and the DNS queries that are received on the public
network interface receive a DNS response that contains the public IP address in the default zone scope (this is the
same as normal query resolution).

How to Configure DNS Split-Brain Deployment

To configure DNS Split-Brain Deployment by using DNS Policy, you must use the following steps.
Create the Zone Scopes
Add Records to the Zone Scopes
Create the DNS Policies
The following sections provide detailed configuration instructions.

IMPORTANT
The following sections include example Windows PowerShell commands that contain example values for many parameters.
Ensure that you replace example values in these commands with values that are appropriate for your deployment before you
run these commands.
Create the Zone Scopes
A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope
containing its own set of DNS records. The same record can be present in multiple scopes, with different IP
addresses or the same IP addresses.

NOTE
By default, a zone scope exists on the DNS zones. This zone scope has the same name as the zone, and legacy DNS
operations work on this scope. This default zone scope will host the external version of www.career.contoso.com.

You can use the following example command to partition the zone scope contoso.com to create an internal zone
scope. The internal zone scope will be used to keep the internal version of www.career.contoso.com.
Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal"

For more information, see Add-DnsServerZoneScope

Add Records to the Zone Scopes
The next step is to add the records representing the Web server host into the two zone scopes - internal and
default (for external clients).
In the internal zone scope, the record www.career.contoso.com is added with the IP address 10.0.0.39, which is a
private IP; and in the default zone scope the same record, www.career.contoso.com , is added with the IP address
65.55.39.10.
No –ZoneScope parameter is provided in the following example commands when the record is being added to
the default zone scope. This is similar to adding records to a vanilla zone.
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10"
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39” -ZoneScope
"internal"

For more information, see Add-DnsServerResourceRecord.

Create the DNS Policies
After you have identified the server interfaces for the external network and internal network and you have created
the zone scopes, you must create DNS policies that connect the internal and external zone scopes.

NOTE
This example uses the server interface as the criteria to differentiate between the internal and external clients. Another
method to differentiate between external and internal clients is by using client subnets as a criteria. If you can identify the
subnets to which the internal clients belong, you can configure DNS policy to differentiate based on client subnet. For
information on how to configure traffic management using client subnet criteria, see Use DNS Policy for Geo-Location Based
Traffic Management with Primary Servers.

When the DNS server receives a query on the private interface, the DNS query response is returned from the
internal zone scope.

NOTE
No policies are required for mapping the default zone scope.

In the following example command, 10.0.0.56 is the IP address on the private network interface, as shown in the
previous illustration.
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface "eq,10.0.0.56" -
ZoneScope "internal,1" -ZoneName contoso.com

For more information, see Add-DnsServerQueryResolutionPolicy.

Example of DNS Selective Recursion Control

Following is an example of how you can use DNS policy to accomplish the previously described scenario of DNS
selective recursion control.
This section contains the following topics.
How DNS Selective Recursion Control Works
How to Configure DNS Selective Recursion Control
This example uses the same fictional company as in the previous example, Contoso, which maintains a career Web
site at www.career.contoso.com.
In the DNS split-brain deployment example, the same DNS server responds to both the external and internal clients
and provides them with different answers.
Some DNS deployments might require the same DNS server to perform recursive name resolution for internal
clients in addition to acting as the authoritative name server for external clients. This circumstance is called DNS
selective recursion control.
In previous versions of Windows Server, enabling recursion meant that it was enabled on the whole DNS server for
all zones. Because the DNS server is also listening to external queries, recursion is enabled for both internal and
external clients, making the DNS server an open resolver.
A DNS server that is configured as an open resolver might be vulnerable to resource exhaustion and can be
abused by malicious clients to create reflection attacks.
Because of this, Contoso DNS administrators do not want the DNS server for contoso.com to perform recursive
name resolution for external clients. There is only a need for recursion control for internal clients, while recursion
control can be blocked for external clients.
The following illustration depicts this scenario.

How DNS Selective Recursion Control Works

If a query for which the Contoso DNS server is non-authoritative is received, such as for
https://www.microsoft.com, then the name resolution request is evaluated against the policies on the DNS server.
Because these queries do not fall under any zone, the zone level policies (as defined in the split-brain example) are
not evaluated.
The DNS server evaluates the recursion policies, and the queries that are received on the private interface match
the SplitBrainRecursionPolicy . This policy points to a recursion scope where recursion is enabled.
The DNS server then performs recursion to get the answer for https://www.microsoft.com from the Internet, and
caches the response locally.
If the query is received on the external interface, no DNS policies match, and the default recursion setting - which
in this case is Disabled - is applied.
This prevents the server from acting as an open resolver for external clients, while it is acting as a caching resolver
for internal clients.
How to Configure DNS Selective Recursion Control
To configure DNS selective recursion control by using DNS Policy, you must use the following steps.
Create DNS Recursion Scopes
Create DNS Recursion Policies
Create DNS Recursion Scopes
Recursion scopes are unique instances of a group of settings that control recursion on a DNS server. A recursion
scope contains a list of forwarders and specifies whether recursion is enabled. A DNS server can have many
recursion scopes.
The legacy recursion setting and list of forwarders are referred to as the default recursion scope. You cannot add or
remove the default recursion scope, identified by the name dot (“.”).
In this example, the default recursion setting is disabled, while a new recursion scope for internal clients is created
where recursion is enabled.

Set-DnsServerRecursionScope -Name . -EnableRecursion $False

Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True

For more information, see Add-DnsServerRecursionScope

Create DNS Recursion Policies
You can create DNS server recursion policies to choose a recursion scope for a set of queries that match specific
criteria.
If the DNS server is not authoritative for some queries, DNS server recursion policies allow you to control how to
resolve the queries.
In this example, the internal recursion scope with recursion enabled is associated with the private network
interface.
You can use the following example command to configure DNS recursion policies.

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy" -Action ALLOW -ApplyOnRecursion -

RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.39"

For more information, see Add-DnsServerQueryResolutionPolicy.

Now the DNS server is configured with the required DNS policies for either a split-brain name server or a DNS
server with selective recursion control enabled for internal clients.
You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
For more information, see DNS Policy Scenario Guide.
 Use DNS Policy for Split-Brain DNS in Active
Directory
3/26/2020 • 6 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to leverage the traffic management capabilities of DNS policies for split-brain deployments
with Active Directory integrated DNS zones in Windows Server 2016.
In Windows Server 2016, DNS policies support is extended to Active Directory integrated DNS zones. Active
Directory integration provides multi-master high availability capabilities to the DNS server.
Previously, this scenario required that DNS administrators maintain two different DNS servers, each providing
services to each set of users, internal and external. If only a few records inside the zone were split-brained or both
instances of the zone (internal and external) were delegated to the same parent domain, this became a
management conundrum.

NOTE
DNS deployments are split-brain when there are two versions of a single zone, one version for internal users on the
organization intranet, and one version for external users – who are, typically, users on the Internet.
The topic Use DNS Policy for Split-Brain DNS Deployment explains how you can use DNS policies and zone scopes to
deploy a split-brain DNS system on a single Windows Server 2016 DNS server.

Example Split-Brain DNS in Active Directory

This example uses one fictional company, Contoso, which maintains a career Web site at www.career.contoso.com.
The site has two versions, one for the internal users where internal job postings are available. This internal site is
available at the local IP address 10.0.0.39.
The second version is the public version of the same site, which is available at the public IP address 65.55.39.10.
In the absence of DNS policy, the administrator is required to host these two zones on separate Windows Server
DNS servers and manage them separately.
Using DNS policies these zones can now be hosted on the same DNS server.
If the DNS server for contoso.com is Active Directory integrated, and is listening on two network interfaces, the
Contoso DNS Administrator can follow the steps in this topic to achieve a split-brain deployment.
The DNS Administrator configures the DNS server interfaces with the following IP addresses.
The Internet facing network adapter is configured with a public IP address of 208.84.0.53 for external queries.
The Intranet facing network adapter is configured with a private IP address of 10.0.0.56 for internal queries.
The following illustration depicts this scenario.
How DNS Policy for Split-Brain DNS in Active Directory Works
When the DNS server is configured with the required DNS policies, each name resolution request is evaluated
against the policies on the DNS server.
The server Interface is used in this example as the criteria to differentiate between the internal and external clients.
If the server interface upon which the query is received matches any of the policies, the associated zone scope is
used to respond to the query.
So, in our example, the DNS queries for www.career.contoso.com that are received on the private IP (10.0.0.56)
receive a DNS response that contains an internal IP address; and the DNS queries that are received on the public
network interface receive a DNS response that contains the public IP address in the default zone scope (this is the
same as normal query resolution).
Support for Dynamic DNS (DDNS) updates and scavenging is supported only on the default zone scope. Because
the internal clients are serviced by the default zone scope, Contoso DNS Administrators can continue using the
existing mechanisms (dynamic DNS or static) to update the records in contoso.com. For non-default zone scopes
(such as the external scope in this example), DDNS or scavenging support is not available.
High Availability of policies
DNS policies are not Active Directory integrated. Because of this, DNS policies are not replicated to the other DNS
servers that are hosting the same Active Directory integrated zone.
DNS policies are stored on the local DNS server. You can easily export DNS policies from one server to another by
using the following example Windows PowerShell commands.

$policies = Get-DnsServerQueryResolutionPolicy -ZoneName "contoso.com" -ComputerName Server01

$policies | Add-DnsServerQueryResolutionPolicy -ZoneName "contoso.com" -ComputerName Server02

For more information, see the following Windows PowerShell reference topics.
Get-DnsServerQueryResolutionPolicy
Add-DnsServerQueryResolutionPolicy

How to Configure DNS Policy for Split-Brain DNS in Active Directory

To configure DNS Split-Brain Deployment by using DNS Policy, you must use the following sections, which provide
detailed configuration instructions.
Add the Active Directory integrated zone
You can use the following example command to add the Active Directory integrated contoso.com zone to the DNS
server.

Add-DnsServerPrimaryZone -Name "contoso.com" -ReplicationScope "Domain" -PassThru

For more information, see Add-DnsServerPrimaryZone.

Create the Scopes of the Zone
You can use this section to partition the zone contoso.com to create an external zone scope.
A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope
containing its own set of DNS records. The same record can be present in multiple scopes, with different IP
addresses or the same IP addresses.
Because you are adding this new zone scope in an Active Directory integrated zone, the zone scope and the
records inside it will replicate via Active Directory to other replica servers in the domain.
By default, a zone scope exists in every DNS zone. This zone scope has the same name as the zone, and legacy
DNS operations work on this scope. This default zone scope will host the internal version of
www.career.contoso.com.
You can use the following example command to create the zone scope on the DNS server.

Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "external"

For more information, see Add-DnsServerZoneScope.

Add Records to the Zone Scopes
The next step is to add the records representing the web server host into the two zone scopes- external and default
(for internal clients).
In the default internal zone scope, the record www.career.contoso.com is added with IP address 10.0.0.39, which is
a private IP address; and in the external zone scope, the same record (www.career.contoso.com) is added with the
public IP address 65.55.39.10.
The records (both in the default internal zone scope and the external zone scope) will automatically replicate
across the domain with their respective zone scopes.
You can use the following example command to add records to the zone scopes on the DNS server.

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10" -

ZoneScope "external"

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39”

NOTE
The –ZoneScope parameter is not included when the record is added to the default zone scope. This action is same as
adding records to a normal zone.

For more information, see Add-DnsServerResourceRecord.

Create the DNS Policies
After you have identified the server interfaces for the external network and internal network and you have created
the zone scopes, you must create DNS policies that connect the internal and external zone scopes.

NOTE
This example uses the server interface (the -ServerInterface parameter in the example command below) as the criteria to
differentiate between the internal and external clients. Another method to differentiate between external and internal clients
is by using client subnets as a criteria. If you can identify the subnets to which the internal clients belong, you can configure
DNS policy to differentiate based on client subnet. For information on how to configure traffic management using client
subnet criteria, see Use DNS Policy for Geo-Location Based Traffic Management with Primary Servers.

After you configure policies, when a DNS query is received on the public interface, the answer is returned from the
external scope of the zone.

NOTE
No policies are required for mapping the default internal zone scope.

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface

"eq,208.84.0.53" -ZoneScope "external,1" -ZoneName contoso.com

NOTE
208.84.0.53 is the IP address on the public network interface.

For more information, see Add-DnsServerQueryResolutionPolicy.

Now the DNS server is configured with the required DNS policies for a split-brain name server with an Active
Directory integrated DNS zone.
You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
 Use DNS Policy for Applying Filters on DNS Queries
3/26/2020 • 4 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn how to configure DNS policy in Windows Server® 2016 to create query filters that
are based on criteria that you supply.
Query filters in DNS policy allow you to configure the DNS server to respond in a custom manner based on the
DNS query and DNS client that sends the DNS query.
For example, you can configure DNS policy with query filter Block List that blocks DNS queries from known
malicious domains, which prevents DNS from responding to queries from these domains. Because no response is
sent from the DNS server, the malicious domain member's DNS query times out.
Another example is to create a query filter Allow List that allows only a specific set of clients to resolve certain
names.

Query filter criteria

You can create query filters with any logical combination (AND/OR/NOT) of the following criteria.

NAME DESC RIP T IO N

Client Subnet Name of a predefined client subnet. Used to verify the subnet
from which the query was sent.

Transport Protocol Transport protocol used in the query. Possible values are UDP
and TCP.

Internet Protocol Network protocol used in the query. Possible values are IPv4
and IPv6.

Server Interface IP address IP address of the network interface of the DNS server that
received the DNS request.

FQDN Fully Qualified Domain Name of record in the query, with the
possibility of using a wild card.

Query Type Type of record being queried (A, SRV, TXT, etc.).

Time of Day Time of day the query is received.

The following examples show you how to create filters for DNS policy that either block or allow DNS name
resolution queries.

NOTE
The example commands in this topic use the Windows PowerShell command Add-DnsSer verQuer yResolutionPolicy . For
more information, see Add-DnsServerQueryResolutionPolicy.
Block queries from a domain
In some circumstances you might want to block DNS name resolution for domains that you have identified as
malicious, or for domains that do not comply with the usage guidelines of your organization. You can accomplish
blocking queries for domains by using DNS policy.
The policy that you configure in this example is not created on any particular zone – instead you create a Server
Level Policy that is applied to all zones configured on the DNS server. Server Level Policies are the first to be
evaluated and thus first to be matched when a query is received by the DNS server.
The following example command configures a Server Level Policy to block any queries with the domain suffix
contosomalicious.com .
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicy" -Action IGNORE -FQDN "EQ,*.contosomalicious.com" -
PassThru

NOTE
When you configure the Action parameter with the value IGNORE , the DNS server is configured to drop queries with no
response at all. This causes the DNS client in the malicious domain to time out.

Block queries from a subnet

With this example, you can block queries from a subnet if it is found to be infected by some malware and is trying
to contact malicious sites using your DNS server.
` Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet 172.0.33.0/24 -PassThru
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyMalicious06" -Action IGNORE -ClientSubnet
"EQ,MaliciousSubnet06" -PassThru `
The following example demonstrates how you can use the subnet criteria in combination with the FQDN criteria to
block queries for certain malicious domains from infected subnets.
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyMalicious06" -Action IGNORE -ClientSubnet
"EQ,MaliciousSubnet06" –FQDN “EQ,*.contosomalicious.com” -PassThru

Block a type of query

You might need to block name resolution for certain types of queries on your servers. For example, you can block
the 'ANY' query, which can be used maliciously to create amplification attacks.
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyQType" -Action IGNORE -QType "EQ,ANY" -PassThru

Allow queries only from a domain

You can not only use DNS policy to block queries, you can use them to automatically approve queries from specific
domains or subnets. When you configure Allow Lists, the DNS server only processes queries from allowed
domains, while blocking all other queries from other domains.
The following example command allows only computers and devices in the contoso.com and child domains to
query the DNS server.
Add-DnsServerQueryResolutionPolicy -Name "AllowListPolicyDomain" -Action IGNORE -FQDN "NE,*.contoso.com" -
PassThru

Allow queries only from a subnet

You can also create Allow Lists for IP subnets, so that all queries not originating from these subnets are ignored.
Add-DnsServerClientSubnet -Name "AllowedSubnet06" -IPv4Subnet 172.0.33.0/24 -PassThru
Add-DnsServerQueryResolutionPolicy -Name "AllowListPolicySubnet” -Action IGNORE -ClientSubnet "NE,
AllowedSubnet06" -PassThru

Allow only certain QTypes

You can apply Allow Lists to QTYPEs.
For example, if you have external customers querying DNS server interface 164.8.1.1, only certain QTYPEs are
allowed to be queried, while there are other QTYPEs like SRV or TXT records which are used by internal servers for
name resolution or for monitoring purposes.
Add-DnsServerQueryResolutionPolicy -Name "AllowListQType" -Action IGNORE -QType "NE,A,AAAA,MX,NS,SOA" –
ServerInterface “EQ,164.8.1.1” -PassThru

You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
 Use DNS Policy for Application Load Balancing
3/26/2020 • 4 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn how to configure DNS policy to perform application load balancing.
Previous versions of Windows Server DNS only provided load balancing by using round robin responses; but with
DNS in Windows Server 2016, you can configure DNS policy for application load balancing.
When you have deployed multiple instances of an application, you can use DNS policy to balance the traffic load
between the different application instances, thereby dynamically allocating the traffic load for the application.

Example of Application Load Balancing

Following is an example of how you can use DNS policy for application load balancing.
This example uses one fictional company - Contoso Gift Services - which provides online gifing services, and which
has a Web site named contosogiftser vices.com .
The contosogiftservices.com website is hosted in multiple datacenters that each have different IP addresses.
In North America, which is the primary market for Contoso Gift Services, the Web site is hosted in three
datacenters: Chicago, IL, Dallas, TX and Seattle, WA.
The Seattle Web server has the best hardware configuration and can handle twice as much load as the other two
sites. Contoso Gift Services wants application traffic directed in the following manner.
Because the Seattle Web server includes more resources, half of the application's clients are directed to this
server
One quarter of the application's clients are directed to the Dallas, TX datacenter
One quarter of the application's clients are directed to the Chicago, IL, datacenter
The following illustration depicts this scenario.
How Application Load Balancing Works
After you have configured the DNS server with DNS policy for application load balancing using this example
scenario, the DNS server responds 50% of the time with the Seattle Web server address, 25% of the time with the
Dallas Web server address, and 25% of the time with the Chicago Web server address.
Thus for every four queries the DNS server receives, it responds with two responses for Seattle and one each for
Dallas and Chicago.
One possible issue with load balancing with DNS policy is the caching of DNS records by the DNS client and the
resolver/LDNS, which can interfere with load balancing because the client or resolver do not send a query to the
DNS server.
You can mitigate the effect of this behavior by using a low Time-to-Live (TTL) value for the DNS records that should
be load balanced.
How to Configure Application Load Balancing
The following sections show you how to configure DNS policy for application load balancing.
Create the Zone Scopes
You must first create the scopes of the zone contosogiftservices.com for the datacenters where they are hosted.
A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope
containing its own set of DNS records. The same record can be present in multiple scopes, with different IP
addresses or the same IP addresses.

NOTE
By default, a zone scope exists on the DNS zones. This zone scope has the same name as the zone, and legacy DNS
operations work on this scope.

You can use the following Windows PowerShell commands to create zone scopes.
 Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "SeattleZoneScope"

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DallasZoneScope"

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "ChicagoZoneScope"

For more information, see Add-DnsServerZoneScope

Add Records to the Zone Scopes
Now you must add the records representing the web server host into the zone scopes.
In SeattleZoneScope , you can add the record www.contosogiftservices.com with IP address 192.0.0.1, which is
located in the Seattle datacenter.
In ChicagoZoneScope , you can add the same record (www.contosogiftservices.com) with IP address 182.0.0.1 in
the Chicago datacenter.
Similarly in DallasZoneScope , you can add a record (www.contosogiftservices.com) with IP address 162.0.0.1 in
the Chicago datacenter.
You can use the following Windows PowerShell commands to add records to the zone scopes.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.0.0.1" -

ZoneScope "SeattleZoneScope

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "182.0.0.1" -

ZoneScope "ChicagoZoneScope"

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "162.0.0.1" -

ZoneScope "DallasZoneScope"

For more information, see Add-DnsServerResourceRecord.

Create the DNS Policies
After you have created the partitions (zone scopes) and you have added records, you must create DNS policies that
distribute the incoming queries across these scopes so that 50% of queries for contosogiftservices.com are
responded to with the IP address for the Web server in the Seattle datacenter and the rest are equally distributed
between the Chicago and Dallas datacenters.
You can use the following Windows PowerShell commands to create a DNS policy that balances application traffic
across these three datacenters.

NOTE
In the example command below, the expression –ZoneScope "SeattleZoneScope,2; ChicagoZoneScope,1; DallasZoneScope,1"
configures the DNS server with an array that includes the parameter combination <ZoneScope>,<weight>.

Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -ZoneScope

"SeattleZoneScope,2;ChicagoZoneScope,1;DallasZoneScope,1" -ZoneName "contosogiftservices.com"

For more information, see Add-DnsServerQueryResolutionPolicy.

You have now successfully created a DNS policy that provides application load balancing across Web servers in
three different datacenters.
You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
 Use DNS Policy for Application Load Balancing With
Geo-Location Awareness
3/26/2020 • 4 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic to learn how to configure DNS policy to load balance an application with geo-location
awareness.
The previous topic in this guide, Use DNS Policy for Application Load Balancing, uses an example of a fictional
company - Contoso Gift Services - which provides online gifting services, and which has a Web site named
contosogiftservices.com. Contoso Gift Services load balances their online Web application between servers in
North American datacenters located in Seattle, WA, Chicago, IL, and Dallas, TX.

NOTE
It is recommended that you familiarize yourself with the topic Use DNS Policy for Application Load Balancing before
performing the instructions in this scenario.

This topic uses the same fictional company and network infrastructure as a basis for a new example deployment
that includes geo-location awareness.
In this example, Contoso Gift Services is successfully expanding their presence across the globe.
Similar to North America, the company now has web servers hosted in European datacenters.
Contoso Gift Services DNS Administrators want to configure application load balancing for European datacenters
in a similar manner to the DNS policy implementation in the United States, with application traffic distributed
among Web servers that are located in Dublin, Ireland, Amsterdam, Holland, and elsewhere.
DNS Administrators also want all queries from other locations in the world distributed equally between all of their
datacenters.
In the next sections you can learn how to achieve similar goals to those of the Contoso DNS Administrators on
your own network.

How to Configure Application Load Balancing with Geo-Location

Awareness
The following sections show you how to configure DNS policy for application load balancing with geo-location
awareness.

IMPORTANT
The following sections include example Windows PowerShell commands that contain example values for many parameters.
Ensure that you replace example values in these commands with values that are appropriate for your deployment before you
run these commands.

Create the DNS Client Subnets

You must first identify the subnets or IP address space of the North America and Europe regions.
You can obtain this information from Geo-IP maps. Based on these Geo-IP distributions, you must create the DNS
Client Subnets.
A DNS Client Subnet is a logical grouping of IPv4 or IPv6 subnets from which queries are sent to a DNS server.
You can use the following Windows PowerShell commands to create DNS Client Subnets.

Add-DnsServerClientSubnet -Name "AmericaSubnet" -IPv4Subnet 192.0.0.0/24,182.0.0.0/24

Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet 141.1.0.0/24,151.1.0.0/24

For more information, see Add-DnsServerClientSubnet.

Create the Zone Scopes
After the client subnets are in place, you must partition the zone contosogiftservices.com into different zone
scopes, each for a datacenter.
A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope
containing its own set of DNS records. The same record can be present in multiple scopes, with different IP
addresses or the same IP addresses.

NOTE
By default, a zone scope exists on the DNS zones. This zone scope has the same name as the zone, and legacy DNS
operations work on this scope.

The previous scenario on application load balancing demonstrates how to configure three zone scopes for
datacenters in North America.
With the commands below, you can create two more zone scopes, one each for the Dublin and Amsterdam
datacenters.
You can add these zone scopes without any changes to the three existing North America zone scopes in the same
zone. In addition, after you create these zone scopes, you do not need to restart your DNS server.
You can use the following Windows PowerShell commands to create zone scopes.

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DublinZoneScope"

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "AmsterdamZoneScope"

For more information, see Add-DnsServerZoneScope

Add Records to the Zone Scopes
Now you must add the records representing the web server host into the zone scopes.
The records for the America datacenters were added in the previous scenario. You can use the following Windows
PowerShell commands to add records to the zone scopes for European datacenters.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "151.1.0.1" -

ZoneScope "DublinZoneScope”
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "141.1.0.1" -
ZoneScope "AmsterdamZoneScope"

For more information, see Add-DnsServerResourceRecord.

Create the DNS Policies
After you have created the partitions (zone scopes) and you have added records, you must create DNS policies that
distribute the incoming queries across these scopes.
For this example, query distribution across application servers in different datacenters meets the following criteria.
1. When the DNS query is received from a source in a North American client subnet, 50% of the DNS responses
point to the Seattle data center, 25% of responses point to the Chicago datacenter, and the remaining 25% of
responses point to the Dallas datacenter.
2. When the DNS query is received from a source in a European client subnet, 50% of the DNS responses point to
the Dublin datacenter, and 50% of the DNS responses point to the Amsterdam datacenter.
3. When the query comes from anywhere else in the world, the DNS responses are distributed across all five
datacenters.
You can use the following Windows PowerShell commands to implement these DNS policies.

Add-DnsServerQueryResolutionPolicy -Name "AmericaLBPolicy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -

ZoneScope "SeattleZoneScope,2;ChicagoZoneScope,1; TexasZoneScope,1" -ZoneName "contosogiftservices.com" –
ProcessingOrder 1

Add-DnsServerQueryResolutionPolicy -Name "EuropeLBPolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -

ZoneScope "DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 2

Add-DnsServerQueryResolutionPolicy -Name "WorldWidePolicy" -Action ALLOW -FQDN "eq,*.contoso.com" -ZoneScope

"SeattleZoneScope,1;ChicagoZoneScope,1; TexasZoneScope,1;DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName
"contosogiftservices.com" -ProcessingOrder 3

For more information, see Add-DnsServerQueryResolutionPolicy.

You have now successfully created a DNS policy that provides application load balancing across Web servers that
are located in five different datacenters on multiple continents.
You can create thousands of DNS policies according to your traffic management requirements, and all new policies
are applied dynamically - without restarting the DNS server - on incoming queries.
 Troubleshooting Domain Name System (DNS) issues
4/7/2020 • 2 minutes to read • Edit Online

Domain Name resolution issues can be broken down into client-side and server-side issues. In general, you should
start with client-side troubleshooting unless you determine during the scoping phase that the issue is definitely
occurring on the server side.
Troubleshooting DNS clients
Troubleshooting DNS Servers

Data Collection
We recommend that you simultaneously collect data on both the client and server sides when the issue occurs.
However, depending on the actual issue, you can start your collection at a single data set on either the DNS client or
DNS server.
To collect a Windows Networking Diagnostic from an affected client and its configured DNS server, follow these
steps:
1. Start network captures on the client and server:

netsh trace start capture=yes tracefile=c:\%computername%_nettrace.etl

2. Clear the DNS cache on the DNS client by running the following command:

ipconfig /flushdns

3. Reproduce the issue.

4. Stop and save traces:

netsh trace stop

5. Save the Nettrace.cab files from each computer. This information will be helpful when you contact Microsoft
Support.
 Troubleshooting DNS clients
4/7/2020 • 2 minutes to read • Edit Online

This article discusses how to troubleshoot issues from DNS clients.

Check IP configuration
1. Open a Command Prompt window as an administrator on the client computer.
2. Run the following command:

ipconfig /all

3. Verify that the client has a valid IP address, subnet mask, and default gateway for the network to which it is
attached and being used.
4. Check the DNS servers that are listed in the output, and verify that the IP addresses listed are correct.
5. Check the connection-specific DNS suffix in the output and verify that it is correct.
If the client does not have a valid TCP/IP configuration, use one of the following methods:
For dynamically configured clients, use the ipconfig /renew command to manually force the client to renew
its IP address configuration with the DHCP server.
For statically configured clients, modify the client TCP/IP properties to use valid configuration settings or
complete its DNS configuration for the network.

Check network connection

Ping test
Verify that the client can contact a preferred (or alternate) DNS server by pinging the preferred DNS server by its IP
address.
For example, if the client uses a preferred DNS server of 10.0.0.1, run this command at a command prompt:

ping 10.0.0.1

If no configured DNS server responds to a direct pinging of its IP address, this indicates that the source of the
problem is more likely network connectivity between the client and the DNS servers. If this is the case, follow basic
TCP/IP network troubleshooting steps to fix the problem. Keep in mind that ICMP traffic must be allowed through
the firewall in order for the ping command to work.
DNS query tests
If the DNS client can ping the DNS server computer, try to use the following nslookup commands to test whether
the server can respond to DNS clients. Because nslookup doesn't use the client's DNS cache, name resolution will
use the client's configured DNS server.
Test a client

nslookup <client>
For example, if the client computer is named client1 , run this command:

nslookup client1

If a successful response is not returned, try to run the following command:

nslookup <fqdn of client>

For example, if the FQDN is client1.corp.contoso.com , run this command:

nslookup client1.corp.contoso.com.

NOTE
You must include the trailing period when you run this test.

If Windows successfully finds the FQDN but cannot find the short name, check the DNS Suffix configuration on the
DNS tab of the Advanced TCP/IP Settings of the NIC. For more information, see Configuring DNS Resolution.
Test the DNS server

nslookup <DNS Server>

For example, if the DNS server is named DC1, run this command:

nslookup dc1

If the previous tests were successful, this test should also be successful. If this test is not successful, verify the
connectivity to the DNS server.
Test the failing record

nslookup <failed internal record>

For example, if the failing record was app1.corp.contoso.com , run this command:

nslookup app1.corp.contoso.com

Test a public Internet address

nslookup <external name>

For example:

nslookup bing.com

If all four of these tests were successful, run ipconfig /displaydns and check the output for the name that failed. If
you see "Name does not exist" under the failing name, a negative response was returned from a DNS server and
was cached on the client.
To resolve the issue, clear the cache by running ipconfig /flushdns .

Next step
If name resolution is still failing, go to the Troubleshooting DNS Servers section.
 Disable DNS client-side caching on DNS clients
4/7/2020 • 3 minutes to read • Edit Online

Windows contains a client-side DNS cache. The client-side DNS caching feature may generate a false impression
that DNS "round robin" load balancing is not occurring from the DNS server to the Windows client computer. When
you use the ping command to search for the same A-record domain name, the client may use the same IP address.

How to disable client-side caching

To stop DNS caching, run either of the following commands:

net stop dnscache

sc servername stop dnscache

To disable the DNS cache permanently in Windows, use the Service Controller tool or the Services tool to set the
DNS Client service startup type to Disabled . Note that the name of the Windows DNS Client service may also
appear as "Dnscache."

NOTE
If the DNS resolver cache is deactivated, the overall performance of the client computer decreases and the network traffic for
DNS queries increases.

The DNS Client service optimizes the performance of DNS name resolution by storing previously resolved names
in memory. If the DNS Client service is turned off, the computer can still resolve DNS names by using the network's
DNS servers.
When the Windows resolver receives a response, either positive or negative, to a query, it adds that response to its
cache and thereby creates a DNS resource record. The resolver always checks the cache before it queries any DNS
server. If a DNS resource record is in the cache, the resolver uses the record from the cache instead of querying a
server. This behavior expedites queries and decreases network traffic for DNS queries.
You can use the ipconfig tool to view and flush the DNS resolver cache. To view the DNS resolver cache, run the
following command at a command prompt:

ipconfig /displaydns

This command displays the contents of the DNS resolver cache, including the DNS resource records that are
preloaded from the Hosts file and any recently queried names that were resolved by the system. After some time,
the resolver discards the record from the cache. The time period is specified by the Time to Live (TTL) value that
is associated with the DNS resource record. You can also flush the cache manually. After you flush the cache, the
computer must query DNS servers again for any DNS resource records that were previously resolved by the
computer. To delete the entries in the DNS resolver cache, run ipconfig /flushdns at a command prompt.

Using the registry to control the caching time

 IMPORTANT
Follow the steps in this section carefully. Serious problems might occur if you modify the registry incorrectly. Before you
modify it, back up the registry for restoration in case problems occur.

The length of time for which a positive or negative response is cached depends on the values of entries in the
following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\DNSCache\Parameters
The TTL for positive responses is the lesser of the following values:
The number of seconds specified in the query response the resolver received
The value of the MaxCacheTtl registry setting.

NOTE
The default TTL for positive responses is 86,400 seconds (1 day).
The TTL for negative responses is the number of seconds specified in the MaxNegativeCacheTtl registry setting.
The default TTL for negative responses is 900 seconds (15 minutes). If you do not want negative responses to be cached,
set the MaxNegativeCacheTtl registry setting to 0.

To set the caching time on a client computer:

1. Start Registry Editor (Regedit.exe).
2. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\Dnscache\Parameters
3. On the Edit menu, point to New, click DWORD Value, and then add the following registry values:
Value name: MaxCacheTtl
Data type: REG_DWORD
Value data: Default value 86400 seconds.
If you lower the Maximum TTL value in the client's DNS cache to 1 second, this gives the appearance
that the client-side DNS cache has been disabled.
Value name: MaxNegativeCacheTtl
Data type: REG_DWORD
Value data: Default value 900 seconds.
Set the value to 0 if you do not want negative responses to be cached.
4. Type the value that you want to use, and then click OK.
5. Quit Registry Editor.
 Troubleshooting DNS servers
4/7/2020 • 9 minutes to read • Edit Online

This article discusses how to troubleshoot issues on DNS servers.

Check IP configuration
1. Run ipconfig /all at a command prompt, and verify the IP address, subnet mask, and default gateway.
2. Check whether the DNS server is authoritative for the name that is being looked up. If so, see Checking for
problems with authoritative data.
3. Run the following command:

nslookup <name> <IP address of the DNS server>

For example:

nslookup app1 10.0.0.1

If you get a failure or time-out response, see Checking for recursion problems.
4. Flush the resolver cache. To do this, run the following command in an administrative Command Prompt
window:

dnscmd /clearcache

Or, in an administrative PowerShell window, run the following cmdlet:

Clear-DnsServerCache

5. Repeat step 3.

Check DNS server problems

Event log
Check the following logs to see whether there are any recorded errors:
Application
System
DNS Server
Test by using nslookup query
Run the following command and check whether the DNS server is reachable from client computers.

nslookup <client name> <server IP address>

 If the resolver returns the IP address of the client, the server does not have any problems.
If the resolver returns a "Server failure" or "Query refused" response, the zone is probably paused, or the
server is possibly overloaded. You can learn whether it's paused by checking the General tab of the zone
properties in the DNS console.
If the resolver returns a "Request to server timed out" or "No response from server" response, the DNS service
probably is not running. Try to restart the DNS Server service by entering the following at a command prompt on
the server:

net start DNS

If the issue occurs when the service is running, the server might not be listening on the IP address that you used in
your nslookup query. On the Interfaces tab of the server properties page in the DNS console, administrators can
restrict a DNS server to listen on only selected addresses. If the DNS server has been configured to limit service to
a specific list of its configured IP addresses, it's possible that the IP address that's used to contact the DNS server is
not in the list. You can try a different IP address in the list or add the IP address to the list.
In rare cases, the DNS server might have an advanced security or firewall configuration. If the server is located on
another network that is reachable only through an intermediate host (such as a packet filtering router or proxy
server), the DNS server might use a non-standard port to listen for and receive client requests. By default,
nslookup sends queries to DNS servers on UDP port 53. Therefore, if the DNS server uses any other port,
nslookup queries fail. If you think that this might be the problem, check whether an intermediate filter is
intentionally used to block traffic on well-known DNS ports. If it's not, try to modify the packet filters or port rules
on the firewall to allow traffic on UDP/TCP port 53.

Checking for problems with authoritative data

Check whether the server that returns the incorrect response is a primary server for the zone (the standard
primary server for the zone or a server that uses Active Directory integration to load the zone) or a server that's
hosting a secondary copy of the zone.
If the server is a primary server
The problem might be caused by user error when users enter data into the zone. Or, it might be caused by a
problem that affects Active Directory replication or dynamic update.
If the server is hosting a secondary copy of the zone
1. Examine the zone on the master server (the server from which this server pulls zone transfers).

NOTE
You can determine which server is the master server by examining the properties of the secondary zone in the DNS
console.

If the name is not correct on the master server, go to step 4.

2. If the name is correct on the master server, check whether the serial number on the master server is less
than or equal to the serial number on the secondary server. If it is, modify either the master server or the
secondary server so that the serial number on the master server is greater than than the serial number on
the secondary server.
3. On the secondary server, force a zone transfer from within the DNS console or by running the following
command:
 dnscmd /zonerefresh <zone name>

For example, if the zone is corp.contoso.com, enter: dnscmd /zonerefresh corp.contoso.com .

4. Examine the secondary server again to see whether the zone was transferred correctly. If not, you probably
have a zone transfer problem. For more information, see Zone Transfer Problems.
5. If the zone was transferred correctly, check whether the data is now correct. If not, the data is incorrect in the
primary zone. The problem might be caused by user error when users enter data into the zone. Or, it might
be caused by a problem that affects Active Directory replication or dynamic update.

Checking for recursion problems

For recursion to work successfully, all DNS servers that are used in the path of a recursive query must be able to
respond and forward correct data. If they can't, a recursive query can fail for any of the following reasons:
The query times out before it can be completed.
A server that's used during the query fails to respond.
A server that's used during the query provides incorrect data.
Start troubleshooting at the server that was used in your original query. Check whether this server forwards
queries to another server by examining the For warders tab in the server properties in the DNS console. If the
Enable for warders check box is selected, and one or more servers are listed, this server forwards queries.
If this server does forward queries to another server, check for problems that affect the server to which this server
forwards queries. To check for problems, see Check DNS Server problems. When that section instructs you to
perform a task on the client, perform it on the server instead.
If the server is healthy and can forward queries, repeat this step, and examine the server to which this server
forwards queries.
If this server does not forward queries to another server, test whether this server can query a root server. To do
this, run the following command:

nslookup
server <IP address of server being examined>
set q=NS

If the resolver returns the IP address of a root server, you probably have a broken delegation between the
root server and the name or IP address that you're trying to resolve. Follow the Test a broken delegation
procedure to determine where you have a broken delegation.
If the resolver returns a "Request to server timed out" response, check whether the root hints point to
functioning root servers. To do this, use the To view the current root hints procedure. If the root hints do
point to functioning root servers, you might have a network problem, or the server might use an advanced
firewall configuration that prevents the resolver from querying the server, as described in the Check DNS
server problems section. It's also possible that the recursive time-out default is too short.
Test a broken delegation
Begin the tests in the following procedure by querying a valid root server. The test takes you through a process of
querying all the DNS servers from the root down to the server that you're testing for a broken delegation.
1. At the command prompt on the server that you're testing, enter the following:
 nslookup
server <server IP address>
set norecursion
set querytype= <resource record type>
<FQDN>

NOTE
Resource record type is the type of resource record that you were querying for in your original query, and FQDN is
the FQDN for which you were querying (terminated by a period).

2. If the response includes a list of "NS" and "A" resource records for delegated servers, repeat step 1 for each
server and use the IP address from the "A" resource records as the server IP address.
If the response does not contain an "NS" resource record, you have a broken delegation.
If the response contains "NS" resource records, but no "A" resource records, enter set recursion ,
and query individually for "A" resource records of servers that are listed in the "NS" records. If you
do not find at least one valid IP address of an "A" resource record for each NS resource record in a
zone, you have a broken delegation.
3. If you determine that you have a broken delegation, fix it by adding or updating an "A" resource record in
the parent zone by using a valid IP address for a correct DNS server for the delegated zone.
To view the current root hints
1. Start the DNS console.
2. Add or connect to the DNS server that failed a recursive query.
3. Right-click the server, and select Proper ties .
4. Click Root Hints.
Check for basic connectivity to the root servers.
If root hints appear to be configured correctly, verify that the DNS server that's used in a failed name
resolution can ping the root servers by IP address.
If the root servers do not respond to pinging by IP address, the IP addresses for the root servers might have
changed. However, it's uncommon to see a reconfiguration of root servers.

Zone Transfer Problems

Run the following checks:
Check Event Viewer for both the primary and secondary DNS server.
Check the master server to see whether it's refusing to send the transfer for security.
Check the Zone Transfers tab of the zone properties in the DNS console. If the server restricts zone
transfers to a list of servers, such as those listed on the Name Ser vers tab of the zone properties, make
sure that the secondary server is on that list. Make sure that the server is configured to send zone transfers.
Check the master server for problems by following the steps in the Check DNS server problems section.
When you're prompted to perform a task on the client, perform the task on the secondary server instead.
Check whether the secondary server is running another DNS server implementation, such as BIND. If it is,
the problem might have one of the following causes:
 The Windows master server might be configured to send fast zone transfers, but the third-party
secondary server might not support fast-zone transfers. If this is the case, disable fast-zone transfers
on the master server from within the DNS console by selecting the Enable Bind secondaries check
box on the Advanced tab of the properties for your server.
If a forward lookup zone on the Windows server contains a record type (for example, an SRV record)
that the secondary server does not support, the secondary server might have problems pulling the
zone.
Check whether the master server is running another DNS server implementation, such as BIND. If so, it's possible
that the zone on the master server includes incompatible resource records that Windows does not recognize.
If either the master or secondary server is running another DNS server implementation, check both servers to
make sure that they support the same features. You can check the Windows server in the DNS console on the
Advanced tab of the properties page for the server. In addition to the Enable Bind secondaries box, this page
includes the Name checking drop-down list. This enables you to select enforcement of strict RFC compliance for
characters in DNS names.
 Dynamic Host Configuration Protocol (DHCP)
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic for a brief overview of DHCP in Windows Server 2016.

NOTE
In addition to this topic, the following DHCP documentation is available.
What's New in DHCP
Deploy DHCP Using Windows PowerShell

Dynamic Host Configuration Protocol (DHCP) is a client/server protocol that automatically provides an Internet
Protocol (IP) host with its IP address and other related configuration information such as the subnet mask and
default gateway. RFCs 2131 and 2132 define DHCP as an Internet Engineering Task Force (IETF) standard based on
Bootstrap Protocol (BOOTP), a protocol with which DHCP shares many implementation details. DHCP allows hosts
to obtain required TCP/IP configuration information from a DHCP server.
Windows Server 2016 includes DHCP Server, which is an optional networking server role that you can deploy on
your network to lease IP addresses and other information to DHCP clients. All Windows-based client operating
systems include the DHCP client as part of TCP/IP, and DHCP client is enabled by default.

Why use DHCP?

Every device on a TCP/IP-based network must have a unique unicast IP address to access the network and its
resources. Without DHCP, IP addresses for new computers or computers that are moved from one subnet to
another must be configured manually; IP addresses for computers that are removed from the network must be
manually reclaimed.
With DHCP, this entire process is automated and managed centrally. The DHCP server maintains a pool of IP
addresses and leases an address to any DHCP-enabled client when it starts up on the network. Because the IP
addresses are dynamic (leased) rather than static (permanently assigned), addresses no longer in use are
automatically returned to the pool for reallocation.
The network administrator establishes DHCP servers that maintain TCP/IP configuration information and provide
address configuration to DHCP-enabled clients in the form of a lease offer. The DHCP server stores the
configuration information in a database that includes:
Valid TCP/IP configuration parameters for all clients on the network.
Valid IP addresses, maintained in a pool for assignment to clients, as well as excluded addresses.
Reserved IP addresses associated with particular DHCP clients. This allows consistent assignment of a single
IP address to a single DHCP client.
The lease duration, or the length of time for which the IP address can be used before a lease renewal is
required.
A DHCP-enabled client, upon accepting a lease offer, receives:
A valid IP address for the subnet to which it is connecting.
 Requested DHCP options, which are additional parameters that a DHCP server is configured to assign to
clients. Some examples of DHCP options are Router (default gateway), DNS Servers, and DNS Domain
Name.

Benefits of DHCP
DHCP provides the following benefits.
Reliable IP address configuration . DHCP minimizes configuration errors caused by manual IP address
configuration, such as typographical errors, or address conflicts caused by the assignment of an IP address
to more than one computer at the same time.
Reduced network administration . DHCP includes the following features to reduce network
administration:
Centralized and automated TCP/IP configuration.
The ability to define TCP/IP configurations from a central location.
The ability to assign a full range of additional TCP/IP configuration values by means of DHCP options.
The efficient handling of IP address changes for clients that must be updated frequently, such as those
for portable devices that move to different locations on a wireless network.
The forwarding of initial DHCP messages by using a DHCP relay agent, which eliminates the need for
a DHCP server on every subnet.
 What's New in DHCP
6/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This topic describes the Dynamic Host Configuration Protocol (DHCP) functionality that is new or changed in
Windows Server 2016.
DHCP is an Internet Engineering Task Force (IETF) standard that is designed to reduce the administrative burden
and complexity of configuring hosts on a TCP/IP-based network, such as a private intranet. By using the DHCP
Server service, the process of configuring TCP/IP on DHCP clients is automatic.
The following sections provide information about new features and changes in functionality for DHCP.

DHCP Subnet Selection Options

DHCP now supports option 82 (sub-option 5). You can use this option to allow DHCP proxy clients and relay agents
to request an IP address for a specific subnet.
If you are using a DHCP relay agent that is configured with DHCP option 82, sub-option 5, the relay agent can
request an IP address lease for DHCP clients from a specific IP address range.
For more information, see DHCP Subnet Selection Options.

New Logging Events for DNS Registration Failures by the DHCP Server
DHCP now includes logging events for circumstances in which DHCP server DNS record registrations fail on the
DNS server.
For more information, see DHCP Logging Events for DNS Record Registrations.

DHCP NAP Is Not Supported in Windows Server 2016

Network Access Protection (NAP) is deprecated in Windows Server 2012 R2, and in Windows Server 2016 the
DHCP Server role no longer supports NAP. For more information, see Features Removed or Deprecated in
Windows Server 2012 R2.
NAP support was introduced to the DHCP Server role with Windows Server 2008, and is supported in Windows
client and server operating systems prior to Windows 10 and Windows Server 2016. The following table
summarizes support for NAP in Windows Server.

O P ERAT IN G SY ST EM N A P SUP P O RT

Windows Server 2008 Supported

Windows Server 2008 R2 Supported

Windows Server 2012 Supported

Windows Server 2012 R2 Supported

 O P ERAT IN G SY ST EM N A P SUP P O RT

Windows Server 2016 Not supported

In a NAP deployment, a DHCP server running an operating system that supports NAP can function as a NAP
enforcement point for the NAP DHCP enforcement method. For more information about DHCP in NAP, see
Checklist: Implementing a DHCP Enforcement Design.
In Windows Server 2016, DHCP servers do not enforce NAP policies, and DHCP scopes cannot be NAP-enabled.
DHCP client computers that are also NAP clients send a statement of health (SoH) with the DHCP request. If the
DHCP server is running Windows Server 2016, these requests are processed as if no SoH is present. The DHCP
server grants a normal DHCP lease to the client.
If servers that are running Windows Server 2016 are RADIUS proxies that forward authentication requests to a
Network Policy Server (NPS) that supports NAP, these NAP clients are evaluated by NPS as non NAP-capable, and
NAP processing fails.

Additional References
Dynamic Host Configuration Protocol (DHCP)
 DHCP Subnet Selection Options
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

You can use this topic for information about new DHCP subnet selection options.
DHCP now supports option 82 (sub-option 5). You can use these options to allow DHCP proxy clients and relay
agents to request an IP address for a specific subnet, and from a specific IP address range and scope. For more
details, see Option 82 Sub Option 5 : RFC 3527 Link Selection sub-option for the Relay Agent Information
Option for DHCPv4.
If you are using a DHCP relay agent that is configured with DHCP option 82, sub-option 5, the relay agent can
request an IP address lease for DHCP clients from a specific IP address range.

Option 82 Sub Option 5: Link Selection Sub Option

The Relay Agent Link Selection sub-option allows a DHCP Relay Agent to specify an IP subnet from which the DHCP
server should assign IP addresses and options.
Typically, DHCP relay agents rely on the Gateway IP Address (GIADDR) field to communicate with DHCP servers.
However, GIADDR is limited by its two operational functions:
1. To inform the DHCP server about the subnet upon which the DHCP client that is requesting the IP address lease
resides.
2. To inform the DHCP server of the IP address to use to communicate with the relay agent.
In some cases, the IP address that the relay agent uses to communicate with the DHCP server might be different
than the IP address range from which the DHCP client IP address needs to be allocated.
The Link Selection Sub option of option 82 is useful in this situation, allowing the relay agent to explicitly state the
subnet from which it wants the IP address allocated in the form of DHCP v4 option 82 sub option 5.

NOTE
All relay agent IP addresses (GIADDR) must be part of an active DHCP scope IP address range. Any GIADDR outside of the
DHCP scope IP address ranges is considered a rogue relay and Windows DHCP Server will not acknowledge DHCP client
requests from those relay agents.
A special scope can be created to "authorize" relay agents. Create a scope with the GIADDR (or multiple if the GIADDR's are
sequential IP addresses), exclude the GIADDR address(es) from distribution, and then activate the scope. This will authorize
the relay agents while preventing the GIADDR addresses from being assigned.

Use case scenario

In this scenario, an organization network includes both a DHCP server and a Wireless Access Point (AP) for the
guest users. Guests client IP addresses are assigned from the organization DHCP server - however, due to firewall
policy restrictions, the DHCP server cannot access the guest wireless network or wireless clients with broadcase
messages.
To resolve this restriction, the AP is configured with the Link Selection Sub Option 5 to specify the subnet from
which it wants the IP address allocated for guest clients, while in the GIADDR also specifying the IP address of the
internal interface that leads to the corporate network.
 DHCP Logging Events for DNS Registrations
3/26/2020 • 2 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

DHCP server event logs now provide detailed information about DNS registration failures.

NOTE
In many cases, the reason for DNS record registration failures by DHCP servers is that a DNS Reverse-Lookup Zone is either
configured incorrectly or not configured at all.

The following new DHCP events assist you to easily identify when DNS registrations are failing because of a
misconfigured or missing DNS Reverse-Lookup Zone.

ID EVEN T VA L UE

20317 DHCPv4.ForwardRecordDNSFailure Forward record registration for IPv4

address %1 and FQDN %2 failed with
error %3. This is likely to be because the
forward lookup zone for this record
does not exist on the DNS server.

20318 DHCPv4.ForwardRecordDNSTimeout Forward record registration for IPv4

address %1 and FQDN %2 failed with
error %3.

20319 DHCPv4.PTRRecordDNSFailure PTR record registration for IPv4 address

%1 and FQDN %2 failed with error %3.
This is likely to be because the reverse
lookup zone for this record does not
exist on the DNS server.

20320 DHCPv4.PTRRecordDNSTimeout PTR record registration for IPv4 address

%1 and FQDN %2 failed with error %3.

20321 DHCPv6.ForwardRecordDNSFailure Forward record registration for IPv6

address %1 and FQDN %2 failed with
error %3. This is likely to be because the
forward lookup zone for this record
does not exist on the DNS server.

20322 DHCPv6.ForwardRecordDNSTimeout Forward record registration for IPv6

address %1 and FQDN %2 failed with
error %3.

20323 DHCPv6.PTRRecordDNSFailure PTR record registration for IPv6 address

%1 and FQDN %2 failed with error %3.
This is likely to be because the reverse
lookup zone for this record does not
exist on the DNS server.
ID EVEN T VA L UE

20324 DHCPv6.PTRRecordDNSTimeout PTR record registration for IPv6 address

%1 and FQDN %2 failed with error %3.

20325 DHCPv4.ForwardRecordDNSError PTR record registration for IPv4 address

%1 and FQDN %2 failed with error %3
(%4).

20326 DHCPv6.ForwardRecordDNSError Forward record registration for IPv6

address %1 and FQDN %2 failed with
error %3 (%4)

20327 DHCPv6.PTRRecordDNSError PTR record registration for IPv6 address

%1 and FQDN %2 failed with error %3
(%4).
 Deploy DHCP Using Windows PowerShell
4/7/2020 • 22 minutes to read • Edit Online

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This guide provides instructions on how to use Windows PowerShell to deploy an Internet Protocol (IP) version 4
Dynamic Host Configuration Protocol (DHCP) server that automatically assigns IP addresses and DHCP options to
IPv4 DHCP clients that are connected to one or more subnets on your network.

NOTE
To download this document in Word format from TechNet Gallery, see Deploy DHCP Using Windows PowerShell in Windows
Server 2016.

Using DHCP servers to assign IP addresses saves in administrative overhead because you do not need to manually
configure the TCP/IP v4 settings for every network adapter in every computer on your network. With DHCP, TCP/IP
v4 configuration is performed automatically when a computer or other DHCP client is connected to your network.
You can deploy your DHCP server in a workgroup as a standalone server, or as part of an Active Directory domain.
This guide contains the following sections.
DHCP Deployment Overview
Technology Overviews
Plan DHCP Deployment
Using This Guide in a Test Lab
Deploy DHCP
Verify Server Functionality
Windows PowerShell Commands for DHCP
List of Windows PowerShell Commands in this guide

DHCP Deployment Overview

The following illustration depicts the scenario that you can deploy by using this guide. The scenario includes one
DHCP server in an Active Directory domain. The server is configured to provide IP addresses to DHCP clients on
two different subnets. The subnets are separated by a router that has DHCP Forwarding enabled.
Technology Overviews
The following sections provide brief overviews of DHCP and TCP/IP.
DHCP overview
DHCP is an IP standard for simplifying the management of host IP configuration. The DHCP standard provides for
the use of DHCP servers as a way to manage dynamic allocation of IP addresses and other related configuration
details for DHCP-enabled clients on your network.
DHCP allows you to use a DHCP server to dynamically assign an IP address to a computer or other device, such as
a printer, on your local network, rather than manually configuring every device with a static IP address.
Every computer on a TCP/IP network must have a unique IP address, because the IP address and its related subnet
mask identify both the host computer and the subnet to which the computer is attached. By using DHCP, you can
ensure that all computers that are configured as DHCP clients receive an IP address that is appropriate for their
network location and subnet, and by using DHCP options, such as default gateway and DNS servers, you can
automatically provide DHCP clients with the information that they need to function correctly on your network.
For TCP/IP-based networks, DHCP reduces the complexity and amount of administrative work involved in
configuring computers.
TCP/IP overview
By default, all versions of Windows Server and Windows Client operating systems have TCP/IP settings for IP
version 4 network connections configured to automatically obtain an IP address and other information, called
DHCP options, from a DHCP server. Because of this, you do not need to configure TCP/IP settings manually unless
the computer is a server computer or other device that requires a manually configured, static IP address.
For example, it is recommended that you manually configure the IP address of the DHCP server, and the IP
addresses of DNS servers and domain controllers that are running Active Directory Domain Services (AD DS).
TCP/IP in Windows Server 2016 is the following:
Networking software based on industry-standard networking protocols.
A routable enterprise networking protocol that supports the connection of your Windows-based computer
to both local area network (LAN) and wide area network (WAN) environments.
Core technologies and utilities for connecting your Windows-based computer with dissimilar systems for
the purpose of sharing information.
A foundation for gaining access to global Internet services, such as Web and File Transfer Protocol (FTP)
 servers.
A robust, scalable, cross-platform, client/server framework.
TCP/IP provides basic TCP/IP utilities that enable Windows-based computers to connect and share information with
other Microsoft and non-Microsoft systems, including:
Windows Server 2016
Windows 10
Windows Server 2012 R2
Windows 8.1
Windows Server 2012
Windows 8
Windows Server 2008 R2
Windows 7
Windows Server 2008
Windows Vista
Internet hosts
Apple Macintosh systems
IBM mainframes
UNIX and Linux systems
Open VMS systems
Network-ready printers
Tablets and cellular telephones with wired Ethernet or wireless 802.11 technology enabled

Plan DHCP Deployment

Following are key planning steps before installing the DHCP server role.
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 prefix 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 and
router/default gateway 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.

A DDRESS C L A SS B IT S F O R SUB N ET M A SK SUB N ET M A SK

Class A 11111111 00000000 00000000 255.0.0.0

00000000

Class B 11111111 11111111 00000000 255.255.0.0

00000000

Class C 11111111 11111111 11111111 255.255.255.0

00000000

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 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
When you create a scope on a DHCP server, you specify an IP address range that includes all of the IP addresses
that the DHCP server is allowed to lease to DHCP clients, such as computers and other devices. If you then go and
manually configure some servers and other devices with static IP addresses from the same IP address range that
the DHCP server is using, you can accidentally create an IP address conflict, where you and the DHCP server have
both assigned the same IP address to different devices.
To solve this problem, you can create an exclusion range for the DHCP scope. An exclusion range is a contiguous
range of IP addresses within the scope's IP address range that the DHCP server is not allowed to use. If you create
an exclusion range, the DHCP server does not assign the addresses in that range, allowing you to manually assign
these addresses without creating an IP address conflict.
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 10.0.0.1 -
10.0.0.254 and a subnet mask of 255.255.255.0.

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES

Exclusion range Start IP Address 10.0.0.1

Exclusion range End IP Address 10.0.0.25

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.

C O N F IGURAT IO N IT EM S EXA M P L E VA L UES

Network Connect Bindings Ethernet

DNS Server Settings DC1.corp.contoso.com

Preferred DNS server IP address 10.0.0.2

 C O N F IGURAT IO N IT EM S EXA M P L E VA L UES

Scope values 1. Primary Subnet

1. Scope Name 2. 10.0.0.1
2. Starting IP Address 3. 10.0.0.254
3. Ending IP Address 4. 255.255.255.0
4. Subnet Mask 5. 10.0.0.1
5. Default Gateway (optional) 6. 8 days
6. Lease duration

IPv6 DHCP Server Operation Mode Not enabled

Using This Guide in a Test Lab

You can use this guide to deploy DHCP in a test lab before you deploy in a production environment.

NOTE
If you do not want to deploy DHCP in a test lab, you can skip to the section Deploy DHCP.

The requirements for your lab differ depending on whether you are using physical servers or virtual machines
(VMs), and whether you are using an Active Directory domain or deploying a standalone DHCP server.
You can use the following information to determine the minimum resources you need to test DHCP deployment
using this guide.
Test Lab requirements with VMs
To deploy DHCP in a test lab with VMs, you need the following resources.
For either domain deployment or standalone deployment, you need one server that is configured as a Hyper-V
host.
Domain deployment
This deployment requires one physical server, one virtual switch, two virtual servers, and one virtual client:
On your physical server, in Hyper-V Manager, create the following items.
1. One Internal virtual switch. Do not create an External virtual switch, because if your Hyper-V host is on a
subnet that includes a DHCP server, your test VMs will receive an IP address from your DHCP server. In addition,
the test DHCP server that you deploy might assign IP addresses to other computers on the subnet where the
Hyper-V host is installed.
2. One VM running Windows Server 2016 configured as a domain controller with Active Directory Domain
Services that is connected to the Internal virtual switch you created. To match this guide, this server must have a
statically configured IP address of 10.0.0.2. For information on deploying AD DS, see the section Deploying
DC1 in the Windows Server 2016 Core Network Guide.
3. One VM running Windows Server 2016 that you will configure as a DHCP server by using this guide and that is
connected to the Internal virtual switch you created.
4. One VM running a Windows client operating system that is connected to the Internal virtual switch you created
and that you will use to verify that your DHCP server is dynamically allocating IP addresses and DHCP options
to DHCP clients.
Standalone DHCP ser ver deployment
This deployment requires one physical server, one virtual switch, one virtual server, and one virtual client:
On your physical server, in Hyper-V Manager, create the following items.
1. One Internal virtual switch. Do not create an External virtual switch, because if your Hyper-V host is on a
subnet that includes a DHCP server, your test VMs will receive an IP address from your DHCP server. In addition,
the test DHCP server that you deploy might assign IP addresses to other computers on the subnet where the
Hyper-V host is installed.
2. One VM running Windows Server 2016 that you will configure as a DHCP server by using this guide and that is
connected to the Internal virtual switch you created.
3. One VM running a Windows client operating system that is connected to the Internal virtual switch you created
and that you will use to verify that your DHCP server is dynamically allocating IP addresses and DHCP options
to DHCP clients.
Test Lab requirements with physical servers
To deploy DHCP in a test lab with physical servers, you need the following resources.
Domain deployment
This deployment requires one hub or switch, two physical servers and one physical client:
1. One Ethernet hub or switch to which you can connect the physical computers with Ethernet cables
2. One physical computer running Windows Server 2016 configured as a domain controller with Active Directory
Domain Services. To match this guide, this server must have a statically configured IP address of 10.0.0.2. For
information on deploying AD DS, see the section Deploying DC1 in the Windows Server 2016 Core Network
Guide.
3. One physical computer running Windows Server 2016 that you will configure as a DHCP server by using this
guide.
4. One physical computer running a Windows client operating system that you will use to verify that your DHCP
server is dynamically allocating IP addresses and DHCP options to DHCP clients.

NOTE
If you do not have enough test machines for this deployment, you can use one test machine for both AD DS and DHCP -
however this configuration is not recommended for a production environment.

Standalone DHCP ser ver deployment

This deployment requires one hub or switch, one physical server, and one physical client:
1. One Ethernet hub or switch to which you can connect the physical computers with Ethernet cables
2. One physical computer running Windows Server 2016 that you will configure as a DHCP server by using this
guide.
3. One physical computer running a Windows client operating system that you will use to verify that your DHCP
server is dynamically allocating IP addresses and DHCP options to DHCP clients.

Deploy DHCP
This section provides example Windows PowerShell commands that you can use to deploy DHCP on one server.
Before you run these example commands on your server, you must modify the commands to match your network
and environment.
For example, before you run the commands, you should replace example values in the commands for the following
items:
Computer names
IP Address range for each scope you want to configure (1 scope per subnet)
 Subnet mask for each IP address range you want to configure
Scope name for each scope
Exclusion range for each scope
DHCP option values, such as default gateway, domain name, and DNS or WINS servers
Interface names

IMPORTANT
Examine and modify every command for your environment before you run the command.

Where to Install DHCP - on a physical computer or a VM?

You can install the DHCP server role on a physical computer or on a virtual machine (VM) that is installed on a
Hyper-V host. If you are installing DHCP on a VM and you want the DHCP server to provide IP address assignments
to computers on the physical network to which the Hyper-V host is connected, you must connect the VM virtual
network adapter to a Hyper-V Virtual Switch that is External .
For more information, see the section Create a Vir tual Switch with Hyper-V Manager in the topic Create a
virtual network.
Run Windows PowerShell as an Administrator
You can use the following procedure to run Windows PowerShell with Administrator privileges.
1. On a computer running Windows Server 2016, click Star t , then right-click the Windows PowerShell icon. A
menu appears.
2. In the menu, click More , and then click Run as administrator . If prompted, type the credentials for an
account that has Administrator privileges on the computer. If the user account with which you are logged on
to the computer is an Administrator level account, you will not receive a credential prompt.
3. Windows PowerShell opens with Administrator privileges.
Rename the DHCP server and configure a static IP address
If you have not already done so, you can u