Documentação de Rede

Dê a sua opinião sobre a experiência de download do PDF.
Documentação de rede
A rede é uma parte fundamental da plataforma SDDC (Datacenter definido pelo
software), e o Windows Server 2016 oferece tecnologias SDN (Rede definida pelo
software) novas e melhores para ajudar você a mudar para uma solução SDDC
totalmente pensada para a sua organização.
Sobre rede
ｅ VISÃO GERAL
Cenários de rede com suporte do Windows Server
ｈ NOVIDADES
Novidades na rede
ｉ REFERÊNCIA
Bibliotecas do Windows Server
Conteúdo desativado do Windows Server 2003/2003 R2
Rede definida pelo software
ｅ VISÃO GERAL
Rede definida pelo software (SDN)
Controlador de rede
Balanceamento de carga do software (SLB) para SDN
Gateway de RAS para SDN
Virtualização de função de rede
Visão geral do firewall do datacenter
｀ IMPLANTAR
Implantar uma infraestrutura SDN usando scripts

Tecnologias de rede
ｅ VISÃO GERAL
BranchCache
Guia da Rede Principal
DirectAccess
Sistema de nome de domínio (DNS)
Protocolo DHCP
Virtualização de Rede Hyper-V
Comutador Virtual Hyper-V
IPAM (Gerenciamento de Endereços IP)
NLB (Balanceamento de Carga de Rede)
Tecnologias de rede
ｅ VISÃO GERAL
Servidor de Políticas de Rede
Shell de Rede (Netsh)
Ajuste do desempenho de subsistemas de rede
Política de QoS (qualidade de serviço)
Serviço de Cadastramento na Internet do Windows (WINS)
Acesso remoto
Rede de contêineres do Windows
VPN (rede virtual privada)
ｉ REFERÊNCIA
Proxy de aplicativo Web no Windows Server 2016
Guia de implantação de acesso remoto com a VPN Always On
Rede de Alto Desempenho

ｅ VISÃO GERAL
Rede de Alto Desempenho

Cenários de rede com suporte do
Windows Server
Artigo • 21/12/2022 • 5 minutos para o fim da leitura
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server (Canal
Semestral), Windows Server 2016
Este tópico fornece informações sobre cenários com suporte e sem suporte que você
pode ou não executar com esta versão do Windows Server 2016.
） Importante
Para todos os cenários de produção, use os drivers de hardware assinados mais

recentes do fabricante original do equipamento (OEM) ou do IHV (fornecedor
independente de hardware).
Cenários de rede com suporte

Esta seção inclui informações sobre os cenários de rede com suporte para Windows
Server 2016 e inclui as seguintes categorias de cenário.
Cenários de SDN (Rede Definida pelo Software)
Cenários de plataforma de rede
Cenários do servidor DNS
IPAM cenários com DHCP e DNS
Cenários de NIC Teaming
Cenários set (switch embedded teaming)
Cenários de SDN (Rede Definida pelo Software)

Você pode usar a documentação a seguir para implantar cenários de SDN com Windows
Server 2016.
Implantar uma infraestrutura de rede definida pelo software usando scripts

Para obter mais informações, consulte SDN (Rede Definida pelo Software).
Cenários do Controlador de Rede

Os cenários do Controlador de Rede permitem que você:
Implante e gerencie uma instância de vários nós do Controlador de Rede. Para

obter mais informações, consulte Deploy Network Controller using Windows
PowerShell.
Use o Controlador de Rede para definir programaticamente a política de rede

usando a API rest Northbound.
Use o Controlador de Rede para criar e gerenciar redes virtuais com a Virtualização
de Rede Hyper-V usando o encapsulamento NVGRE ou VXLAN.
Para obter mais informações, consulte Controlador de Rede.
Cenários de NFV (Virtualização de Função de Rede)
Os cenários de NFV permitem que você:
Implante e use um balanceador de carga de software para distribuir o tráfego de

northbound e southbound.
Implante e use um balanceador de carga de software para distribuir o tráfego de

saída leste e oeste para redes virtuais criadas com a Virtualização de Rede Hyper-
V.
Implante e use um balanceador de carga de software NAT para redes virtuais

criadas com a Virtualização de Rede Hyper-V.
Implantar e usar um gateway de encaminhamento de Camada 3
Implantar e usar um gateway de VPN (rede virtual privada) para túneis IPsec
(IKEv2) site a site
Implante e use um gateway GRE (Encapsulamento de Roteamento Genérico).
Implante e configure o roteamento dinâmico e o roteamento de trânsito entre

sites usando Border Gateway Protocol (BGP).
Configure a redundância M+N para a Camada 3 e gateways site a site e para

roteamento BGP.
Use o Controlador de Rede para especificar ACLs em redes virtuais e adaptadores
de rede.
Para obter mais informações, consulte Network Function Virtualization.
Cenários de plataforma de rede

Para os cenários desta seção, a equipe Windows De rede do servidor do Windows
Server 2016 dá suporte ao uso de qualquer Windows Server 2016 certificado. Verifique
com o fabricante da placa de interface de rede (NIC) para garantir que você tenha as
atualizações de driver mais recentes.
Os cenários de plataforma de rede permitem que você:
Use uma NIC convergida para combinar o tráfego RDMA e Ethernet usando um
único adaptador de rede.
Crie um caminho de dados de baixa latência usando o Packet Direct, habilitado no

Com switch virtual do Hyper-V e um único adaptador de rede.
Configure SET para difundir fluxos de tráfego SMB Direct e RDMA entre até dois
adaptadores de rede.
Para obter mais informações, consulte Remote Direct Memory Access (RDMA) e Switch
Embedded Teaming (SET).
Cenários de com switch virtual do Hyper-V
Os cenários do Com switch virtual do Hyper-V permitem que você:
Criar um comutamento virtual do Hyper-V com uma vNIC de RDMA (Acesso

Remoto Direto à Memória)
Criar um comutamento virtual hyper-V com set (comutamento inserido) e vNICs

RDMA
Criar uma equipe SET no Com switch virtual do Hyper-V
Gerenciar uma equipe SET usando Windows PowerShell comandos
Embedded Teaming (SET)
Cenários do servidor DNS

Os cenários do Servidor DNS permitem que você:
Especificar o Geo-Location de tráfego baseado em dados usando políticas DNS
Configurar DNS de dupla encefálica usando políticas DNS
Aplicar filtros em consultas DNS usando políticas DNS
Configurar o balanceamento de carga do aplicativo usando políticas DNS
Especificar respostas DNS inteligentes com base na hora do dia
Configurar políticas de transferência de zona DNS
Configurar políticas de servidor DNS em Active Directory Domain Services (AD DS)
integradas
Configurar a limitação da taxa de resposta
Especificar autenticação baseada em DNS de entidades nomeadas (LTD)
Configurar suporte para registros desconhecidos no DNS
Para obter mais informações, consulte os tópicos Novidades no cliente DNS no

Windows Server 2016 e Novidades no servidor DNS no Windows Server 2016.
IPAM cenários com DHCP e DNS

Os IPAM de dados permitem que você:
Descobrir e administrar servidores DNS e DHCP e endereçamento IP em várias

florestas federadas do Active Directory
Use IPAM gerenciamento centralizado de propriedades DNS, incluindo zonas e

registros de recursos.
Defina políticas granulares de controle de acesso baseado em função e delegar

IPAM usuários ou grupos de usuários para gerenciar o conjunto de propriedades
DNS que você especificar.
Use os comandos Windows PowerShell para IPAM automatizar a configuração de

controle de acesso para DHCP e DNS.
Para obter mais informações, consulte Gerenciar IPAM.
Cenários de NIC Teaming

Os cenários de NIC Teaming permitem que você:
Criar uma equipe de NIC em uma configuração com suporte
Excluir uma equipe de NIC
Adicionar adaptadores de rede à equipe de NIC em uma configuração com

suporte
Remover adaptadores de rede da equipe de NIC
７ Observação
No Windows Server 2016, você pode usar o NIC Teaming no Hyper-V, no entanto,
em alguns casos, as VMQs (Filas de Máquina Virtual) podem não ser habilitadas
automaticamente nos adaptadores de rede subjacentes quando você cria uma
equipe NIC. Se isso ocorrer, você poderá usar o seguinte comando Windows
PowerShell para garantir que a VMQ está habilitada nos adaptadores de membro
da equipe NIC: Set-NetAdapterVmq -Name <NetworkAdapterName> -Enable
Cenários set (switch embedded teaming)

SET é uma solução alternativa de NIC Teaming que você pode usar em ambientes que
incluem o Hyper-V e a pilha SDN (Rede Definida pelo Software) no Windows Server
2016. SET integra algumas funcionalidades de NIC Teaming no Com switch virtual do
Hyper-V.
Embedded Teaming (SET)
Cenários de rede sem suporte

Não há suporte para os cenários de rede a seguir Windows Server 2016.
Redes virtuais de locatário baseadas em VLAN.
Não há suporte para IPv6 na sobreposição ou na sobreposição.

Novidades na rede
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
O seguinte fornece informações sobre tecnologias de rede novas ou aprimoradas no

Windows Server 2016.
Este tópico contém as seguintes seções:
Novos recursos e tecnologias de rede

Novos recursos para tecnologias de rede adicionais
Novos recursos e tecnologias de rede

A rede é uma parte fundamental da plataforma SDDC (Datacenter definido pelo
software), e o Windows Server 2016 oferece tecnologias SDN (Rede definida pelo
software) novas e melhores para ajudar você a mudar para uma solução SDDC
totalmente pensada para a sua organização.
Ao gerenciar redes como um recurso de software definido, você pode descrever os

requisitos de infraestrutura de um aplicativo uma vez e, em seguida, escolher onde o
aplicativo é executado no local ou na nuvem. Essa consistência significa que agora os
aplicativos são mais fáceis de dimensionar e você pode executar aplicativos de forma
simples em qualquer lugar com confiança igual em relação à segurança, ao
desempenho, à qualidade do serviço e à disponibilidade. As seções a seguir contêm
informações sobre esses novos recursos e tecnologias de rede.
Infraestrutura de rede definida pelo software

Estas são as tecnologias de infraestrutura SDN novas ou aprimoradas:
Controlador de rede. novidade no Windows Server 2016, o controlador de rede

fornece um ponto de automação centralizado e programável para gerenciar,
configurar, monitorar e solucionar problemas de infraestrutura de rede física e
virtual em seu datacenter. Usando o Controlador de Rede, você pode automatizar
a configuração da infraestrutura de rede em vez de executar a configuração
manual dos dispositivos e dos serviços de rede. Para obter mais informações,
consulte controlador de rede e implantar redes definidas por software usando
scripts.
Comutador virtual do Hyper-V. O comutador virtual do Hyper-V é executado em
hosts Hyper-V e permite que você crie comutação distribuída e roteamento e uma
camada de imposição de política que esteja alinhada e compatível com Microsoft
Azure. Para saber mais, consulte Comutador Virtual do Hyper-V.
NFV (virtualização de função de rede). Nos data centers definidos pelo software
de hoje, as funções de rede que estão sendo executadas por dispositivos de
hardware (como balanceadores de carga, firewalls, roteadores, comutadores etc.)
são cada vez mais implantadas como dispositivos virtuais. Essa "virtualização da
função de rede" é uma progressão natural de virtualização do servidor e de
virtualização de rede. Os dispositivos virtuais estão surgindo rapidamente e
criando um mercado totalmente novo. Eles continuam gerando interesse e
conquistam impulso nas plataformas de virtualização e nos serviços de nuvem. As
tecnologias NFV a seguir estão disponíveis em Windows Server 2016.
Firewall do datacenter. Esse firewall distribuído fornece ACLs (listas de controle

de acesso) granulares, permitindo que você aplique políticas de firewall no nível
da interface da VM ou no nível da sub-rede. Para obter mais informações,
consulte visão geral do firewall do datacenter.
Gateway de Ras. Você pode usar o gateway de RAS para roteamento de tráfego
entre redes virtuais e redes físicas, incluindo conexões VPN site a site de seu
datacenter de nuvem para sites remotos de seus locatários. especificamente,
você pode implantar protocolo IKE a IKEv2 (redes virtuais privadas) site a site
(VPNs), VPN de camada 3 (L3) e gateways de túnel de roteamento genérico
(GRE). Além disso, agora há suporte para pools de gateway e redundância M +
N de gateways; e Border Gateway Protocol (BGP) com recursos de refletor de
rota fornecem roteamento dinâmico entre redes para todos os cenários de
gateway (VPN IKEv2, VPN GRE e VPN L3). Para obter mais informações, consulte
What ' s New in RAS gateway and RAS gateway for Sdn.
Load Balancer de software (SLB) e conversão de endereços de rede (NAT). O

balanceador de carga da camada 4-Sul e leste-oeste e o NAT aprimoram a taxa
de transferência ao dar suporte ao retorno direto de servidor, com o qual o
tráfego de rede de retorno pode ignorar o multiplexador de balanceamento de
carga. Para obter mais informações, consulte balanceamento de carga de
software (SLB) para Sdn e virtualização de função de rede.
Protocolos padronizados. O controlador de rede usa a transferência de estado de

reapresentação (REST) em sua interface Northbound com cargas JavaScript Object
Notation (JSON). A interface Southbound do controlador de rede usa o protocolo
de gerenciamento de banco de dados vSwitch (OVSDB) aberto.
Tecnologias de encapsulamento flexíveis. Essas tecnologias operam no plano de
dados e dão suporte tanto ao VxLAN (virtual Extensible LAN) quanto ao NVGRE
(encapsulamento de roteamento genérico de virtualização de rede). Para obter
mais informações, consulte túnel GRE em Windows Server 2016. Para obter mais
informações sobre SDN, consulte software defined Networking (SDN).
Conceitos básicos de escala de nuvem

Os seguintes conceitos básicos de escala de nuvem agora estão disponíveis:
NIC (placa de interface de rede) convergida. A NIC convergida permite que você
use um único adaptador de rede para gerenciamento, armazenamento habilitado
para RDMA (acesso remoto direto à memória) e tráfego de locatário. Isso reduz as
despesas de capital associadas a cada servidor em seu datacenter, pois você
precisa de menos adaptadores de rede para gerenciar diferentes tipos de tráfego
por servidor.
Pacote direto. O pacote direto fornece uma alta taxa de transferência de tráfego
de rede e uma infra-estrutura de processamento de pacotes de baixa latência.
Alterne a equipe inserida (Set). O conjunto é uma solução de agrupamento NIC

integrada ao comutador virtual Hyper-V. SET permite o agrupamento de até oito
NICS físicas em uma única equipe de conjunto, o que melhora a disponibilidade e
fornece failover. no Windows Server 2016, você pode criar equipes definidas que
são restritas ao uso de protocolo SMB e RDMA. Além disso, você pode usar o SET
Teams para distribuir o tráfego de rede para virtualização de rede Hyper-V. Para
obter mais informações, consulte acesso remoto direto à memória (RDMA) e
Comutador incorporado (Set).
Novos recursos para tecnologias de rede

adicionais
Esta seção contém informações sobre os novos recursos para tecnologias de rede
familiares.
DHCP
O DHCP é um padrão IETF (Internet Engineering Task Force) projetado para reduzir a
carga administrativa e a complexidade da configuração de hosts em uma rede baseada
em TCP/IP, por exemplo, uma intranet privada. Usando o serviço de servidor DHCP, o
processo de configuração de TCP/IP em clientes DHCP é automático. Para obter mais
informações, consulte What ' s New in DHCP.
DNS
DNS é um sistema usado em redes TCP/IP para nomear computadores e serviços de
rede. A nomeação DNS localiza computadores e serviços por meio de nomes simples.
Quando um usuário insere um nome DNS em um aplicativo, os serviços DNS podem
resolvê-lo para outra informação associada a ele, como um endereço IP.
As seções a seguir fornecem informações sobre o cliente DNS e o servidor DNS.
Cliente DNS
A seguir está uma tecnologia de cliente DNS nova ou aprimorada:
Associação de serviço do cliente DNS. no Windows 10, o serviço cliente DNS

oferece suporte aprimorado para computadores com mais de uma interface de
rede. Para obter mais informações, consulte o que há de novo no cliente DNS no
Windows Server 2016
Servidor DNS
A seguir estão as tecnologias de servidor DNS novas ou aprimoradas:
Políticas de DNS. Você pode configurar as políticas de DNS para especificar como
um servidor DNS responde a consultas DNS. As respostas DNS podem ser
baseadas no endereço IP do cliente (local), na hora do dia e em vários outros
parâmetros. As políticas de DNS habilitam o DNS com reconhecimento de local, o
gerenciamento de tráfego, o balanceamento de carga, o DNS de divisão e outros
cenários.
Suporte do nano Server para DNS baseado em arquivo. você pode implantar o
servidor DNS em Windows Server 2016 em uma imagem do Nano server. Essa
opção de implantação estará disponível se você estiver usando DNS baseado em
arquivo. Ao executar o servidor DNS em uma imagem do nano Server, você pode
executar seus servidores DNS com espaço reduzido, inicialização rápida e
aplicação de patch minimizada.
７ Observação
Não há suporte para o DNS integrado Active Directory no nano Server.

Limitação de taxa de resposta (RRL). Você pode habilitar a limitação da taxa de
resposta em seus servidores DNS. Ao fazer isso, você evita a possibilidade de
sistemas mal-intencionados que usam seus servidores DNS para iniciar um ataque
de negação de serviço em um cliente DNS.
Autenticação baseada em DNS de entidades nomeadas (sundanês). Você pode

usar os registros TLSA (autenticação de segurança de camada de transporte) para
fornecer informações aos clientes DNS que afirmam qual autoridade de
certificação (CA) eles devem esperar um certificado para seu nome de domínio.
Isso impede ataques man-in-the-Middle, em que alguém pode corromper o cache
DNS para apontar para seu próprio site e fornecer um certificado emitido por uma
autoridade de certificação diferente.
Suporte a registro desconhecido.

você pode adicionar registros que não são
explicitamente suportados pelo servidor DNS Windows usando a funcionalidade
de registro desconhecida.
Dicas de raiz IPv6.

Você pode usar o suporte de dicas de raiz IPV6 nativo para
executar a resolução de nomes da Internet usando os servidores raiz IPV6.
suporte a Windows PowerShell aprimorado.

novos cmdlets Windows PowerShell
estão disponíveis para o servidor DNS.
Para obter mais informações, consulte What ' s New in DNS Server in Windows Server
2016
Túnel GRE
O gateway de RAS agora dá suporte a túneis GRE (encapsulamento de roteamento
genérico) de alta disponibilidade para conexões site a site e a redundância M + N de
gateways. GRE é um protocolo de túnel leve que pode encapsular uma ampla variedade
de protocolos de camada de rede em links de ponto a ponto virtuais por meio de uma
ligação entre redes de protocolo de Internet. Para obter mais informações, consulte
túnel GRE em Windows Server 2016.

introduzido em Windows Server 2012, a virtualização de rede do Hyper-V (HNV)
permite a virtualização de redes de clientes sobre uma infraestrutura de rede física
compartilhada. com as alterações mínimas necessárias na malha de rede física, o HNV
dá aos provedores de serviços a agilidade para implantar e migrar cargas de trabalho de
locatário em qualquer lugar nas três nuvens: a nuvem do provedor de serviços, a nuvem
privada ou a nuvem pública Microsoft Azure. Para obter mais informações, consulte o
que há de novo na virtualização de rede Hyper-V em Windows Server 2016
IPAM
o IPAM fornece recursos administrativos e de monitoramento altamente personalizáveis
para o endereço IP e a infraestrutura de DNS em uma rede da organização. usando
IPAM, você pode monitorar, auditar e gerenciar servidores que estão executando o
protocolo DHCP e o DNS (sistema de nomes de domínio).
Gerenciamento de endereços IP aprimorado.

IPAM recursos são aprimorados para
cenários como o tratamento de sub-redes IPv4/32 e IPv6/128 e a localização de
sub-redes de endereço ip e intervalos livres em um bloco de endereço ip.
Gerenciamento de serviço DNS avançado.

o IPAM dá suporte ao registro de
recurso dns, encaminhador condicional e gerenciamento de zona dns para
servidores DNS integrados ao Active Directory domínio e com backup em arquivo.
DNS integrado, DHCP e gerenciamento de endereço IP (DDI).

Várias experiências
novas e operações de gerenciamento de ciclo de vida integradas são habilitadas,
como visualização de todos os registros de recursos DNS que pertencem a um
endereço IP, inventário automatizado de endereços IP com base em registros de
recursos DNS e gerenciamento de ciclo de vida de endereço IP para operações de
DNS e DHCP.
Suporte a florestas múltiplas Active Directory.

você pode usar IPAM para
gerenciar os servidores DNS e DHCP de várias florestas do Active Directory quando
houver uma relação de confiança bidirecional entre a floresta em que IPAM está
instalado e cada uma das florestas remotas.
Windows PowerShell suporte para controle de acesso baseado em função.

você
pode usar Windows PowerShell para definir escopos de acesso em objetos IPAM.
para obter mais informações, consulte o que há de novo em IPAM e gerenciar IPAM.
novos recursos do HPN no Windows Server

2019
o seguinte fornece informações sobre tecnologias de rede novas ou aprimoradas no
VRSS e VMMQ dinâmicos
Aplica-se a: Azure Stack HCI, versão 20H2; Windows Server 2019
No passado, as filas de máquinas virtuais e as várias filas de máquinas virtuais permitiam

uma taxa de transferência muito maior para VMs individuais, já que as taxas de
transferência de rede chegaram pela primeira vez à marca de 10 GbE e além.
Infelizmente, o planejamento, a linha de base, o ajuste e o monitoramento necessários
para o sucesso se tornaram um grande empreendimento; muitas vezes, o administrador
de ti pretende gastar.
o Windows Server 2019 melhora essas otimizações distribuindo e ajustando

dinamicamente o processamento de cargas de trabalho de rede, conforme necessário. o
Windows Server 2019 garante a eficiência de pico e remove a carga de configuração
para os administradores de ti. Para saber mais, confira requisitos de rede do host para
Azure Stack HCI.
Para obter mais informações, consulte:
Blog do comunicado
Guia de validação para o Pro de ti
Receber segmento Coalescing (RSC) em vSwitch

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows 10, versão 1809
A União de segmento de recebimento (RSC) no vSwitch é um aprimoramento que une

vários segmentos TCP em um segmento maior antes de os dados atravessarem o
vSwitch. O segmento grande melhora o desempenho de rede para cargas de trabalho
virtuais.
Anteriormente, esse foi um descarregamento implementado pela NIC. Infelizmente, isso

foi desabilitado no momento em que você anexou o adaptador a um comutador virtual.
o RSC no vSwitch no Windows Server 2019 e Atualização de outubro de 2018 para o
Windows 10 remove essa limitação.
Por padrão, o RSC no vSwitch é habilitado em comutadores virtuais externos.
Blog do comunicado
Guia de validação para o Pro de ti
Diretrizes de rede principal para o
Windows Server
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server, Windows
Server 2016
Este tópico fornece uma visão geral das diretrizes de rede principal para Windows
Server® 2016 e contém as seções a seguir.
Introdução à rede principal do Windows Server
Guia de rede principal para Windows Server
Introdução à rede principal do Windows Server

Uma rede principal é um conjunto de hardware de rede, dispositivos e software que
fornece os serviços fundamentais para as necessidades da TI (tecnologia da informação)
de sua organização.
Uma rede principal do Windows Server fornece muitos benefícios, incluindo alguns a
seguir.
Os protocolos principais de conectividade da rede entre computadores e outros

dispositivos compatíveis com os protocolos TCP/IP. TCP/IP é um conjunto de
protocolos padrão para conexão de computadores e criação de redes. TCP/IP é
software de protocolo de rede fornecido com os sistemas operacionais Microsoft®
Windows® que implementa e oferece suporte ao pacote de protocolos TCP/IP.
Endereçamento IP automático do servidor DHCP A configuração manual dos

endereços IP em todos os computadores na sua rede é demorado e menos flexível
que fornecer dinamicamente computadores e outros dispositivos com concessões
de endereço IP de um servidor DHCP.
Serviços de resolução de nomes do DNS (Sistema de Nomes de Domínios) O DNS

permite que os usuários, computadores, aplicativos e serviços encontrem os
endereços IP dos computadores e dispositivos na rede usando o Nome de
Domínio Totalmente Qualificado do computador ou dispositivo.
Uma floresta, que é um ou mais domínios do Active Directory que compartilham

as mesmas definições de classe e de atributo (esquema), informações de local e
replicação (configuração) e capacidades de pesquisa da floresta (catálogo global).
Um domínio raiz de floresta, que é o primeiro domínio criado em uma nova

floresta. Os grupos Administradores de Empresa e Administradores de Esquema
(que são grupos administrativos em toda a floresta) estão localizados no domínio
raiz da floresta. Além disso, um domínio raiz da floresta, tal como acontece com
outros domínios, é uma coleção de objetos de computador, de usuário e de grupo
que são definidos pelo administrador no AD DS (Serviços de Domínio Active
Directory). Esses objetos compartilham um banco de dados de diretório comum e
políticas de segurança. Eles também poderão compartilhar relações de segurança
com outros domínios se você adicionar domínios à medida que sua organização
crescer. O serviço de diretório também armazena os dados de diretório e permite
que computadores autorizados, aplicativos e usuários acessem os dados.
Um banco de dados de contas de usuário e de computador. O serviço de diretório

fornece um banco de dados de contas de usuário centralizado que permite que
você crie contas de usuário e de computador para pessoas e computadores que
estão autorizados a se conectar à sua rede e acessar os recursos da rede, como
aplicativos, bancos de dados, arquivos e pastas compartilhados, e impressoras.
Uma rede principal também permite escalar sua rede à medida que sua organização
cresce e os requisitos de TI mudam. Por exemplo, com uma rede principal, você pode
adicionar domínios, sub-redes IP, serviços de acesso remoto, serviços sem fio e outros
recursos e funções de servidor fornecidos pelo Windows Server 2016.
Guia de rede principal para Windows Server

O Windows Server 2016 De rede principal fornece instruções sobre como planejar e
implantar os componentes principais necessários para uma rede totalmente funcional e
um novo domínio do Active Directory® em uma nova floresta. Usando este guia, você
pode implantar os computadores configurados com os seguintes componentes de
servidor do Windows:
A função de servidor do AD DS (Serviços de Domínio Active Directory)
A função de servidor DNS (Sistema de Nomes de Domínio)
A função de servidor de protocolo DHCP
O serviço de função do NPS (Servidor de Políticas de Rede) da função de servidor

dos Serviços de Acesso e Política de Rede.
A função de servidor Servidor Web (IIS)

Conexões de protocolo TCP/IPv4 em servidores individuais
Este guia está disponível no local a seguir.
O guia de rede principal na biblioteca Windows Server 2016 técnica.

Principais componentes de rede
Este guia fornece instruções sobre como planejar e implantar os componentes principais
necessários para uma rede totalmente funcional e um novo domínio do Active Directory
em uma nova floresta.
Este guia apresenta as seguintes seções:
Sobre este guia
Visão geral da rede principal
Planejamento da rede principal
Implantação da rede principal
Recursos técnicos adicionais
Apêndices A a E
Sobre este guia

Este guia se destina aos administradores de rede e de sistema que estão instalando uma
nova rede ou que desejam criar uma rede baseada em domínio para substituir uma rede
constituída de grupos de trabalho. O cenário de implantação fornecido neste guia é
especialmente útil quando você prevê a necessidade de adicionar mais recursos e
serviços a sua rede no futuro.
Recomendamos que você leia os guias de design e de implantação para cada uma das
tecnologias usadas neste cenário de implantação para ajudar a determinar se este guia
fornece os serviços e configurações que você precisa.
Uma rede principal é um conjunto de hardware de rede, dispositivos e software que

fornece os serviços fundamentais para as necessidades da TI (tecnologia da informação)
de sua organização.
Uma rede principal do Windows Server fornece muitos benefícios, incluindo alguns a
seguir.
Os protocolos principais de conectividade da rede entre computadores e outros
dispositivos compatíveis com os protocolos TCP/IP. TCP/IP é um conjunto de
protocolos padrão para conexão de computadores e criação de redes. TCP/IP é um
software de protocolo de rede fornecido com sistemas operacionais Microsoft
Windows que implementa e dá suporte ao conjunto de protocolos TCP/IP.
A atribuição automática de endereços IP do protocolo DHCP para computadores e

outros dispositivos que são configurados como clientes DHCP. A configuração
manual dos endereços IP em todos os computadores na sua rede é demorado e
menos flexível que fornecer dinamicamente computadores e outros dispositivos
com as configurações de endereço IP usando um servidor DHCP.
Serviços de resolução de nomes do DNS (Sistema de Nomes de Domínios) O DNS

permite que os usuários, computadores, aplicativos e serviços encontrem os
endereços IP dos computadores e dispositivos na rede usando o Nome de
Domínio Totalmente Qualificado do computador ou dispositivo.
Uma floresta, que é um ou mais domínios do Active Directory que compartilham

as mesmas definições de classe e de atributo (esquema), informações de local e
replicação (configuração) e capacidades de pesquisa da floresta (catálogo global).
Um domínio raiz de floresta, que é o primeiro domínio criado em uma nova

floresta. Os grupos Administradores de Empresa e Administradores de Esquema
(que são grupos administrativos em toda a floresta) estão localizados no domínio
raiz da floresta. Além disso, um domínio raiz da floresta, tal como acontece com
outros domínios, é uma coleção de objetos de computador, de usuário e de grupo
que são definidos pelo administrador no AD DS (Serviços de Domínio Active
Directory). Esses objetos compartilham um banco de dados de diretório comum e
políticas de segurança. Eles também poderão compartilhar relações de segurança
com outros domínios se você adicionar domínios à medida que sua organização
crescer. O serviço de diretório também armazena os dados de diretório e permite
que computadores autorizados, aplicativos e usuários acessem os dados.
Um banco de dados de contas de usuário e de computador. O serviço de diretório

fornece um banco de dados de contas de usuário centralizado que permite que
você crie contas de usuário e de computador para pessoas e computadores que
estão autorizados a se conectar à sua rede e acessar os recursos da rede, como
aplicativos, bancos de dados, arquivos e pastas compartilhados, e impressoras.
Uma rede principal também permite escalar sua rede à medida que sua organização
cresce e os requisitos de TI mudam. Por exemplo, com uma rede principal, você pode
adicionar domínios, sub-redes IP, serviços de acesso remoto, serviços sem fio e outros
recursos e funções de servidor fornecidos por Windows Server 2016.
Requisitos de hardware de rede
Para implantar com êxito uma rede principal, implante o hardware de rede, incluindo o
seguinte:
Cabeamento Ethernet, Fast Ethernet ou Gigabyte Ethernet
Um hub, comutador de Camada 2 ou 3, roteador ou outro dispositivo que executa

a função de retransmissão do tráfego de rede entre computadores e dispositivos.
Os computadores que atendem aos requisitos mínimos de hardware para os

sistemas operacionais de cliente e servidor respectivos.
O que este guia não contém

Este guia não fornece instruções para implantar o seguinte:
Hardware de rede, como cabeamentos, roteadores, comutadores e hubs
Recursos de rede adicionais, como impressoras e servidores de arquivos
Conectividade com a Internet
Acesso remoto
Acesso sem fio
Implantação do computador cliente
７ Observação
Os computadores que executam sistemas operacionais cliente Windows são

configurados por padrão para receber concessões de endereço IP do servidor
DHCP. Portanto, nenhuma configuração adicional do protocolo DHCP ou IPv4 nos
computadores clientes é necessária.
Visões gerais de tecnologia

As seções a seguir fornecem visões gerais breves das tecnologias exigidas que são
implantadas para criar uma rede principal.
Active Directory Domain Services

Um diretório é uma estrutura hierárquica que armazena informações sobre objetos na
rede, como usuários e computadores. Um serviço de diretório, como o AD DS, fornece
os métodos para armazenar dados de diretório e disponibilizá-los para administradores
e usuários da rede. Por exemplo, o AD DS armazena informações sobre contas de
usuário, incluindo nomes, endereços de email, senhas e números de telefone e permite
que outros usuários autorizados da mesma rede acessem essas informações.
DNS
O DNS é um protocolo de resolução de nomes para redes TCP/IP, como a Internet ou
uma rede da organização. Um servidor DNS hospeda as informações que permite que
os computadores cliente e serviços resolvam nomes DNS alfanuméricos fáceis de
reconhecer para os endereços IP que os computadores usam para comunicação entre si.
DHCP
O DHCP é um padrão de IP para simplificar o gerenciamento da configuração de IP do
host. O padrão DHCP proporciona o uso de servidores DHCP como uma forma de
gerenciar a alocação dinâmica de endereços IP e outros detalhes de configuração
relacionados para clientes habilitados para DHCP em sua rede.
O DHCP permite que você use um servidor DHCP para atribuir dinamicamente um
endereço IP a um computador ou outro dispositivo, como uma impressora em sua rede
local. Todos os computadores em uma rede TCP/IP devem ter um endereço IP exclusivo,
porque o endereço IP e a máscara de sub-rede relacionada identificam o computador
host e a sub-rede à qual o computador está conectado. Usando o DHCP, você pode
garantir que todos os computadores configurados como clientes DHCP recebam um
endereço IP que seja apropriado para seu local de rede e sua sub-rede e, usando as
opções de DHCP (como o gateway padrão e os servidores DNS), você pode fornecer
automaticamente aos clientes DHCP as informações que eles precisam para funcionar
corretamente na rede.
Para redes baseadas em TCP/IP, o DHCP reduz a complexidade e a quantidade de

trabalho administrativo envolvido na reconfiguração dos computadores.
TCP/IP
TCP/IP no Windows Server 2016 é o seguinte:
Software de rede baseado em protocolos de rede padrão do setor.

Um protocolo de rede de empresa roteável que suporta a conexão de seu
computador baseado em Windows com os ambientes LAN (rede de área local) e
WAN (rede de longa distância).
As principais tecnologias e utilitários para conectar seu computador baseado em

Windows com os sistemas diferentes com a finalidade de compartilhar
informações.
Uma base para obter acesso aos serviços globais da Internet, como os servidores
WWW e FTP.
Uma estrutura robusta, escalável, multiplataforma, de cliente/servidor.
O TCP/IP oferece utilitários TCP/IP básicos que permitem que computadores baseados
no Windows se conectem e compartilhem informações com outros sistemas Microsoft e
não Microsoft, incluindo:
Windows Server 2016
Windows 10
Windows Server 2012 R2
Windows 8.1
Windows Server 2012
Windows 8
Windows 7
Windows Server 2008
Windows Vista
Hosts da Internet
Sistemas Apple Macintosh
Mainframes IBM
Sistemas UNIX e Linux
Sistemas VMS abertos
Impressoras prontas para rede

Tablets e telefones celulares com ethernet com fio ou tecnologia sem fio 802.11
habilitada
Visão geral da rede principal

A ilustração a seguir mostra a topologia de Rede Principal do Windows Server.
７ Observação
Este guia também inclui instruções para adicionar servidores NPS (Servidor de
Políticas de Rede) e de Servidor Web (IIS) para sua topologia de rede para fornecer
a base para proteger as soluções de acesso à rede, como implantações 802.1X com
fio e sem fio que você pode implementar usando guias complementares de Rede
Principal. Para obter mais informações, consulte Implantando recursos opcionais
para a autenticação do acesso à rede e dos serviços Web.
Componentes da rede principal

Estes são os componentes de uma rede principal.
Roteador
Este guia de implantação fornece instruções para a implantação de uma rede principal
com duas sub-redes separadas por um roteador que tem o encaminhamento DHCP
habilitado. No entanto, você pode implantar um comutador de Camada 2, comutador
de Camada 3 ou um hub, dependendo das suas necessidades e recursos. Se você
implantar uma opção, a opção deverá ser capaz de encaminhar DHCP ou você deverá
colocar um servidor DHCP em cada sub-rede. Se você implantar um hub, estará
implantando uma única sub-rede e não precisará do encaminhamento DHCP ou de um
segundo escopo no servidor DHCP.
Configurações TCP/IP estáticas
Os servidores nesta implantação são configurados com endereços IPv4 estáticos. Os

computadores cliente são configurados por padrão para receber concessões de
endereço IP do servidor DHCP.
Catálogo global dos Serviços de Domínio Active Directory e

servidor DNS DC1
O AD DS (Serviços de Domínio Active Directory) e o DNS (Sistema de Nomes de

Domínio) são instalados neste servidor, denominado DC1, que fornece os serviços de
diretório e de resolução de nomes para todos os computadores e dispositivos na rede.
Servidor DHCP DHCP1
O servidor DHCP, denominado DHCP1, está configurado com um escopo que fornece
concessões de endereços IP para computadores na sub-rede local. O servidor DHCP
pode também ser configurado com escopos adicionais para fornecer concessões de
endereços IP para computadores em outras sub-redes quando o encaminhamento
DHCP é configurado nos roteadores.
Computadores cliente
Os computadores que executam sistemas operacionais cliente Windows são

configurados por padrão como clientes DHCP, que obtêm endereços IP e opções DHCP
automaticamente do servidor DHCP.
Planejamento da rede principal

Antes de implantar uma rede principal, você deve planejar os itens a seguir.
Planejando sub-redes
Planejando a configuração básica de todos os servidores

Planejando a implantação do DC1
Planejando o acesso de domínio
Planejando a implantação do DHCP1
As seções a seguir fornecem mais detalhes sobre cada um desses itens.
７ Observação
Para obter assistência com o planejamento de sua implantação, consulte Também

Apêndice E – Planilha de Preparação de Planejamento de Rede Principal.
Planejando sub-redes
No sistema de redes dos protocolos TCP/IP, os roteadores são usados para
interconectar o hardware e o software usados em segmentos de rede física diferentes
chamados sub-redes. Os roteadores também são usados para encaminhar pacotes IP
entre cada uma das sub-redes. Determine o layout físico da rede, incluindo o número de
roteadores e sub-redes que você precisa, antes de continuar com as instruções deste
guia.
Além disso, para configurar os servidores na rede com endereços IP estáticos, determine
o intervalo de endereços IP que deseja usar para a sub-rede onde se encontram os
servidores da rede principal. Neste guia, os intervalos de endereços IP privados 10.0.0.1
– 10.0.0.254 e 10.0.1.1 – 10.0.1.254 são usados como exemplos, mas você pode usar
qualquer intervalo de endereços IP privado que preferir.
） Importante
Depois de selecionar os intervalos de endereços IP que deseja usar para cada sub-
rede, verifique se você pode configurar seus roteadores com o mesmo intervalo de
endereços IP usado na sub-rede onde o roteador está instalado. Por exemplo, se
seu roteador estiver configurado por padrão com um endereço IP 192.168.1.1, mas
você estiver instalando o roteador em uma sub-rede com um intervalo de
endereços IP de 10.0.0.0/24, deverá reconfigurar o roteador para usar um endereço
IP do intervalo de endereços IP 10.0.0.0/24.
Os seguintes intervalos de endereços IP privados reconhecidos são especificados pela

RFC (Request for Comments) da Internet 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
Quando você usa os intervalos de endereços IP privados como especificado na RFC

1918, não pode se conectar diretamente à Internet usando um endereço IP privado
porque as solicitações desses endereços e para eles são descartadas automaticamente
pelos roteadores do ISP (provedor de serviço da Internet). Para adicionar conectividade
de Internet à rede principal mais tarde, contrate um ISP para obter um endereço IP
público.
） Importante
Ao usar endereços IP particulares, você deve usar algum tipo de servidor proxy ou
NAT (conversão de endereços de rede) para converter os intervalos de endereços IP
privados na rede local para um endereço IP público que pode ser roteado na
Internet. A maioria dos roteadores fornecem os serviços NAT; portanto, selecionar
um roteador compatível com NAT deve ser bastante simples.
Para obter mais informações, consulte Planejando a implantação do DHCP1.
Planejando a configuração básica de todos os servidores

Para cada servidor da rede principal, renomeie o computador e atribua e configure um
endereço IPv4 estático e outras propriedades de TCP/IP para o computador.
Planejando convenções de nomenclatura para computadores e

dispositivos
Para manter a consistência em toda a rede, é uma boa ideia usar nomes consistentes
para servidores, impressoras e outros dispositivos. Os nomes de computador podem ser
usados para ajudar os usuários e administradores a identificar facilmente a finalidade e a
localização do servidor, impressora ou outro dispositivo. Por exemplo, se você tiver três
servidores DNS, um em São Francisco, um em Los Angeles e outro em Chicago, poderá
usar onúmero delocal- da função- do servidor de convenção de nomenclatura:
DNS-DEN-01. Este nome representa o servidor DNS em Denver, Colorado. Se os

servidores DNS adicionais forem adicionados em Denver, o valor numérico no
nome poderá ser incrementado, como no DNS-DEN-02 e no DNS-DEN-03.
DNS-SPAS-01. Este nome representa o servidor DNS em South Pasadena,
Califórnia.
DNS-ORL-01. Este nome representa o servidor DNS em Orlando, Flórida.
Para este guia, a convenção de nomenclatura do servidor é muito simples e consiste na

função de servidor primário e em um número. Por exemplo, o controlador de domínio é
denominado DC1 e o servidor DHCP é denominado DHCP1.
Recomendamos que você escolha uma convenção de nomenclatura antes de instalar a

rede de núcleo usando este guia.
Planejando endereços IP estáticos

Antes de configurar cada computador com um endereço IP estático, planeje seus
intervalos de endereços IP e sub-redes. Além disso, determine os endereços IP dos
servidores DNS. Se você planeja instalar um roteador que fornece acesso a outras redes,
como sub-redes adicionais ou a Internet, deve saber o endereço IP do roteador,
também chamado de gateway padrão, para a configuração do endereço IP estático.
A tabela a seguir fornece valores de exemplo para a configuração de endereço IP

estático.
Itens de configuração Valores de exemplo
Endereço IP 10.0.0.2
Máscara de sub-rede 255.255.255.0
Gateway padrão (endereço IP do roteador) 10.0.0.1
Servidor DNS preferencial 10.0.0.2
７ Observação
Se você planeja implantar mais de um servidor DNS, também pode planejar o

endereço IP do Servidor DNS Alternativo.
Planejando a implantação do DC1

Estas são as principais etapas de planejamento antes de instalar o AD DS (Serviços de
Domínio Active Directory e o DNS no DC1.
Planejando o nome do domínio raiz da floresta
Uma primeira etapa no processo de design do AD DS é determinar quantas florestas sua
organização requer. Uma floresta é o contêiner de nível superior AD DS e consiste em
um ou mais domínios que compartilham um esquema comum e um catálogo global.
Uma organização pode ter várias florestas, mas para a maioria das organizações, um
design de floresta única é o modelo preferido e o mais simples de administrar.
Quando você cria o primeiro controlador de domínio em sua organização, está criando
o primeiro domínio (também chamado de domínio raiz da floresta) e a primeira floresta.
No entanto, antes de executar esta ação usando este guia, determine o melhor nome de
domínio para sua organização. Na maioria dos casos, o nome da organização é usado
como o nome de domínio, e, em muitos casos, este nome de domínio está registrado.
Se você planeja implantar os servidores Web baseados na Internet externos para
fornecer informações e serviços para seus clientes ou parceiros, escolha um nome de
domínio que não esteja em uso e registre o nome de domínio, para que sua
organização o possua.
Planejando o nível funcional da floresta

Durante a instalação do AD DS, escolha o nível funcional da floresta que deseja usar. A
funcionalidade de domínio e de floresta, inserida no Active Directory do Windows
Server 2003, fornece uma maneira de habilitar os recursos de domínio ou de floresta do
Active Directory no ambiente de rede. Os diferentes níveis de funcionalidade de
domínio e de floresta disponíveis, dependendo do ambiente.
A funcionalidade de floresta habilita os recursos em todos os domínios da floresta. Os

seguintes níveis funcionais de floresta estão disponíveis:
Windows Server 2008 . Esse nível funcional de floresta dá suporte apenas a

controladores de domínio que executam o Windows Server 2008 e versões
posteriores do sistema operacional Windows Server.
Windows Server 2008 R2 . Esse nível funcional de floresta dá suporte a

controladores de domínio e controladores de domínio do Windows Server 2008 R2
que executam versões posteriores do sistema operacional Windows Server.
Windows Server 2012 . Esse nível funcional de floresta dá suporte a controladores

de domínio Windows Server 2012 e controladores de domínio que estão
executando versões posteriores do sistema operacional Windows Server.
Windows Server 2012 R2 . Esse nível funcional de floresta dá suporte a

controladores de domínio do Windows Server 2012 R2 e controladores de domínio
que executam versões posteriores do sistema operacional Windows Server.
Windows Server 2016. Esse nível funcional de floresta dá suporte apenas a

controladores de domínio Windows Server 2016 e controladores de domínio que
executam versões posteriores do sistema operacional Windows Server.
Se você estiver implantando um novo domínio em uma nova floresta e todos os

controladores de domínio estiverem executando Windows Server 2016, é recomendável
configurar o AD DS com o nível funcional da floresta Windows Server 2016 durante a
instalação do AD DS.
） Importante
Depois que o nível funcional de floresta é aumentado, os controladores de domínio

que estão executando os sistemas operacionais anteriores não podem ser
introduzidos na floresta. Por exemplo, se você elevar o nível funcional da floresta
para Windows Server 2016, os controladores de domínio que executam Windows
Server 2012 R2 ou Windows Server 2008 não poderão ser adicionados à floresta.
Os itens de configuração de exemplo para o AD DS são fornecidos na tabela a seguir.
Itens de configuração: Valores de exemplo:
Nome DNS completo Exemplos:

- corp.contoso.com
- example.com
Nível funcional da floresta – Windows Server 2008
– Windows Server 2008

R2

R2
- Windows Server 2016
Local da pasta do Banco de Dados dos Serviços de Domínio Active E:\Configuração\

Directory Ou aceite o local
padrão.
Local da pasta dos arquivos de Log dos Serviços de Domínio Active E:\Configuração\
padrão.
Local da pasta do SYSVOL dos Serviços de Domínio Active Directory E:\Configuração\

Ou aceite o local
padrão.
Itens de configuração: Valores de exemplo:
Senha do Administrador do Modo de Restauração de Diretório J*p2leO4$F
Nome de arquivo de resposta (opcional) AD DS_AnswerFile
Planejando zonas DNS

Em servidores DNS primários, integrados ao Active Directory, uma zona de pesquisa
direta é criada por padrão durante a instalação da função de Servidor DNS. Uma zona
de pesquisa direta permite que computadores e dispositivos consultem o endereço IP
de outro computador ou dispositivo com base no seu nome DNS. Além de uma zona de
pesquisa direta, recomendamos que você crie uma zona de pesquisa inversa de DNS.
Com uma zona de pesquisa inversa de DNS, um computador ou dispositivo pode
descobrir o nome de outro computador ou dispositivo usando seu endereço IP. A
implantação de uma zona de pesquisa inversa normalmente melhora o desempenho do
DNS e aumenta o êxito nas consultas DNS.
Quando você cria uma zona de pesquisa inversa, o domínio in-addr.arpa, que é definido
nos padrões DNS e reservado no namespace DNS da Internet para oferecer uma forma
prática e confiável de realizar consultas inversas, é configurado no DNS. Para criar o
namespace inverso, subdomínios dentro do domínio in-addr.arpa são formados, usando
a ordem inversa dos números na notação decimal com ponto de endereços IP.
O domínio in-addr.arpa se aplica a todas as redes TCP/IP baseadas no endereçamento

de protocolo Internet versão 4 (IPv4). O Assistente de Nova Zona automaticamente
assumirá que você está usando este domínio ao criar uma nova zona de pesquisa
inversa.
Enquanto você estiver executando o Assistente de Nova Zona, recomendamos as

seguintes seleções:
Tipo de zona Zona primária e Armazenar a zona no Active

Directory estão selecionados
Escopo de Replicação de Zona do Active Para todos os servidores DNS neste domínio
Directory
Página do assistente de Nome da Primeira Zona de pesquisa inversa do IPv4

Zona de Pesquisa Inversa
Página do assistente de Nome da Segunda ID da Rede = 10.0.0.

Zona de Pesquisa Inversa
Atualizações Dinâmicas Permitir apenas atualizações dinâmicas seguras
Planejando o acesso de domínio

Para fazer logon no domínio, o computador deve ser um computador membro do
domínio e a conta de usuário deve ser criada no AD DS antes da tentativa de logon.
７ Observação
Computadores individuais que estão executando o Windows tem um banco de

dados local de contas de usuários de grupos e usuários denominado o banco de
dados de contas de usuário do SAM (Gerente de Contas de Segurança). Quando
você criar uma conta de usuário no computador local no banco de dados do SAM,
pode fazer logon no computador local, mas não pode fazer logon em um domínio.
As contas de usuário de domínio são criadas com o MMC (Console de
Gerenciamento Microsoft) dos Usuários e Computadores do Active Directory em
um controlador de domínio, não com os usuários e grupos locais no computador
local.
Depois do primeiro logon bem-sucedido com as credenciais de logon do domínio, as

configurações de logon persistem, a menos que o computador seja removido do
domínio ou as configurações de logon sejam alteradas manualmente.
Antes de você fazer logon no domínio:
Crie contas de usuários em Usuários e Computadores do Active Directory. Cada

usuário deve ter uma conta de usuário dos Serviços de Domínio Active Directory
em Usuários e Computadores do Active Directory. Para obter mais informações,
consulte Criar uma conta de usuário em Usuários e Computadores do Active
Directory.
Verifique a configuração do endereço IP está correta. Para ingressar um

computador no domínio, o computador deve ter um endereço IP. Neste guia, os
servidores são configurados com endereços IP estáticos e os computadores cliente
recebem concessões de endereços IP do servidor DHCP. Por esse motivo, o
servidor DHCP deve ser implantado antes que você adicione clientes ao domínio.
Para obter mais informações, consulte Implantando o DHCP1.
Ingresse o computador no domínio. Qualquer computador que fornece ou acessa

recursos de rede deve ser ingressado no domínio. Para obter mais informações,
consulte Ingressando computadores servidores no domínio e fazendo logon e
Ingressando computadores cliente no domínio e fazendo logon.
Planejando a implantação do DHCP1

Estas são as principais etapas de planejamento antes de instalar a função de servidor
DHCP no DHCP1.
Planejando os servidores DHCP e o encaminhamento DHCP
Como as mensagens DHCP são mensagens de difusão, elas não são encaminhadas
entre as sub-redes por roteadores. Se você tiver várias sub-redes e desejar fornecer o
serviço DHCP em cada sub-rede, deverá fazer o seguinte:
Instalar um servidor DHCP em cada sub-rede
Configurar roteadores para encaminhar as mensagens de difusão DHCP entre sub-

redes e configurar vários escopos no servidor DHCP, um escopo por sub-rede.
Na maioria dos casos, a configuração de roteadores para encaminhar mensagens de

difusão DHCP é mais econômica que a implantação de um servidor DHCP em cada
segmento físico da rede.
Planejando intervalos de endereços IP
Cada sub-rede deve ter seu próprio intervalo de endereços IP exclusivo. Esses intervalos
são representados em um servidor DHCP com escopos.
Um escopo é um agrupamento administrativo de endereços IP para computadores em

uma sub-rede que usa o serviço DHCP. O administrador primeiro cria um escopo para
cada sub-rede física e, em seguida, usa o escopo para definir os parâmetros usados
pelos clientes.
Um escopo tem as seguintes propriedades:
Um intervalo de endereços IP do qual incluir ou excluir endereços usados para

ofertas de concessão de serviço DHCP.
Uma máscara de sub-rede, que determina o prefixo de sub-rede para um

determinado endereço IP.
Um nome de escopo atribuído quando é criado.

Valores de duração da concessão, que são atribuídos aos clientes DHCP que
recebem endereços IP alocados dinamicamente.
Qualquer opção de escopo DHCP configurada para atribuição a clientes DHCP,

como endereço ID do servidor DNS ou endereço IP do gateway do
roteador/padrão.
As reservas são opcionalmente usadas para garantir que um cliente DHCP sempre
receba o mesmo endereço IP.
Antes de implantar os servidores, liste suas sub-redes e o intervalo de endereços IP que

você deseja usar para cada sub-rede.
Planejando máscaras de sub-rede
As IDs de rede e IDs de host são diferenciadas usando uma máscara de sub-rede. Cada
máscara de sub-rede é um número de 32 bits que usa grupos de bits consecutivos de
todos (1) para identificar a ID da rede e todos os zeros (0) para identificar as partes de
ID do host de um endereço IP.
Por exemplo, a máscara de sub-rede normalmente usada com o endereço IP

131.107.16.200 é o seguinte número binário de 32 bits:
11111111 11111111 00000000 00000000
Esse número de máscara de sub-rede são 16 bits de um seguidos de 16 bits de zero,

indicando que as seções de ID da rede e as seções de ID do host desse endereço IP têm
16 bits de comprimento. Normalmente, essa máscara de sub-rede é exibida em notação
decimal com ponto como 255.255.0.0.
A tabela a seguir exibe as máscaras de sub-rede para as classes de endereço de Internet.
Classe de endereço Bits para máscara de sub-rede Máscara de sub-rede
Classe A 11111111 00000000 00000000 00000000 255.0.0.0
Classe B 11111111 11111111 00000000 00000000 255.255.0.0
Classe C 11111111 11111111 11111111 00000000 255.255.255.0
Quando você cria um escopo no DHCP e insere o intervalo de endereços IP do escopo,

o DHCP fornece esses valores de máscara de sub-rede padrão. Normalmente, os valores
de máscara de sub-rede padrão são aceitáveis para a maioria das redes sem requisitos
especiais e onde cada segmento de rede IP corresponde a uma única rede física.
Em alguns casos, você pode usar máscaras de sub-rede personalizadas para

implementar a criação de sub-redes IP. Com a criação de sub-redes IP, você pode
subdividir a parte padrão de ID de host de um endereço IP para especificar sub-redes,
que são subdivisões de ID de rede baseada na classe original.
Personalizando o comprimento da máscara de sub-rede, você pode reduzir o número

de bits que são usados para o ID de host real.
Para evitar a solução e o roteamento de problemas, verifique se todos os computadores

TCP/IP em um segmento de rede usam a mesma máscara de sub-rede e se cada
computador ou dispositivo tem um endereço IP exclusivo.
Planejando intervalos de exclusão

Quando você cria um escopo em um servidor DHCP, pode especificar um intervalo de
endereços IP que inclui todos os endereços IP que o servidor DHCP pode conceder aos
clientes DHCP, como computadores e outros dispositivos. Se você acessar e configurar
manualmente alguns servidores e outros dispositivos com endereços IP estáticos do
mesmo intervalo de endereços IP usado pelo servidor DHCP, poderá criar
acidentalmente um conflito de endereços IP, onde você e o servidor DHCP atribuem o
mesmo endereço IP a dispositivos diferentes.
Para resolver esse problema, você pode criar um intervalo de exclusão para o escopo
DHCP. Um intervalo de exclusão é um intervalo contíguo de endereços IP dentro do
intervalo de endereços IP do escopo que o servidor DHCP não tem permissão para usar.
Se você criar um intervalo de exclusão, o servidor DHCP não atribuirá os endereços
nesse intervalo, permitindo que você atribua manualmente esses endereços sem criar
um conflito de endereços IP.
Você pode excluir endereços IP da distribuição pelo servidor DHCP, criando um intervalo
de exclusão para cada escopo. Use as exclusões para todos os dispositivos configurados
com um endereço IP estático. Os endereços excluídos devem incluir todos os endereços
IP que você atribuiu manualmente a outros servidores, clientes não-DHCP, estações de
trabalho sem disco ou clientes de Roteamento, Acesso Remoto e PPP.
Recomendamos que você configure o intervalo de exclusão com endereços extras para
acomodar o crescimento futuro da rede. A tabela a seguir fornece um intervalo de
exclusão de exemplo para um escopo com um intervalo de endereços IP 10.0.0.1 a
10.0.0.254 e uma máscara de sub-rede de 255.255.255.0.
Endereço IP Inicial do intervalo de exclusão 10.0.0.1
Endereço IP Final do intervalo de exclusão 10.0.0.25
Planejando a configuração estática do TCP/IP
Certos dispositivos, como roteadores, servidores DHCP e servidores DNS, devem ser
configurados com um endereço IP estático. Além disso, você pode ter dispositivos
adicionais, como impressoras, onde deve garantir sempre o mesmo endereço IP. Liste os
dispositivos que você deseja configurar estaticamente para cada sub-rede e planeje o
intervalo de exclusão que deseja usar no servidor DHCP para garantir que o servidor
DHCP não conceda o endereço IP de um dispositivo configurado estaticamente. Um
intervalo de exclusão é uma sequência limitada de endereços IP dentro de um escopo,
excluído das ofertas de serviço DHCP. Os intervalos de exclusão garantem que os
endereços nesses intervalos não sejam oferecidos pelo servidor a clientes DHCP na sua
rede.
Por exemplo, se o intervalo de endereços IP de uma sub-rede for 192.168.0.1 a

192.168.0.254 e você tiver dez dispositivos que deseja configurar com um endereço IP
estático, poderá criar um intervalo de exclusão para o escopo 192.168.0.x que inclui dez
ou mais endereços IP: 192.168.0.1 a 192.168.0.15.
Neste exemplo, você usa dez dos endereços IP excluídos para configurar servidores e
outros dispositivos com endereços IP estáticos e cinco endereços IP adicionais ficam
disponíveis para uma configuração estática de novos dispositivos que você possa
desejar adicionar no futuro. Com este intervalo de exclusão, o servidor DHCP fica com
um pool de endereços de 192.168.0.16 até 192.168.0.254.
Itens de configuração de exemplo adicionais para o AD DS e o DNS são fornecidos na

tabela a seguir.
Ligações de Conexão de Rede Ethernet
Configurações do servidor DNS DC1.corp.contoso.com
Endereço IP do servidor DNS preferencial 10.0.0.2

Adicionar valores da caixa de diálogo Escopo 1. Sub-rede primária
1. Nome do escopo
2. 10.0.0.1
2. Iniciando o endereço IP
3. 10.0.0.254
3. Endereço IP final
4. 255.255.255.0
4. Máscara de Sub-rede
5. 10.0.0.1
5. Gateway padrão (opcional)

6. 8 dias
6. Duração da concessão
Modo de Operação do Servidor DHCP IPv6 não ativado
Implantação da rede principal

Para implantar uma rede principal, estas são as etapas básicas:
1. Configurando todos os servidores
2. Implantando o DC1
3. Ingressando computadores servidores no domínio e fazendo logon
4. Implantando o DHCP1
5. Ingressando computadores clientes no domínio e fazendo logon
6. Implantando recursos opcionais para a autenticação do acesso à rede e dos

serviços Web
７ Observação
Comandos equivalentes do Windows PowerShell são fornecidos para a

maioria dos procedimentos neste guia. Antes de executar esses cmdlets no
Windows PowerShell, substitua os valores de exemplo pelos valores que são
apropriados para sua implantação de rede. Além disso, insira cada cmdlet em
uma única linha no Windows PowerShell. Neste guia, cmdlets individuais
podem aparecer em várias linhas devido à formatação de restrições e à
exibição do documento por outro aplicativo ou navegador.
Os procedimentos deste guia não incluem instruções para os casos em que a
caixa de diálogo Controle de Conta de Usuário é aberta para solicitar sua
permissão para continuar. Caso essa caixa de diálogo seja aberta durante a
execução dos procedimentos deste guia e em resposta às suas ações, clique
em Continuar.
Configurando todos os servidores
Antes de instalar outras tecnologias, como os Serviços de Domínio Active Directory ou o
DHCP, é importante configurar os itens a seguir.
Renomear o computador
Configurar um endereço IP estático
Você pode usar as seções a seguir para executar essas ações em cada servidor.
A associação a Administradores ou equivalente é o requisito mínimo para a execução

destes procedimentos.
Você pode usar o procedimento nesta seção para alterar o nome de um computador.
Renomear o computador é útil quando o sistema operacional cria automaticamente um
nome de computador que você deseja usar.
７ Observação
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell,

digite os cmdlets a seguir em linhas separadas e pressione ENTER. Você também
deve substituir Nome_do_Computador pelo nome que deseja usar.
Rename-Computer Computername
Restart-Computer
Para renomear computadores que executam Windows Server 2016,

Windows Server 2012 R2 e Windows Server 2012
1. No Gerenciador do Servidor, clique em Servidor Local. As Propriedades do

computador são exibidas no painel de detalhes.
2. Em Propriedades, em Nome do computador, clique no nome existente. A caixa de

diálogo Propriedades do Sistema será aberta. Clique em Alterar. A caixa de
diálogo Alterações de Nome/Domínio do Computador será aberta.
3. Na caixa de diálogo Alterações de Nome/Domínio do Computador, no Nome do
computador, digite um novo nome para o computador. Por exemplo, se você
deseja denominar o computador como DC1, digite DC1.
4. Clique em OK duas vezes e depois em Fechar. Se você deseja reiniciar o

computador imediatamente para concluir a alteração de nome, clique em Reiniciar
Agora. Caso contrário, clique em Reiniciar Mais Tarde.
７ Observação
Para obter informações sobre como renomear computadores que estão

executando outros sistemas operacionais da Microsoft, consulte Apêndice A –
Renomeando computadores.

Você pode usar os procedimentos neste tópico para configurar as propriedades IPv4
(Internet Protocol versão 4) de uma conexão de rede com um endereço IP estático para
computadores que executam Windows Server 2016.
７ Observação

digite os cmdlets a seguir em linhas separadas e pressione ENTER. Você também
deve substituir os nomes de interface e os endereços IP neste exemplo pelos
valores que deseja usar para configurar o seu computador.
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
Para configurar um endereço IP estático em computadores que

executam Windows Server 2016, Windows Server 2012 R2 e Windows
Server 2012
1. Na barra de tarefas, clique com o botão direito do mouse no ícone Rede e clique
em Abrir a Central de Rede e Compartilhamento.
2. Na Central de Rede e Compartilhamento, clique em Alterar as configurações do
adaptador. A pasta Conexões de Rede é aberta e exibe as conexões de rede
disponíveis.
3. Em Conexões de Rede, clique com o botão direito do mouse na conexão que

deseja configurar e clique em Propriedades. A caixa de diálogo Propriedades da
conexão de rede é aberta.
4. Na caixa de diálogo Propriedades da conexão de rede, em Esta conexão utiliza os

seguintes itens, selecione Protocolo TCP/IPv4 (TCP/IP Versão 4) e clique em
Propriedades. A caixa de diálogo Propriedades do Protocolo TCP/IPv4 (TCP/IP
Versão 4) será aberta.
5. Em Propriedades do Protocolo TCP/IPv4 (TCP/IP Versão 4), na guia Geral, clique

em Usar o seguinte endereço IP. Em Endereço IP, digite o endereço IP que deseja
usar.
6. Pressione Tab para colocar o cursor em Máscara de sub-rede. Um valor padrão

para máscara de sub-rede será inserido automaticamente. Aceite a máscara de
sub-rede padrão ou digite a máscara de sub-rede que deseja usar.
7. No Gateway padrão, digite o endereço IP do seu gateway padrão.
７ Observação
Configure o Gateway padrão com o mesmo endereço IP usado na interface

de LAN (rede de área local) do seu roteador. Por exemplo, se você tiver um
roteador que está conectado a uma WAN (rede de longa distância), como a
Internet, bem como a sua LAN, configure a interface de LAN com o mesmo
endereço IP que você especificará como o Gateway padrão. Em outro
exemplo, se você tiver um roteador que está conectado a duas LANs, onde a
LAN A usa o intervalo de endereços 10.0.0.0/24 e a LAN B usa o intervalo de
endereços 192.168.0.0/24, configure a LAN A com um endereço de IP de
roteador a partir desse intervalo de endereço, como 10.0.0.1. Além disso, no
escopo DHCP desse intervalo de endereços, configure o Gateway padrão com
o endereço IP 10.0.0.1. Para a LAN B, configure a interface do roteador da
LAN B com um endereço desse intervalo de endereços, como 192.168.0.1, e
configure o escopo da LAN B 192.168.0.0/24 com um valor de Gateway
padrão de 192.168.0.1.
8. Em Servidor DNS preferencial, digite o endereço IP do seu servidor DNS. Se você

planeja usar o computador local como o servidor DNS preferencial, digite o
endereço IP do computador local.
9. Em Servidor DNS alternativo, digite o endereço IP do seu servidor DNS

alternativo, se houver. Se você planeja usar o computador local como um servidor
DNS alternativo, digite o endereço IP do computador local.
10. Clique em OKe então clique em Fechar.
７ Observação
Para obter informações sobre como configurar um endereço IP estático em

computadores que estão executando outros sistemas operacionais da Microsoft,
consulte Apêndice B – Configurando endereços IP estáticos.
Implantando o DC1
Para implantar o DC1, que é o computador que executa o AD DS (Serviços de Domínio

Active Directory) e o DNS, conclua estas etapas na seguinte ordem:
Siga as etapas na seção Configurando todos os servidores.
Instalar o AD DS e o DNS para uma Nova Floresta
Criar uma Conta de Usuário em Usuários e Computadores do Active Directory
Atribuir a associação ao grupo
Configurar uma zona de pesquisa inversa de DNS
Privilégios administrativos
Se você estiver instalando uma rede pequena e for o único administrador da rede,
recomendamos que crie uma conta de usuário para si mesmo e adicione sua conta de
usuário como um membro dos Administradores de Empresa e Administradores do
Domínio. Isso tornará mais fácil para você atuar como o administrador de todos os
recursos de rede. Também recomendamos que você faça logon com essa conta
somente quando precisar executar tarefas administrativas e crie uma conta de usuário
separada para executar outras tarefas relacionadas.
Se você tem uma organização maior com vários administradores, consulte a

documentação do AD DS para determinar a melhor associação de grupo para os
funcionários da organização.
Diferenças entre contas de usuário de domínio e contas de usuário no computador
local
Uma das vantagens de uma infraestrutura baseada em domínio é que você não precisa
criar contas de usuário em cada computador no domínio. Isso é verdadeiro quando o
computador é um computador cliente ou um servidor.
Devido a isso, você não deve criar contas de usuário em cada computador no domínio.
Crie todas as contas de usuário em Usuários e Computadores do Active Directory e use
os procedimentos anteriores para atribuir a associação de grupo. Por padrão, todas as
contas de usuário são membros do grupo Usuários do Domínio.
Todos os membros do grupo Usuários do Domínio podem fazer logon em qualquer

computador cliente depois que ele é associado ao domínio.
Você pode configurar contas de usuário para designar os dias e horários em que o
usuário tem permissão para fazer logon no computador. Você também pode designar
que computadores cada usuário tem permissão para usar. Para definir essas
configurações, abra Usuários e Computadores do Active Directory, localize a conta de
usuário que deseja configurar e clique duas vezes na conta. Em Propriedades da conta
de usuário, clique na guia Conta e clique em Horário de Logon ou em Fazer Logon em.
Instalar o AD DS e o DNS para uma Nova Floresta
Você pode usar um dos procedimentos a seguir para instalar Active Directory Domain
Services (AD DS) e DNS e criar um novo domínio em uma nova floresta.
O primeiro procedimento fornece instruções sobre como executar essas ações usando
Windows PowerShell, enquanto o segundo procedimento mostra como instalar o AD DS
e o DNS usando Gerenciador do Servidor.
） Importante
Depois que você concluir a execução das etapas neste procedimento, o

computador será reiniciado automaticamente.
Instalar o AD DS e o DNS usando Windows PowerShell
Você pode usar os comandos a seguir para instalar e configurar o AD DS e o DNS. Você
deve substituir o nome de domínio neste exemplo pelo valor que deseja usar para seu
domínio.
７ Observação
Para obter mais informações sobre esses comandos Windows PowerShell, consulte
os tópicos de referência a seguir.
Install-WindowsFeature
Install-ADDSForest
O mínimo necessário para executar este procedimento é ser membro do grupo

Administradores.
Execute Windows PowerShell como administrador, digite o seguinte comando e

pressione ENTER:
PowerShell
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools`
Quando a instalação for concluída com êxito, a mensagem a seguir será exibida em
Windows PowerShell.
Êxito Reinicialização Código de Resultado do recurso

necessária Saída
True Não Êxito {Active Directory Domain Services, Grupo

P...
Em Windows PowerShell, digite o seguinte comando, substituindo o texto

corp.contoso.com pelo nome de domínio e pressione ENTER:
PowerShell
Install-ADDSForest -DomainName "corp.contoso.com"
Durante o processo de instalação e configuração, que é visível na parte superior da

janela Windows PowerShell, o prompt a seguir é exibido. Depois de aparecer,
digite uma senha e pressione ENTER.
SafeModeAdministratorPassword:
Depois de digitar uma senha e pressionar ENTER, o prompt de confirmação a

seguir será exibido. Digite a mesma senha e pressione ENTER.
Confirme SafeModeAdministratorPassword:
Quando o prompt a seguir for exibido, digite a letra Y e pressione 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"):
Se desejar, leia as mensagens de aviso exibidas durante a instalação normal e

bem-sucedida do AD DS e do DNS. Essas mensagens são normais e não são uma
indicação de falha na instalação.
Depois que a instalação for bem-sucedida, uma mensagem será exibida

informando que você está prestes a ser desconectado do computador para que o
computador possa reiniciar. Se você clicar em Fechar, será imediatamente
desconectado do computador e o computador será reiniciado. Se você não clicar
em Fechar, o computador será reiniciado após um período de tempo padrão.
Depois que o servidor for reiniciado, você poderá verificar a instalação bem-
sucedida de Active Directory Domain Services e DNS. Abra Windows PowerShell,
digite o comando a seguir e pressione ENTER.
PowerShell
Get-WindowsFeature
Os resultados desse comando são exibidos em Windows PowerShell e devem ser

semelhantes aos resultados na imagem abaixo. Para tecnologias instaladas, os colchetes
à esquerda do nome da tecnologia contêm o caractere X e o valor de Estado de
Instalação é Instalado.
Instalar o AD DS e o DNS usando Gerenciador do Servidor
1. No DC1, no Gerenciador do Servidor, clique em Gerenciar e em Adicionar

Funções e Recursos. O Assistente para Adicionar Funções e Recursos é aberto.
2. Em Antes de Começar, clique em Avançar.
７ Observação
A página Antes de Começar do Assistente para Adicionar Funções e Recursos

não é exibida quando você marca a opção Ignorar esta página por padrão
quando o Assistente para Funções e Recursos foi executado.
3. Em Selecionar Tipo de Instalação, verifique se Instalação baseada em função ou

recurso está marcada e clique em Avançar.
4. Em Selecionar servidor de destino, verifique se Selecionar um servidor no pool

de servidores está marcada. Em Pool de Servidores, verifique se o computador
local está selecionado. Clique em Próximo.
5. Em Selecionar funções de servidor, em Funções, clique em Serviços de Domínio

Active Directory. Em Adicionar recursos que são necessários para Serviços de
Domínio Active Directory, clique em Adicionar Recursos. Clique em Próximo.
6. Em Selecionar recursos, clique em Avançar e, em Serviços de Domínio Active

Directory, analise as informações fornecidas e clique em Avançar.
7. Em Confirmar seleções de instalação, clique em Instalar. A página Progresso da

instalação exibe o status durante o processo de instalação. Quando o processo é
concluído, nos detalhes da mensagem, clique em Promover este servidor a um
controlador de domínio. O Assistente de Configuração dos Serviços de Domínio
Active Directory é aberto.
8. Em Configuração de Implantação, selecione Adicionar uma nova floresta. Em

Nome do domínio raiz, digite o FQDN (nome de domínio totalmente qualificado
do seu domínio. Por exemplo, se o FQDN for corp.contoso.com, digite
corp.contoso.com. Clique em Próximo.
9. Em Opções do Controlador de Domínio, em Selecionar nível funcional da nova

floresta e do domínio raiz, selecione o nível funcional da floresta e o nível
funcional do domínio que você deseja usar. Em Especificar recursos do
controlador de domínio, verifique se as opções Servidor do Sistema de Nomes
de Domínio (DNS) e Catálogo Global (GC) estão marcadas. Em Senha e Confirmar
senha, digite a senha do DSRM (Modo de Restauração de Serviços de Diretório)
que você deseja usar. Clique em Próximo.
10. Em Opções do DNS, clique em Avançar.
11. Em Opções Adicionais, verifique o nome NetBIOS atribuído ao domínio e o altere

quando necessário. Clique em Próximo.
12. Em Caminhos, em Especificar o local do banco de dados do AD DS, arquivos de

log e SYSVOL, execute um destes procedimentos:
Aceite os valores padrão.
Digite os locais de pasta que deseja usar para a Pasta do banco de dados,
Pasta dos arquivos de log e Pasta SYSVOL.
13. Clique em Próximo.
14. Em Examinar Opções, analise suas seleções.
15. Se você deseja exportar as configurações para um script do Windows PowerShell,

clique em Exibir script. O script é aberto no Bloco de Notas e você pode salvá-lo
no local de pasta desejado. Clique em Próximo. Em Verificação de Pré-Requisitos,
suas seleções são validadas. Quando a verificação for concluída, clique em Instalar.
Quando o Windows solicitar, clique em Fechar. O servidor é reiniciado para
concluir a instalação do AD DS e do DNS.
16. Para verificar a instalação bem-sucedida, exiba o console do Gerenciador do

Servidor após a reinicialização do servidor. O AD DS e o DNS devem aparecer no
painel esquerdo, como os itens realçados na imagem abaixo.
Criar uma Conta de Usuário em Usuários e Computadores do
Active Directory
Você pode usar este procedimento para criar uma nova conta de usuário de domínio no
MMC (Console de Gerenciamento Microsoft) Usuários e Computadores do Active
Directory.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a

execução deste procedimento.
７ Observação

digite o cmdlet a seguir em uma linha e pressione ENTER. Você também deve
substituir o nome da conta de usuário neste exemplo pelo valor que você deseja
usar.
New-ADUser -SamAccountName User1 -AccountPassword (read-host "Set user
password" -assecurestring) -name "User1" -enabled $true -PasswordNeverExpires

$true -ChangePasswordAtLogon $false
Depois de pressionar ENTER, digite a senha da conta de usuário. A conta é criada e,

por padrão, é concedida a associação ao grupo Usuários do Domínio.
Com o cmdlet a seguir, você pode atribuir membros de grupos adicionais à nova
conta de usuário. O exemplo a seguir adiciona User1 aos grupos Administradores
do Domínio e Administradores de Empresa. Antes de executar esse comando,
altere o nome de conta de usuário, o nome do domínio e os grupos para atender
às suas necessidades.
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"
Para criar uma conta de usuário
1. No DC1, no Gerenciador do Servidor, clique em Ferramentas e em Usuários e

Computadores do Active Directory. O MMC Usuários e Computadores do Active
Directory é aberto. Caso ainda não esteja selecionado, clique no nó do seu
domínio. Por exemplo, se o domínio for corp.contoso.com, clique em
corp.contoso.com.
2. No painel de detalhes, clique com o botão direito do mouse na pasta em que você
deseja adicionar uma conta de usuário.
Onde?
Usuários e Computadores do Active Directory/pastade nó de/ domínio
3. Aponte para Novo e clique em Usuário. A caixa de diálogo Novo Objeto – Usuário
é aberta.
4. Em Nome, digite o nome do usuário.
5. Em Iniciais, digite as iniciais do usuário.
6. Em Sobrenome, digite o sobrenome do usuário.
7. Modifique Nome completo para adicionar iniciais ou inverter a ordem do primeiro

e do último nome.
8. Em Nome de logon do usuário, digite o nome de logon do usuário. Clique em

Próximo.
9. Em Novo Objeto - Usuário, em Senha e em Confirmar senha, digite a senha do

usuário e selecione as opções de senha apropriadas.
10. Clique em Avançar, analise as configurações da nova conta de usuário e clique em

Concluir.
Você pode usar este procedimento para adicionar um usuário, computador ou grupo a
um grupo no MMC (Console de Gerenciamento Microsoft) Usuários e Computadores do
Active Directory.

1. No DC1, no Gerenciador do Servidor, clique em Ferramentas e em Usuários e

Computadores do Active Directory. O MMC Usuários e Computadores do Active
Directory é aberto. Caso ainda não esteja selecionado, clique no nó do seu
domínio. Por exemplo, se o domínio for corp.contoso.com, clique em
corp.contoso.com.
2. No painel de detalhes, clique duas vezes na pasta que contém o grupo ao qual
deseja adicionar um membro.
Onde?
/pasta de nó / Usuários e Computadores do Active Directory domínioque

contém o grupo
3. No painel de detalhes, clique com o botão direito do mouse no objeto que deseja
adicionar a um grupo, como um usuário ou computador e clique em
Propriedades. A caixa de diálogo Propriedades do objeto é aberta. Clique na guia
Membro de.
4. Na guia Membro de, clique em Adicionar.
5. Em Insira os nomes de objeto a serem selecionados, digite o nome do grupo ao

qual você deseja adicionar o objeto e clique em OK.
6. Para atribuir a associação de grupo a outros usuários, grupos ou computadores,

repita as etapas 4 e 5 deste procedimento.
Configurar uma zona de pesquisa inversa de DNS
Você pode usar este procedimento para configurar uma zona de pesquisa inversa no
DNS (Sistema de Nome de Domínio).
O mínimo necessário para executar este procedimento é ser membro do grupo

Adminis. do Domínio.
７ Observação
Para organizações de médio e grande porte, é recomendável que você

configure e use o grupo DNSAdmins em Usuários e Computadores do Active
Directory. Para obter mais informações, consulte Recursos técnicos
adicionais.
Para executar este procedimento usando o Windows PowerShell, abra o
PowerShell, digite o cmdlet a seguir em uma linha e pressione ENTER. Você
também deve substituir os nomes da zona de pesquisa inversa DNS e do
arquivo de zona neste exemplo pelos valores que deseja usar. Verifique se
você inverteu a ID de rede para o nome de zona inversa. Por exemplo, se a ID
de rede for 192.168.0, crie o nome da zona de pesquisa inversa 0.168.192.in-
addr.arpa.
Add-DnsServerPrimaryZone 0.0.10.in-addr.arpa -ZoneFile 0.0.10.in-addr.arpa.dns
Para configurar uma zona de pesquisa inversa de DNS
1. No DC1, no Gerenciador do Servidor, clique em Ferramentas e em DNS. O MMS

DNS é aberto.
2. No DNS, clique duas vezes no nome do servidor para expandir a árvore, se ela
ainda não estiver expandida. Por exemplo, se o nome do Servidor DNS for DC1,
clique duas vezes em DC1.
3. Selecione Zonas de Pesquisa Inversa, clique com o botão direito do mouse em

Zonas de Pesquisa Inversa e clique em Nova Zona. O Assistente de Nova Zona se
abre.
4. Em Bem-vindo ao Assistente de Nova Zona, clique em Avançar.
5. Em Tipo de Zona, selecione Zona primária.
6. Se o servidor DNS for um controlador de domínio gravável, verifique se a opção

Armazenar a zona no Active Directory está marcada. Clique em Próximo.
7. Em Escopo de Replicação de Zona do Active Directory, selecione Para todos os

servidores DNS sendo executados em controladores de domínio neste domínio,
a menos que você tenha um motivo específico para escolher uma opção diferente.
Clique em Próximo.
8. Na primeira página de Nome da Zona de Pesquisa Inversa, selecione Zona de

Pesquisa Inversa IPv4. Clique em Próximo.
9. Na segunda página de Nome da Zona de Pesquisa Inversa, selecione uma das

seguintes opções:
Em Identificação de rede, digite a identificação de rede do seu intervalo de

endereços IP. Por exemplo, se o intervalo de endereços IP for 10.0.0.1 a
10.0.0.254, digite 10.0.0.
Em Nome da zona de pesquisa inversa, seu nome da zona de pesquisa

inversa IPv4 é adicionado automaticamente. Clique em Próximo.
10. Em Atualização Dinâmica, selecione o tipo de atualizações dinâmicas que serão

permitidas. Clique em Próximo.
11. Em Concluindo o Assistente de Nova Zona, verifique suas escolhas e clique em
Concluir.
Ingressando computadores servidores no domínio e fazendo logon
Depois de ter instalado o AD DS (Serviços de Domínio Active Directory) e criado uma ou

mais contas de usuário que tem permissões para ingressar um computador no domínio,
você poderá ingressar servidores de rede principal no domínio e fazer logon em
servidores para instalar tecnologias adicionais, como o protocolo DHCP.
Em todos os servidores que você estiver implantando, exceto no servidor que executa o
AD DS, faça o seguinte:
1. Conclua os procedimentos fornecidos em Configurando todos os servidores.
2. Use as instruções nos dois seguintes procedimentos para ingressar seus servidores
no domínio e fazer logon nos servidores para executar tarefas de implantação
adicionais:
７ Observação

digite o cmdlet a seguir e pressione ENTER. Você também deve substituir o nome
do domínio pelo nome que deseja usar.
Add-Computer -DomainName corp.contoso.com
Quando você for solicitado a fazê-lo, digite o nome de usuário e a senha de uma
conta que tenha permissão para ingressar um computador no domínio. Para
reiniciar o computador, digite o comando a seguir e pressione ENTER.
Restart-Computer
Para unir computadores que executam Windows Server 2016, Windows

Server 2012 R2 e Windows Server 2012 ao domínio
1. No Gerenciador do Servidor, clique em Servidor Local. No painel de detalhes,

clique em Grupo de Trabalho. A caixa de diálogo Propriedades do Sistema será
aberta.
2. Na caixa de diálogo Propriedades do Sistema, clique em Alterar. A caixa de

diálogo Alterações de Nome/Domínio do Computador será aberta.
3. No Nome do Computador, em Membro de, clique em Domínio e digite o nome
do domínio no qual você deseja ingressar. Por exemplo, se o nome do domínio for
corp.contoso.com, digite corp.contoso.com.
4. Clique em OK. A caixa de diálogo Segurança do Windows será aberta.
5. Em Alterações de Nome/Domínio do Computador, em Nome de usuário, digite o

nome de usuário, digite a senha no campo Senha e clique em OK. A caixa de
diálogo Alterações de Nome/Domínio do Computador é aberta, dando as boas-
vindas ao domínio. Clique em OK.
6. A caixa de diálogo Alterações de Nome/Domínio do Computador exibe uma

mensagem indicando que você deve reiniciar o computador para aplicar as
alterações. Clique em OK.
7. Na caixa de diálogo Propriedades do Sistema, na guia Nome do Computador,

clique em Fechar. A caixa de diálogo Microsoft Windows é aberta e exibe uma
mensagem, indicando novamente que você deve reiniciar o computador para
aplicar as alterações. Clique em Reiniciar Agora.
７ Observação
Para obter informações sobre como ingressar computadores que estão executando
outros sistemas operacionais da Microsoft no domínio, consulte Apêndice C –
Ingressando computadores no domínio.
Para fazer logon no domínio usando computadores que executam

Windows Server 2016
1. Faça logoff do computador ou o reinicie.
2. Pressione CTRL + ALT + DELETE. A tela de logon é exibida.
3. No canto inferior esquerdo, clique em Outro Usuário.
4. Em Nome de usuário, digite seu nome de usuário.
5. Em Senha, digite sua senha do domínio e clique na seta ou pressione ENTER.
７ Observação
Para obter informações sobre como fazer logon no domínio usando computadores
que executam outros sistemas operacionais da Microsoft, consulte Apêndice D –
Fazer logon no domínio.
Implantando o DHCP1
Antes de implantar este componente da rede principal, faça o seguinte:
Siga as etapas na seção Ingressando computadores servidores no domínio e

fazendo logon.
Para implantar o DHCP1, que é o computador que executa a função de servidor do

protocolo DHCP, conclua estas etapas na seguinte ordem:
Instalar o protocolo DHCP
Criar e ativar um novo escopo do DHCP
７ Observação
Para executar estes procedimentos usando o Windows PowerShell, abra o

PowerShell, digite os cmdlets a seguir em linhas separadas e pressione ENTER.
Substitua o nome do escopo, os intervalos de endereços IP iniciais e finais, a
máscara de sub-rede e outros valores neste exemplo pelos valores que você deseja
usar.
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


EndRange 10.0.1.15
Set-DhcpServerv4OptionValue -DnsDomain corp.contoso.com -DnsServer 10.0.0.2
Add-DhcpServerInDC -DnsName DHCP1.corp.contoso.com
Instalar o protocolo DHCP
Você pode usar este procedimento para instalar e configurar a função de Servidor DHCP
usando o Assistente para Adicionar Funções e Recursos.

Para instalar o DHCP
1. No DHCP1, no Gerenciador do Servidor, clique em Gerenciar e em Adicionar

７ Observação



5. Em Selecionar Funções de Servidor, em Funções, selecione Servidor DHCP. Em

Adicionar recursos que são necessários para Servidor DHCP, clique em Adicionar
Recursos. Clique em Próximo.
6. Em Selecionar recursos, clique em Avançar e, em Servidor DHCP, analise as

informações fornecidas e clique em Avançar.
7. Em Confirmar seleções de instalação, clique em Reiniciar cada servidor de
destino automaticamente, se necessário. Na solicitação de confirmação dessa
seleção, clique em Sim e em Instalar. A página Progresso da instalação exibe o
status durante o processo de instalação. Quando o processo for concluído, a
mensagem "Configuração necessária. A instalação foi bem-sucedida em
ComputerName" é exibida, em que ComputerName é o nome do computador no
qual você instalou o Servidor DHCP. Na janela de mensagem, clique em
Configuração de DHCP concluída. O Assistente de configuração pós-instalação do
DHCP é aberto. Clique em Próximo.
8. Em Autorização, especifique as credenciais que deseja usar para autorizar o

servidor DHCP nos Serviços de Domínio Active Directory e clique em Confirmar.
Na conclusão da autorização, clique em Fechar.
Criar e ativar um novo escopo do DHCP
Você pode usar este procedimento para criar um novo escopo do DHCP usando o MMC
(Console de Gerenciamento Microsoft) DHCP. Quando você conclui o procedimento, o
escopo é ativado e o intervalo de exclusão que você cria impede que o servidor DHCP
conceda os endereços IP usados para configurar estaticamente os servidores e outros
dispositivos que exigem um endereço IP estático.
A associação em Administradores DHCP, ou equivalente, é o requisito mínimo para

executar este procedimento.
Para criar e ativar um novo escopo do DHCP
1. No DHCP1, no Gerenciador do Servidor, clique em Ferramentas e em DHCP. O

MMS DHCP é aberto.
2. No DHCP, expanda o nome do servidor. Por exemplo, se o nome do servidor

DHCP for DHCP1.corp.contoso.com, clique na seta para baixo ao lado de
DHCP1.corp.contoso.com.
3. Abaixo do nome do servidor, clique com o botão direito do mouse em IPv4 e

clique em Novo Escopo. O Assistente para Novos Escopos é aberto.
4. Em Assistente para Novos Escopos, clique em Avançar.
5. No Nome do Escopo, em Nome, digite um nome para o escopo. Por exemplo,

digite Sub-rede 1.
6. Em Descrição, digite uma descrição para o novo escopo e clique em Avançar.

7. Em Intervalo de Endereços IP, faça o seguinte:
a. Em Endereço IP inicial, digite o endereço IP que é o primeiro no intervalo. Por

exemplo, digite 10.0.0.1.
b. Em Endereço IP final, digite o endereço IP que é o último no intervalo. Por

exemplo, digite 10.0.0.254. Os valores para Comprimento e Máscara de sub-
rede são inseridos manualmente, com base no endereço IP que você inseriu
para o Endereço IP inicial.
c. Se necessário, modifique os valores em Comprimento ou Máscara de sub-rede,

de forma adequada para seu esquema de endereçamento.
d. Clique em Próximo.
8. Em Adicionar Exclusões, faça o seguinte:
a. Em Endereço IP inicial, digite o endereço IP que é o primeiro no intervalo de

exclusão. Por exemplo, digite 10.0.0.1.
b. Em Endereço IP final, digite o endereço IP que é o último no intervalo de

exclusão. Por exemplo, digite 10.0.0.15.
9. Clique em Adicionar e em Avançar.
10. Em Duração da Concessão, modifique os valores padrão para Dias, Horas e

Minutos, de forma adequada para sua rede e clique em Avançar.
11. Em Configurar opções DHCP, selecione Sim, desejo configurar essas opções
agora e clique em Avançar.
12. Na seção Roteador (Gateway Padrão), siga um destes procedimentos:
Se você não tiver roteadores na rede, clique em Avançar.
No Endereço IP, digite o endereço IP do seu gateway padrão ou roteador.

Por exemplo, digite 10.0.0.1. Clique em Adicionar e em Avançar.
13. Em Servidor de Nomes de Domínio e DNS, faça o seguinte:
a. Em Domínio pai, digite o nome do domínio DNS usado pelos clientes na

resolução de nomes. Por exemplo, digite corp.contoso.com.
b. Em Nome do servidor, digite o nome do computador DNS usado pelos clientes

na resolução de nomes. Por exemplo, digite DC1.
c. Clique em Resolver. O endereço IP do servidor DNS é adicionado a Endereço IP.
Clique em Adicionar, aguarde a conclusão da validação do endereço IP do
servidor DNS e clique em Avançar.
14. Em Servidores WINS, como você não tem servidores WINS na sua rede, clique em
Avançar.
15. Em Ativar Escopo, selecione Sim, desejo ativar este escopo agora.
16. Clique em Avançare em Concluir.
） Importante
Para criar novos escopos para sub-redes adicionais, repita o procedimento. Use um
intervalo de endereços IP diferente para cada sub-rede que você planeja implantar
e verifique se o encaminhamento de mensagem DHCP está habilitado em todos os
roteadores que levam a outras sub-redes.
Ingressando computadores clientes no domínio e

fazendo logon
７ Observação

digite o cmdlet a seguir e pressione ENTER. Você também deve substituir o nome
do domínio pelo nome que deseja usar.
Add-Computer -DomainName corp.contoso.com
Quando você for solicitado a fazê-lo, digite o nome de usuário e a senha de uma
conta que tenha permissão para ingressar um computador no domínio. Para
reiniciar o computador, digite o comando a seguir e pressione ENTER.
Restart-Computer
Para unir computadores que executam Windows 10 ao domínio
1. Faça logon no computador com a conta de Administrador local.
2. Em Pesquisar na Web e no Windows, digite Sistema. Nos resultados da pesquisa,

clique em Sistema (Painel de controle). Será exibida a caixa de diálogo Sistema.
3. Em Sistema, clique em Configurações avançadas do sistema. A caixa de diálogo
Propriedades do Sistema será aberta. Clique na guia Nome do Computador .
4. Em Nome do Computador, clique em Alterar. A caixa de diálogo Alterações de

Nome/Domínio do Computador será aberta.
5. Em Nome do Computador/Alterações de Domínio , em Membro de, clique em

Domínio e digite o nome do domínio que você deseja ingressar. Por exemplo, se o
nome do domínio for corp.contoso.com, digite corp.contoso.com.



Para unir computadores que executam Windows 8.1 ao domínio
2. Clique com o botão direito do mouse em Iniciar e, em seguida, clique em Sistema.

Será exibida a caixa de diálogo Sistema.
3. Em Sistema, clique em Configurações avançadas do sistema. A caixa de diálogo

Propriedades do Sistema será aberta. Clique na guia Nome do Computador .
4. Em Nome do Computador, clique em Alterar. A caixa de diálogo Alterações de

Nome/Domínio do Computador será aberta.
5. Em Nome do Computador/Alterações de Domínio , em Membro de, clique em

Domínio e digite o nome do domínio que você deseja ingressar. Por exemplo, se o
nome do domínio for corp.contoso.com, digite corp.contoso.com.



Para fazer logon no domínio usando computadores que executam

Windows 10
3. No canto inferior esquerdo, clique em Outro Usuário.
4. Em Nome de usuário, digite o domínio e o nome de usuário no formato

domínio\usuário. Por exemplo, para fazer logon no domínio corp.contoso.com
usando uma conta denominada User-01, digite CORP\User-01.
Implantando recursos opcionais para a autenticação do

acesso à rede e dos serviços Web
Se você pretende implantar servidores de acesso à rede, como pontos de acesso sem fio
ou servidores VPN, depois de instalar sua rede principal, é recomendável implantar um
NPS e um servidor Web. Para implantações de acesso à rede, recomendamos o uso de
métodos de autenticação baseada em certificado seguro. Você pode usar o NPS para
gerenciar políticas de acesso à rede e implantar métodos de autenticação segura. Você
pode usar um servidor Web para publicar a CRL (lista de revogação de certificados) de
sua autoridade de certificação que fornece os certificados para autenticação segura.
７ Observação
Você pode implantar certificados de servidor e outros recursos adicionais por meio
de Guias Complementares de Rede Principal. Para obter mais informações, consulte
Recursos técnicos adicionais.
A ilustração a seguir mostra a topologia rede do Windows Server Core com NPS e
servidores Web adicionados.
As seções a seguir fornecem informações sobre como adicionar servidores NPS e Web a
sua rede.
Implantando o NPS1
Implantando o WEB1
Implantando o NPS1
O servidor NPS (Servidor de Políticas de Rede) é instalado como uma etapa preparatória
para a implantação de outras tecnologias de acesso à rede, como servidores VPN (rede
virtual privada), pontos de acesso sem fio e comutadores de autenticação 802.1X.
O NPS (Servidor de Política de Rede) permite que você configure e gerencie
centralmente as políticas de rede com os seguintes recursos: servidor RADIUS (Serviço
de Usuário Discado de Autenticação Remota) e proxy RADIUS.
O NPS é um componente opcional de uma rede principal, mas você deve instalar o NPS
quando qualquer uma das seguintes opções é verdadeira:
Você está planejando expandir sua rede para incluir servidores de acesso remoto
compatíveis com o protocolo RADIUS, como um computador executando
Windows Server 2016, Windows Server 2012 R2 Windows Server 2012 , Windows
Server 2008 R2 ou Windows Server 2008 e Serviço de Roteamento e Acesso
Remoto, Gateway de Serviços de Terminal ou Gateway de Área de Trabalho
Remota.
Você planeja implantar a autenticação 802.1X para acesso com fio ou sem fio.
Antes de implantar esse serviço de função, você deve executar as seguintes etapas no
computador que está configurando como um NPS.

fazendo logon.
Para implantar o NPS1, que o computador está executando o serviço de função do NPS
(Servidor de Políticas de Rede) da função de servidor de Política de Rede e Serviços de
Acesso, conclua esta etapa:
Planejando a implantação do NPS1
Instalar o NPS (Servidor de Políticas de Rede)
Registrar o NPS no domínio padrão
７ Observação
Este guia fornece instruções para implantar o NPS em um servidor autônomo ou

uma VM chamada NPS1. Outro modelo de implantação recomendado é a
instalação do NPS em um controlador de domínio. Se você preferir instalar o NPS
em um controlador de domínio em vez de em um servidor autônomo, instale o
NPS no DC1.
Planejando a implantação do NPS1

Se você pretende implantar servidores de acesso à rede, como pontos de acesso sem fio
ou servidores VPN, depois de implantar a rede principal, recomendamos que implante o
NPS.
Quando você usa o NPS como um servidor do serviço RADIUS, o NPS executa a
autenticação e a autorização para solicitações de conexão por meio de servidores de
acesso à rede. O NPS também permite que você configure e gerencie de forma
centralizada as políticas de rede que determinam quem pode acessar a rede, como eles
podem acessar a rede e quando eles podem acessar a rede.
Estas são as principais etapas de planejamento antes de instalar o NPS.
Planeje o banco de dados de contas de usuário. Por padrão, se você ingressar o

servidor que executa o NPS em um domínio do Active Directory, o NPS executará a
autenticação e a autorização usando o banco de dados de contas de usuário do
AD DS. Em alguns casos, como em grandes redes que usam o NPS como um proxy
RADIUS para encaminhar solicitações de conexão a outros servidores RADIUS,
você pode desejar instalar o NPS em um computador que não é membro do
domínio.
Planeje a contabilização do RADIUS. O NPS permite que você registre em log os

dados de contabilização em um banco de dados SQL Server ou em um arquivo de
texto no computador local. Se você deseja usar o registro em log do SQL Server,
planeje a instalação e a configuração de seu servidor que executa o SQL Server.
Você pode usar esse procedimento para instalar o NPS (Servidor de Política de Rede)
usando o Assistente para Adicionar Funções e Recursos. O NPS é um serviço de função
da função de servidor Serviços de Acesso e Política de Rede.
７ Observação
Por padrão, o NPS ouve o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 em
todos os adaptadores de rede instalados. Se o Firewall do Windows com Segurança
Avançada estiver habilitado quando você instala o NPS, as exceções de firewall para
essas portas serão criadas automaticamente durante o processo de instalação para
o tráfego IPv6 (Protocolo de Internet 6) e IPv4. Se os servidores de acesso à rede
estiverem configurados para enviar tráfego RADIUS por portas diferentes desses
padrões, remova as exceções criadas no Firewall do Windows com Segurança
Avançada durante a instalação do NPS e crie exceções para as portas que você usa
para o tráfego RADIUS.
Credenciais Administrativas
Para concluir este procedimento, você deve ser um membro do grupo Administradores
de Domínio.
７ Observação

digite o texto a seguir e pressione ENTER.
Install-WindowsFeature NPAS -IncludeManagementTools
Para instalar o NPS
1. No NPS1, no Gerenciador do Servidor, clique em Gerenciar e em Adicionar

７ Observação



5. Em Selecionar Funções de Servidor, em Funções, selecione Política de Rede e

Serviços de Acesso. Uma caixa de diálogo é aberta perguntando se ela deve
adicionar recursos necessários para a Política de Rede e os Serviços de Acesso.
Clique em Adicionar Recursose depois em Avançar.
6. Em Selecionar recursos, clique em Avançar e, em Serviços de Acesso e Política de

Rede, analise as informações fornecidas e clique em Avançar.
7. Em Selecionar serviços de função, clique em Servidor de Políticas de Rede. Em

Adicionar recursos que são necessários para Servidor de Políticas de Rede, clique
em Adicionar Recursos. Clique em Próximo.

status durante o processo de instalação. Quando o processo é concluído, a
mensagem "Instalação bem-sucedida no ComputerName" é exibida, em que
ComputerName é o nome do computador no qual você instalou o Servidor de
Política de Rede. Clique em fechar
Registrar o NPS no domínio padrão
Você pode usar esse procedimento para registrar um NPS no domínio em que o
servidor é um membro de domínio.
Os NPSs devem ser registrados no Active Directory para que tenham permissão para ler
as propriedades discadas das contas de usuário durante o processo de autorização.
Registrar um NPS adiciona o servidor ao grupo SERVIDORES RAS e IAS no Active
Directory.
Credenciais administrativas
de Domínio.
７ Observação
Para executar esse procedimento usando comandos de shell de rede (Netsh) em

Windows PowerShell, abra o PowerShell e digite o seguinte e pressione ENTER.
netsh nps add registeredserver domain=corp.contoso.com
server=NPS1.corp.contoso.com
Para registrar um NPS em seu domínio padrão
1. No NPS1, no Gerenciador do Servidor, clique em Ferramentas e em Servidor de

Políticas de Rede. O MMC Servidor de Políticas de Rede é aberto.
2. Clique com o botão direito do mouse em NPS (Local) e clique em Registrar

servidor no Active Directory. A caixa de diálogo Servidor de Políticas de Rede é
aberta.
3. Em Servidor de Políticas de Rede, clique em OK e em OK novamente.
Para obter mais informações sobre o Servidor de Política de Rede, consulte NPS
(Servidor de Política de Rede).
Implantando o WEB1
A função servidor Web (IIS) no Windows Server 2016 fornece uma plataforma segura,
fácil de gerenciar, modular e extensível para hospedar sites, serviços e aplicativos de
forma confiável. Com os Serviços de Informações da Internet (IIS), você pode
compartilhar informações com usuários na Internet, uma intranet ou uma extranet. O IIS
é uma plataforma Web unificada que integra IIS, ASP.NET, serviços FTP, PHP e WCF
(Windows Communication Foundation).
Além de permitir que você publique uma CRL para acesso por computadores membros
do domínio, a função de servidor do Servidor Web (IIS) permite que você configure e
gerencie vários sites, aplicativos Web e sites FTP. O IIS também oferece os seguintes
benefícios:
Maximizar a segurança da Web através de uma estrutura menor de servidores e

isolamento automático de aplicativos.
Implantar e executar facilmente aplicativos Web em ASP.NET, ASP clássico e PHP

no mesmo servidor.
Obter o isolamento do aplicativo dando aos processos de trabalho uma identidade

exclusiva e configuração de área restrita por padrão, reduzindo ainda mais os
riscos de segurança.
Adicionar, remover e até mesmo substituir facilmente componentes internos do IIS

por módulos personalizados, adaptados às necessidades dos clientes.
Acelerar o seu site através de armazenamento em cache dinâmico interno e

compactação aprimorada.
Para implantar o WEB1, que é o computador que está executando a função de servidor
Servidor Web (IIS), faça o seguinte:

fazendo logon.
Instalar a função de servidor do Servidor Web (IIS)

Instalar a função de servidor do Servidor Web (IIS)
Para concluir este procedimento, é preciso ser um membro do grupo Administradores.
７ Observação

digite o texto a seguir e pressione ENTER.
Install-WindowsFeature Web-Server -IncludeManagementTools
1. No Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções

e Recursos. O Assistente para Adicionar Funções e Recursos é aberto.
７ Observação

3. Na página Selecionar Tipo de Instalação , clique em Avançar.
4. Na página Selecionar servidor de destino , verifique se o computador local está

selecionado e clique em Avançar.
5. Na página Selecionar funções de servidor , role até e selecione Servidor Web

(IIS). A caixa de diálogo Adicionar recursos necessários para o Servidor Web (IIS)
é aberta. Clique em Adicionar Recursose depois em Avançar.
6. Clique em Avançar até ter aceitado todas as configurações padrão do servidor

Web e clique em Instalar.
7. Confirme se todas as instalações tiveram êxito e clique em Fechar.
Recursos técnicos adicionais

Para obter mais informações sobre as tecnologias neste guia, consulte os recursos a
seguir:
Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012 Recursos da
Biblioteca Técnica
Novidades no AD DS (Active Directory Domain Services) no Windows Server 2016
Active Directory Domain Services visão geral em

https://technet.microsoft.com/library/hh831484.aspx .
Visão geral do DNS (Sistema de Nomes de Domínio) em

Implementando a função de administradores DNS
Visão geral do DHCP (Dynamic Host Configuration Protocol) em

Visão geral da Política de Rede e dos Serviços de Acesso em

Visão geral do IIS (Servidor Web) em

Apêndices A a E
As seções a seguir contêm informações de configuração adicionais para computadores
que estão executando sistemas operacionais diferentes de Windows Server 2016,
Windows 10, Windows Server 2012 e Windows 8. Além disso, uma planilha de
preparação de rede é fornecida para ajudá-lo na implantação.
1. Apêndice A – Renomeando computadores
2. Apêndice B – Configurando endereços IP estáticos
3. Apêndice C – Ingressando computadores no domínio
4. Apêndice D – Fazer logon no domínio
5. Apêndice E – Folha de preparação do planejamento da Rede Principal
Apêndice A – Renomeando computadores

Você pode usar os procedimentos nesta seção para fornecer computadores que
executam o Windows Server 2008 R2, Windows 7, Windows Server 2008 e Windows
Vista com um nome de computador diferente.
Windows Server 2008 R2 e Windows 7
Windows Server 2008 e Windows Vista
Para renomear os computadores que executam o Windows Server

2008 R2 e o Windows 7
1. Clique em Iniciar, clique com botão direito do computadore clique em

Propriedades. Será exibida a caixa de diálogo Sistema.
2. Em Nome do computador, domínio e configurações de grupo de trabalho, clique

em Alterar configurações. A caixa de diálogo Propriedades do Sistema será
aberta.
７ Observação
Em computadores que executam o Windows 7, antes que a caixa de diálogo

Propriedades do Sistema seja aberta, a caixa de diálogo Controle de Conta
de Usuário será aberta, solicitando permissão para continuar. Clique em
Continuar para prosseguir.
3. Clique em Alterar. A caixa de diálogo Alterações de Nome/Domínio do

Computador será aberta.
4. Em Nome do Computador, digite o nome do seu computador. Por exemplo, se

você deseja denominar o computador como DC1, digite DC1.
5. Clique em OK duas vezes, clique em Fechar e depois em Reiniciar Agora para

reiniciar o computador.
Para renomear os computadores executando o Windows Server

2008 e o Windows Vista

aberta.
７ Observação
Em computadores que executam o Windows Vista, antes que a caixa de

diálogo Propriedades do Sistema seja aberta, a caixa de diálogo Controle de
Conta de Usuário será aberta, solicitando permissão para continuar. Clique
em Continuar para prosseguir.

4. Em Nome do Computador, digite o nome do seu computador. Por exemplo, se

você deseja denominar o computador como DC1, digite DC1.
5. Clique em OK duas vezes, clique em Fechar e depois em Reiniciar Agora para

reiniciar o computador.
Apêndice B – Configurando endereços IP

estáticos
Este tópico fornece procedimentos para configurar endereços IP estáticos em
computadores que executam os seguintes sistemas operacionais:
Windows Server 2008

A associação em Administradores, ou equivalente, é o requisito mínimo para executar
este procedimento.
Para configurar um endereço IP estático em um computador

executando o Windows Server 2008 R2
1. Clique em Iniciar e em Painel de Controle.

2. Em Painel de Controle, clique em Rede e Internet. A janela Rede e Internet será
aberta.
Em Rede e Internet, clique em Central de Rede e Compartilhamento. A Central de

Rede e Compartilhamento será aberta.
3. Na Central de Rede e Compartilhamento, clique em Alterar as configurações do

adaptador. A janela Conexões de Rede será aberta.
4. Em Conexões de Rede, clique com o botão direito na conexão de rede que deseja
configurar e clique em Propriedades.
5. Em Propriedades da Conexão Local, em Esta conexão utiliza os seguintes itens,

selecione Protocolo TCP/IPv4 (TCP/IP Versão 4) e clique em Propriedades. A caixa
de diálogo Propriedades do Protocolo TCP/IPv4 (TCP/IP Versão 4) será aberta.

usar.



Windows Server 2008

Para configurar um endereço IP estático em um computador

executando o Windows Server 2008
1. Clique em Iniciar e em Painel de Controle.
2. No Painel de Controle, selecione o Modo de Exibição Clássico e clique duas vezes

em Central de Rede e Compartilhamento.
3. Na Central de Rede e Compartilhamento, em Tarefas, clique em Gerenciar

Conexões de Rede.
4. Em Conexões de Rede, clique com o botão direito na conexão de rede que deseja
configurar e clique em Propriedades.
5. Em Propriedades da Conexão Local, em Esta conexão utiliza os seguintes itens,

selecione Protocolo TCP/IPv4 (TCP/IP Versão 4) e clique em Propriedades. A caixa
de diálogo Propriedades do Protocolo TCP/IPv4 (TCP/IP Versão 4) será aberta.

usar.



Apêndice C - Ingressando computadores no

domínio
Você pode usar esses procedimentos para ingressar computadores que executam o
Windows Server 2008 R2, Windows 7, Windows Server 2008 e Windows Vista no
domínio.

） Importante
Para ingressar um computador em um domínio, faça logon no computador com a

conta de Administrador local ou, se já estiver conectado ao computador com uma
conta de usuário que não tem credenciais administrativas do computador local,
forneça as credenciais para a conta de Administrador local durante o processo de
ingressar o computador no domínio. Além disso, você deve ter uma conta de
usuário no domínio no qual deseja ingressar o computador. Durante o processo de
ingressar o computador no domínio, você será solicitado para inserir as credenciais
de conta de domínio (nome de usuário e senha).

O requisito mínimo para executar este procedimento é a associação ao grupo Usuários
do Domínio ou equivalente.
Para ingressar computadores que executam o Windows Server

2008 R2 e o Windows 7 no domínio


aberta.
７ Observação
Em computadores que executam o Windows 7, antes que a caixa de diálogo

Propriedades do Sistema seja aberta, a caixa de diálogo Controle de Conta
de Usuário será aberta, solicitando permissão para continuar. Clique em
Continuar para prosseguir.

5. No Nome do Computador, em Membro de, selecione Domínio e digite o nome



Para ingressar computadores que executam o Windows Server

2008 e o Windows Vista no domínio


aberta.

5. No Nome do Computador, em Membro de, selecione Domínio e digite o nome




Apêndice D – Fazer logon no domínio

Você pode usar esses procedimentos para fazer logon no domínio usando
computadores que executam o Windows Server 2008 R2, Windows 7, Windows Server
2008 e Windows Vista.

Fazer logon no domínio usando computadores que executam o

Windows Server 2008 R2 e o Windows 7
3. Clique em Trocar de Usuário e em Outro Usuário.

Fazer logon no domínio usando computadores que executam o

Windows Server 2008 e o Windows Vista
3. Clique em Trocar de Usuário e em Outro Usuário.

Apêndice E – Folha de preparação do

planejamento da Rede Principal
Você pode usar esta Folha de preparação do planejamento de Rede Principal para obter
as informações necessárias para instalar uma rede principal. Este tópico fornece as
tabelas que contêm os itens de configuração individual para cada computador do
servidor para o qual você deve fornecer informações ou valores específicos durante o
processo de instalação ou configuração. Os valores de exemplo são fornecidos para
cada item de configuração.
Para fins de planejamento e acompanhamento, os espaços são fornecidos em cada

tabela para você inserir os valores usados para sua implantação. Se você se registrar em
log os valores relacionados com a segurança nessas tabelas, deverá armazenar as
informações em um local seguro.
Estes links levam para as seções neste tópico que fornecem itens de configuração e
exemplos de valores que estão associados com os procedimentos de implantação
apresentados neste guia.
1. Instalando os Serviços de Domínio Active Directory e o DNS

Configurando uma zona de pesquisa inversa de DNS
2. Instalando o DHCP
Criando um intervalo de exclusão no DHCP
Criando um novo escopo do DHCP
3. Instalando o Servidor de Políticas de Rede (opcional)
Instalando os Serviços de Domínio Active Directory e o

DNS
As tabelas nesta seção listam os itens de configuração para a pré-instalação e a
instalação do AD DS (Serviços de Domínio Active Directory) e do DNS.
Itens de configuração de pré-instalação para o AD DS e o DNS
As seguintes tabelas listam os itens de configuração de pré-instalação descritos em

Configurando todos os servidores:
Itens de configuração Valores de exemplo Valores
Gateway padrão 10.0.0.1
Servidor DNS alternativo 10.0.0.15
Item de configuração Valor de exemplo Valor
Nome do computador DC1
Itens de configuração de instalação do AD DS e do DNS
Itens de configuração para o procedimento de implantação da Rede Principal do

Windows Server Instalar o AD DS e o DNS para uma Nova Floresta:
Nome DNS completo corp.contoso.com
Nível funcional da floresta Windows Server

2003
Local da pasta do banco de dados dos Serviços de Domínio E:\Configuração\

Active Directory Ou aceite o local
padrão.
Local da pasta dos arquivos de log dos Serviços de Domínio E:\Configuração\

Active Directory Ou aceite o local
padrão.
Local da pasta do SYSVOL dos Serviços de Domínio Active E:\Configuração\

padrão.
Senha do Administrador do Modo de Restauração de Diretório J*p2leO4$F
Nome de arquivo de resposta (opcional) AD DS_AnswerFile
Configurando uma zona de pesquisa inversa de DNS
Tipo de zona: - Zona primária
- Zona secundária
- Zona stub
Tipo de zona -Selecionado
Armazenar a zona no Active - Não selecionado

Directory
Escopo de replicação de – Para todos os servidores DNS nessa floresta
zona do Active Directory – Para todos os servidores DNS neste domínio
– Para todos os controladores de domínio neste

domínio
– Para todos os controladores de domínio especificados

no escopo desta partição de diretório
Nome da zona de pesquisa - Zona de Pesquisa Inversa IPv4
inversa - Zona de Pesquisa Inversa IPv6

(tipo de IP)
Nome da zona de pesquisa 10.0.0

inversa
(ID da rede)
Instalando o DHCP
As tabelas nesta seção listam os itens de configuração de pré-instalação e de instalação
do DHCP.
Itens de configuração de pré-instalação do DHCP
As seguintes tabelas listam os itens de configuração de pré-instalação descritos em

Nome do computador DHCP1
Itens de configuração de instalação do DHCP
Os itens de configuração do procedimento de implantação da Rede Principal do

Windows Server Instalar o protocolo DHCP:
Ligações de conexão de rede Ethernet
Configurações do servidor DNS DC1
Endereço IP do servidor DNS alternativo 10.0.0.15
Nome do escopo Corp1

Endereço IP inicial 10.0.0.1
Endereço IP final 10.0.0.254
Gateway padrão (opcional) 10.0.0.1
Duração da concessão 8 dias
Modo de operação do servidor DHCP IPv6 não ativado
Criando um intervalo de exclusão no DHCP

Itens de configuração para criar um intervalo de exclusão durante a criação de um
escopo no DHCP.
Nome do escopo Corp1
Descrição do escopo Sub-rede do escritório principal 1
Endereço IP inicial do intervalo de exclusão 10.0.0.1
Endereço IP final do intervalo de exclusão 10.0.0.15
Criando um novo escopo do DHCP
Os itens de configuração do procedimento de implantação da Rede Principal do

Windows Server Criar e ativar um novo escopo do DHCP:
Novo nome do escopo Corp2
Descrição do escopo Sub-rede do escritório principal 2
(intervalo de endereços IP) 10.0.1.1

Endereço IP inicial
(intervalo de endereços IP) 10.0.1.254

Endereço IP final
Comprimento 8
Endereço IP Inicial (intervalo de exclusão) 10.0.1.1
Endereço IP final do intervalo de exclusão 10.0.1.15
Duração da concessão - 8
Dias - 0
-0
Horas
minutos
Roteador (gateway padrão) 10.0.1.1

Endereço IP
Domínio pai DNS corp.contoso.com
Servidor DNS 10.0.0.2

Endereço IP
Instalando o Servidor de Políticas de Rede (opcional)

As tabelas nesta seção listam os itens de configuração de pré-instalação e de instalação
do NPS.
Itens de configuração de pré-instalação
As seguintes três tabelas listam os itens de configuração de pré-instalação descritos em

Nome do computador NPS1
Itens de configuração de instalação do Servidor de Políticas de

Rede
Itens de configuração para os procedimentos de implantação NPS da Rede Principal do

Windows Server Instalam o NPS (Servidor de Política de Rede) e registram o NPS no
domínio padrão.
Nenhum item de configuração adicional é necessário para instalar e registrar o

NPS.
Diretrizes de complementar de rede
principal
Embora o guia de rede Windows Server 2016 Core forneça instruções sobre como
implantar uma nova floresta do Active Directory® com um novo domínio raiz e a
infraestrutura de rede de suporte, os Guias Adicionais fornecem a capacidade de
adicionar recursos à sua rede.
Cada guia complementar permite cumprir uma meta específica, após a implantação de
sua rede principal. Em alguns casos, existem vários guias complementarem que, quando
implantados juntos e na ordem correta, permitem realizar objetivos muito complexos de
forma medida, econômica e razoável.
Se você implantou sua rede principal e seu domínio do Active Directory antes de
encontrar o Guia da Rede Principal, ainda pode usar os Guias Complementares para
adicionar recursos à sua rede. Simplesmente use o Guia da Rede Principal como uma
lista de pré-requisitos e saiba que, para implantar recursos adicionais com os Guias
Complementares, a rede deve atender aos pré-requisitos que são fornecidos pelo Guia
da Rede Principal.
Guia de adoção de rede principal: Implantar

certificados de servidor para implantações com
fio e sem fio 802.1X
Este guia de adendo explica como se basear na rede principal implantando certificados
de servidor para computadores que executam o NPS (Servidor de Políticas de Rede),
RAS (Serviço de Acesso Remoto) ou ambos.
Quando você implanta os métodos de autenticação baseada em certificados com o

protocolo EAP e o PEAP (EAP protegido) para autenticação de acesso de rede, são
necessários certificados de servidor. Implantar os certificados do servidor com o AD CS
(Serviços de Certificado do Active Directory) para métodos de autenticação baseada em
certificados EAP e PEAP oferece os seguintes benefícios:
Vincular a identidade do servidor NPS ou RAS a uma chave privada

Um método econômico e seguro para registrar automaticamente certificados em
servidores NPS e RAS do membro do domínio
Um método eficiente para o gerenciamento de certificados e autoridades de
certificação
Segurança fornecida por autenticação baseada em certificado
A capacidade de expandir o uso de certificados para outras finalidades
Para obter instruções sobre como implantar certificados de servidor, consulte Implantar
certificados de servidor para implantações com fio e sem fio 802.1X.
Guia de adoção de rede principal: implantar

Password-Based acesso sem fio autenticado
802.1X
Este guia de adoção explica como se basear na rede principal fornecendo instruções
sobre como implantar o acesso sem fio do IEEE (Institute of Electrical and Electronics
Engineers) 802.1X authenticated IEEE 802.11 usando o Protocolo de Autenticação
Extensível Protegido –Microsoft Challenge Handshake Authentication Protocol versão 2
(PEAP-MS-CHAP v2).
O método de autenticação PEAP-MS-CHAP v2 requer que os servidores de autenticação

que executam o NPS (Servidor de Políticas de Rede) apresentem clientes sem fio com
um certificado de servidor para provar a identidade do NPS para o cliente, no entanto, a
autenticação do usuário não é executada usando um certificado – em vez disso, os
usuários fornecem seu nome de usuário de domínio e senha.
Como PEAP-MS-CHAP v2 exige que os usuários forneçam credenciais baseadas em

senha em vez de um certificado durante o processo de autenticação, normalmente é
mais fácil e menos caro implantar do que EAP-TLS ou PEAP-TLS.
Antes de usar este guia para implantar o acesso sem fio com o método de autenticação
PEAP-MS-CHAP v2, você deve fazer o seguinte:
1. Siga as instruções no Guia de Rede Principal para implantar sua infraestrutura de

rede principal ou já tenha as tecnologias apresentadas nesse guia implantadas em
sua rede.
2. Siga as instruções no Guia principal de acompanhamento de rede Implantar
certificados de servidor para implantações com fio e sem fio 802.1X ou já ter as
tecnologias apresentadas nesse guia implantadas em sua rede.
Para obter instruções sobre como implantar o acesso sem fio com PEAP-MS-CHAP v2,
consulte Implantar Password-Based acesso sem fio autenticado 802.1X.
Guia de adoção de rede principal: implantar o

modo de cache hospedado do BranchCache
Este guia adicional explica como implantar o BranchCache no Modo de Cache
Hospedado em uma ou mais filiais.
O BranchCache é uma tecnologia de otimização de largura de banda de WAN (rede de

ampla área) incluída em algumas edições dos sistemas operacionais Windows Server
2016 e Windows 10, bem como em versões anteriores do Windows e Windows Server.
Quando você implanta o BranchCache no modo de cache hospedado, o cache de

conteúdo em uma filial é hospedado em um ou mais servidores, que são chamados de
servidores de cache hospedado. Os servidores de cache hospedados podem executar
cargas de trabalho além de hospedar o cache, o que permite que você use o servidor
para várias finalidades na filial.
O modo de cache hospedado do BranchCache aumenta a eficiência do cache porque o

conteúdo está disponível mesmo se o cliente que originalmente solicitou e armazenava
os dados em cache está offline. Como o servidor de cache hospedado está sempre
disponível, mais conteúdo é armazenado em cache, proporcionando maiores economias
de largura de banda de WAN e aumentando a eficiência do BranchCache.
Quando você implanta o modo de cache hospedado, todos os clientes em uma filial de
várias sub-redes podem acessar um único cache, que é armazenado no servidor de
cache hospedado, mesmo se os clientes estão em sub-redes diferentes.
Para obter instruções sobre como implantar o BranchCache no Modo de Cache

Hospedado, consulte Implantar o Modo de Cache Hospedado do BranchCache.
Implantar certificados de servidor para
implantações com e sem fio do 802.1X
Você pode usar este guia para implantar certificados de servidor em seus servidores de
infraestrutura de acesso remoto e servidor de políticas de rede (NPS).
Este guia contém as seções a seguir.
Pré-requisitos para usar este guia
Visões gerais da tecnologia
Visão geral da implantação de certificado do servidor
Planejamento de implantação de certificado do servidor
Implantação de certificado do servidor
Certificados do servidor digital

Este guia fornece instruções para usar Active Directory serviços de certificados (AD CS)
para registrar automaticamente certificados para acesso remoto e servidores de
infraestrutura do NPS. O AD CS permite criar uma PKI (infraestrutura de chave pública) e
fornecer criptografia de chave pública, certificados digitais e recursos de assinatura
digital para sua organização.
Quando você usa certificados de servidor digital para autenticação entre computadores
em sua rede, os certificados fornecem:
1. Confidencialidade por meio de criptografia.

2. Integridade por meio de assinaturas digitais.
3. Autenticação associando chaves de certificado a contas de computador, usuário ou
dispositivo em uma rede de computadores.
Tipos de servidores
Usando este guia, você pode implantar certificados de servidor nos seguintes tipos de
servidores.
Servidores que executam o serviço de acesso remoto, que são servidores de rede
virtual privada (VPN) do DirectAccess ou padrão, e que são membros do grupo de
Servidores RAS e ias .
Servidores que executam o serviço de servidor de diretivas de rede (NPS) que são
membros do grupo de Servidores RAS e ias .
Vantagens do registro automático de certificado

O registro automático de certificados de servidor, também chamado de inscrição
automática, oferece as seguintes vantagens.
A AC (autoridade de certificação) do AD CS registra automaticamente um

certificado de servidor para todos os seus servidores de acesso remoto e NPS.
Todos os computadores no domínio recebem automaticamente seu certificado de
autoridade de certificação, que é instalado no repositório de autoridades de
certificado raiz confiáveis em cada computador membro do domínio. Por isso,
todos os computadores no domínio confiam nos certificados emitidos pela sua
autoridade de certificação. Essa confiança permite que seus servidores de
autenticação comprovem suas identidades entre si e participem de comunicações
seguras.
Além de atualizar Política de Grupo, a reconfiguração manual de todos os
servidores não é necessária.
Cada certificado de servidor inclui a finalidade de autenticação de servidor e a
finalidade de autenticação de cliente em extensões EKU (uso avançado de chave).
Escalabilidade. depois de implantar seu Enterprise ac raiz com este guia, você pode
expandir sua PKI (infraestrutura de chave pública) adicionando Enterprise CAs
subordinadas.
Capacidade de gerenciamento. você pode gerenciar o ad cs usando o console do
ad cs ou usando Windows PowerShell comandos e scripts.
Simplicidade. Você especifica os servidores que registram certificados de servidor
usando Active Directory contas de grupo e a associação de grupo.
Quando você implanta certificados de servidor, os certificados são baseados em
um modelo que você configura com as instruções neste guia. Isso significa que
você pode personalizar modelos de certificado diferentes para tipos de servidor
específicos ou pode usar o mesmo modelo para todos os certificados de servidor
que você deseja emitir.
Este guia fornece instruções sobre como implantar certificados de servidor usando o AD
CS e a função de servidor do servidor Web (IIS) no Windows Server 2016. Veja a seguir
os pré-requisitos para executar os procedimentos deste guia.
você deve implantar uma rede principal usando o guia de rede Windows Server
2016 core ou já deve ter as tecnologias fornecidas no guia de rede principal
instaladas e funcionando corretamente na rede. Essas tecnologias incluem TCP/IP
V4, DHCP, Active Directory Domain Services (AD DS), DNS e NPS.
７ Observação
o guia de rede de Windows Server 2016 Core está disponível na biblioteca

técnica Windows Server 2016. Para obter mais informações, consulte Guia de
rede de núcleo.
Você deve ler a seção de planejamento deste guia para garantir que você está
preparado para essa implantação antes de executar a implantação.
Você deve executar as etapas neste guia na ordem em que elas são apresentadas.
Não vá em frente e implante sua autoridade de certificação sem executar as etapas
que levam à implantação do servidor ou a sua implantação falhará.
você deve estar preparado para implantar dois novos servidores em sua rede-um
servidor no qual você instalará o AD CS como uma autoridade de certificação raiz
Enterprise e um servidor no qual você instalará o servidor web (IIS) para que sua
autoridade de certificação possa publicar a CRL (lista de certificados revogados) no
servidor web.
７ Observação
Você está preparado para atribuir um endereço IP estático aos servidores Web e do
AD CS que você implanta com este guia, bem como para nomear os computadores
de acordo com as convenções de nomenclatura da organização. Além disso, você
deve unir os computadores ao seu domínio.

Este guia não fornece instruções abrangentes para projetar e implantar uma PKI
(infraestrutura de chave pública) usando o AD CS. É recomendável que você examine a
documentação do AD CS e a documentação de design PKI antes de implantar as
tecnologias neste guia.

A seguir estão as visões gerais de tecnologia para o AD CS e o servidor Web (IIS).
Serviços de Certificados do Active Directory

o AD CS no Windows Server 2016 fornece serviços personalizáveis para criar e gerenciar
os certificados X. 509 que são usados em sistemas de segurança de software que
empregam tecnologias de chave pública. As organizações podem usar o AD CS para
aumentar a segurança ligando a identidade de uma pessoa, dispositivo ou serviço a
uma chave pública correspondente. O AD CS também inclui recursos que permitem que
você gerencie o registro e a revogação de certificados em uma variedade de ambientes
escalonáveis.
Para obter mais informações, consulte visão geral dos serviços de certificados Active
Directory e diretrizes de design de infraestrutura de chave pública .
Servidor Web (IIS)

a função servidor Web (IIS) no Windows Server 2016 fornece uma plataforma segura,
fácil de gerenciar, modular e extensível para hospedagem confiável de sites, serviços e
aplicativos. Com o IIS, você pode compartilhar informações com usuários na Internet,
em uma intranet ou em uma extranet. o iis é uma plataforma web unificada que integra
o IIS, ASP.NET, serviços FTP, PHP e Windows Communication Foundation (WCF).
Para obter mais informações, consulte visão geral do servidor Web (IIS).
Visão geral da implantação de
certificado do servidor
Este tópico inclui as seções a seguir.
Componentes de implantação de certificado de servidor
Visão geral do processo de implantação de certificado do servidor
Componentes de implantação de certificado de

servidor
Você pode usar este guia para instalar o AD CS (Active Directory Certificate Services)
como uma AC (autoridade de certificação) raiz Enterprise e registrar certificados de
servidor em servidores que estão executando o NPS (Servidor de Política de Rede),
Roteamento e Serviço de Acesso Remoto (RRAS) ou NPS e RRAS.
Se você implantar o SDN com autenticação baseada em certificado, os servidores serão

obrigados a usar um certificado de servidor para provar suas identidades em outros
servidores para que eles alcancem comunicações seguras.
A ilustração a seguir mostra os componentes necessários para implantar certificados de

servidor em servidores em sua infraestrutura de SDN.
７ Observação
Na ilustração acima, vários servidores são descritos: DC1, CA1, WEB1 e muitos
servidores SDN. Este guia fornece instruções para implantar e configurar o CA1 e o
WEB1 e para configurar o DC1, que este guia pressupõe que você já instalou em
sua rede. Se você ainda não instalou seu domínio do Active Directory, poderá fazê-
lo usando o Guia de Rede Principal para Windows Server 2016.
Para obter mais informações sobre cada item ilustrado na ilustração acima, consulte o
seguinte:
CA1
WEB1
DC1
NPS1
CA1 executando a função de servidor do AD CS

Nesse cenário, a AC (autoridade de certificação raiz) do Enterprise também é uma AC
emissora. A AC emite certificados para computadores de servidor que têm as
permissões de segurança corretas para registrar um certificado. O AD CS (Active
Directory Certificate Services) está instalado no CA1.
Para redes maiores ou em que questões de segurança fornecem justificativa, você pode
separar as funções da AC raiz e da AC emissora e implantar CAs subordinadas que estão
emitindo CAs.
Nas implantações mais seguras, a AC raiz Enterprise é retirada offline e fisicamente

protegida.
Capolicy.inf
Antes de instalar o AD CS, configure o arquivo CAPolicy.inf com configurações

específicas para sua implantação.
Cópia do modelo de certificado de servidores RAS e IAS

Ao implantar certificados de servidor, você faz uma cópia do modelo de certificado de
servidores RAS e IAS e, em seguida, configura o modelo de acordo com seus requisitos
e as instruções neste guia.
Você utiliza uma cópia do modelo em vez do modelo original para que a configuração
do modelo original seja preservada para possível uso futuro. Você configura a cópia do
modelo de servidores RAS e IAS para que a AC possa criar certificados de servidor que
ele emite para os grupos em Usuários e Computadores do Active Directory que você
especificar.
Configuração de CA1 adicional

A AC publica uma CRL (lista de revogação de certificado) que os computadores devem
verificar para garantir que os certificados apresentados a eles como prova de identidade
sejam certificados válidos e não tenham sido revogados. Você deve configurar sua AC
com o local correto da CRL para que os computadores saibam onde procurar a CRL
durante o processo de autenticação.
WEB1 executando a função de servidor dos Serviços Web

(IIS)
No computador que está executando a função de servidor do Servidor Web (IIS), WEB1,
você deve criar uma pasta no Gerenciador de Windows para uso como o local para a
CRL e a AIA.
Diretório virtual para CRL e AIA

Depois de criar uma pasta no Windows Explorer, você deve configurar a pasta como um
diretório virtual no Gerenciador de Serviços de Informações da Internet (IIS), bem como
configurar a lista de controle de acesso para o diretório virtual para permitir que os
computadores acessem o AIA e o CRL depois que eles forem publicados lá.
DC1 executando as funções de servidor AD DS e DNS

DC1 é o controlador de domínio e o servidor DNS em sua rede.
Política de Grupo política de domínio padrão

Depois de configurar o modelo de certificado na AC, você pode configurar a política de
domínio padrão em Política de Grupo para que os certificados sejam registrados
automaticamente em servidores NPS e RAS. Política de Grupo está configurado no AD
DS no servidor DC1.
Registro de recurso de Alias DNS (CNAME)
Você deve criar um registro de recurso cname (alias) para o servidor Web para garantir
que outros computadores possam encontrar o servidor, bem como o AIA e a CRL que
estão armazenados no servidor. Além disso, o uso de um registro de recurso CNAME de
alias oferece flexibilidade para que você possa usar o servidor Web para outras
finalidades, como hospedar sites Web e FTP.
NPS1 executando o serviço de função servidor de política

de rede da política de rede e Serviços do Access função
de servidor
O NPS é instalado quando você executa as tarefas no guia de rede do Windows Server
2016 Core, portanto, antes de executar as tarefas neste guia, você já deve ter um ou
mais NPSs instalados em sua rede.
Política de Grupo aplicado e certificado registrado em servidores

Depois de configurar o modelo de certificado e o registro automático, você pode
atualizar Política de Grupo em todos os servidores de destino. Neste momento, os
servidores registram o certificado do servidor da CA1.
Visão geral do processo de implantação de certificado do

servidor
７ Observação
Os detalhes de como executar essas etapas são fornecidos na seção Implantação

de Certificado do Servidor.
O processo de configuração do registro de certificado do servidor ocorre nestas fases:
1. No WEB1, instale a função servidor Web (IIS).
2. No DC1, crie um registro de alias (CNAME) para seu servidor Web, WEB1.
3. Configure o servidor Web para hospedar a CRL da AC e, em seguida, publique a

CRL e copie o certificado de AC raiz Enterprise para o novo diretório virtual.
4. No computador em que você planeja instalar o AD CS, atribua ao computador um

endereço IP estático, renomeie o computador, ingresse o computador no domínio
e faça logon no computador com uma conta de usuário que seja membro dos
grupos administradores de domínio e Enterprise administradores.
5. No computador em que você está planejando instalar o AD CS, configure o

arquivo CAPolicy.inf com configurações específicas para sua implantação.
6. Instale a função de servidor do AD CS e execute uma configuração adicional da

AC.
7. Copie o certificado CRL e AC da CA1 para o compartilhamento no web server

Web1.
8. Na AC, configure uma cópia do modelo de certificado ras e ias servers. A AC emite
certificados com base em um modelo de certificado, portanto, você deve
configurar o modelo para o certificado do servidor antes que a AC possa emitir um
certificado.
9. Configure o registro automático de certificado do servidor no Política de Grupo.

Quando você configura o registro automático, todos os servidores especificados
com associações de grupo do Active Directory recebem automaticamente um
certificado de servidor quando Política de Grupo em cada servidor é atualizado. Se
você adicionar mais servidores posteriormente, eles também receberão
automaticamente um certificado de servidor.
10. Atualize Política de Grupo em servidores. Quando Política de Grupo é atualizado,

os servidores recebem o certificado do servidor, que se baseia no modelo que
você configurou na etapa anterior. Esse certificado é usado pelo servidor para
provar sua identidade para computadores cliente e outros servidores durante o
processo de autenticação.
７ Observação
Todos os computadores membros do domínio recebem automaticamente o

certificado da AC raiz Enterprise sem a configuração do registro automático.
Esse certificado é diferente do certificado do servidor que você configura e
distribui usando o registro automático. O certificado da AC é instalado
automaticamente no repositório de certificados autoridades de certificação
raiz confiáveis para todos os computadores membros do domínio para que
eles confiem em certificados emitidos por essa AC.
11. Verifique se todos os servidores registraram um certificado de servidor válido.

Planejamento da implantação de
Antes de implantar certificados de servidor, você deve planejar os seguintes itens:
Planejar a configuração básica do servidor
Planejar o acesso ao domínio
Planejar o local e o nome do diretório virtual em seu servidor Web
Planejar um registro de alias DNS (CNAME) para o servidor Web
Planejar a configuração de CAPolicy.inf
Planejar a configuração das extensões CDP e AIA na CA1
Planejar a operação de cópia entre a AC e o servidor Web
Planejar a configuração do modelo de certificado do servidor na AC

Depois de instalar Windows Server 2016 nos computadores que você está planejando
usar como sua autoridade de certificação e servidor Web, você deve renomear o
computador e atribuir e configurar um endereço IP estático para o computador local.
Para obter mais informações, consulte o Guia Windows Server 2016 De rede principal.

Além disso, a maioria dos procedimentos neste guia exige que a conta de usuário seja
membro dos grupos Administradores do Enterprise ou Administradores de Domínio no
Usuários e Computadores do Active Directory, portanto, você deve fazer logon na AC
com uma conta que tenha a associação de grupo apropriada.
Para obter mais informações, consulte o Guia Windows Server 2016 De rede principal.
Planejar o local e o nome do diretório virtual

em seu servidor Web
Para fornecer acesso à CRL e ao certificado de AC para outros computadores, você deve
armazenar esses itens em um diretório virtual em seu servidor Web. Neste guia, o
diretório virtual está localizado no servidor Web WEB1. Essa pasta está na unidade "C:" e
é chamada de "pki". Você pode localizar o diretório virtual em seu servidor Web em
qualquer local de pasta apropriado para sua implantação.
Planejar um registro de alias DNS (CNAME)

para o servidor Web
Registros de recursos de alias (CNAME) também são, às vezes, chamados de registros de
recurso de nome canônico. Com esses registros, você pode usar mais de um nome para
apontar para um único host, facilitando a tarefa de hospedar um servidor protocolo FTP
(FTP) e um servidor Web no mesmo computador. Por exemplo, os nomes de servidor
conhecidos (ftp, www) são registrados usando registros de recurso de alias (CNAME)
que são mapeados para o nome de host DNS (Sistema de Nomes de Domínio), como
WEB1, para o computador servidor que hospeda esses serviços.
Este guia fornece instruções para configurar seu servidor Web para hospedar a CRL (lista
de certificados revogados) para sua AC (autoridade de certificação). Como você também
pode querer usar seu servidor Web para outras finalidades, como hospedar um FTP ou
site, é uma boa ideia criar um registro de recurso de alias no DNS para seu servidor
Web. Neste guia, o registro CNAME é denominado "pki", mas você pode escolher um
nome apropriado para sua implantação.
Planejar a configuração de CAPolicy.inf

Antes de instalar AD CS, você deve configurar CAPolicy.inf na AC com informações
corretas para sua implantação. Um arquivo CAPolicy.inf contém as seguintes
informações:
[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
Você deve planejar os seguintes itens para este arquivo:
URL. O arquivo CAPolicy.inf de exemplo tem um valor de URL de

https://pki.corp.contoso.com/pki/cps.txt . Isso porque o servidor Web neste
guia é denominado WEB1 e tem um registro de recurso CNAME dns de pki. O
servidor Web também está ingressado no corp.contoso.com domínio. Além disso,
há um diretório virtual no servidor Web chamado "pki" em que a lista de
certificados revogados é armazenada. Verifique se o valor que você fornece para a
URL no arquivo CAPolicy.inf aponta para um diretório virtual no servidor Web em
seu domínio.
RenewalKeyLength. O comprimento da chave de renovação padrão AD CS em

Windows Server 2012 é 2048. O comprimento da chave selecionado deve ser o
máximo possível e ainda fornecer compatibilidade com os aplicativos que você
pretende usar.
RenewalValidityPeriodUnits. O arquivo CAPolicy.inf de exemplo tem um valor

RenewalValidityPeriodUnits de 5 anos. Isso porque o tempo de vida esperado da
AC é de cerca de dez anos. O valor de RenewalValidityPeriodUnits deve refletir o
período de validade geral da AC ou o maior número de anos para os quais você
deseja fornecer o registro.
CRLPeriodUnits. O arquivo CAPolicy.inf de exemplo tem um valor CRLPeriodUnits

de 1. Isso porque o intervalo de atualização de exemplo para a lista de certificados
revogados neste guia é de 1 semana. No valor de intervalo especificado com essa
configuração, você deve publicar a CRL na AC no diretório virtual do servidor Web
em que você armazena a CRL e fornecer acesso a ela para computadores que
estão no processo de autenticação.
AlternateSignatureAlgorithm. Esse CAPolicy.inf implementa um mecanismo de

segurança aprimorado implementando formatos de assinatura alternativos. Você
não deve implementar essa configuração se ainda tiver Windows XP que exigem
certificados dessa AC.
Se você não planeja adicionar nenhuma AC subordinada à sua infraestrutura de chave

pública posteriormente e, se quiser impedir a adição de qualquer AC subordinada,
poderá adicionar a chave PathLength ao arquivo CAPolicy.inf com um valor de 0. Para
adicionar essa chave, copie e copie o seguinte código em seu arquivo:
[BasicConstraintsExtension]
PathLength=0
Critical=Yes
） Importante
Não é recomendável que você altere outras configurações no arquivo CAPolicy.inf,

a menos que você tenha um motivo específico para fazer isso.
Planejar a configuração das extensões CDP e

AIA na CA1
Ao definir as configurações de CDP (Certificate Revocation List) (CRL) e AIA (Acesso a
Informações da Autoridade) na CA1, você precisará do nome do servidor Web e do
nome de domínio. Você também precisa do nome do diretório virtual criado no servidor
Web em que a CRL (lista de certificados revogados) e o certificado da autoridade de
certificação estão armazenados.
O local do CDP que você deve inserir durante essa etapa de implantação tem o formato:
http:\/\/*DNSAlias\
(CNAME\)RecordName*.*Domain*.com\/*VirtualDirectoryName*\/<CaName><CRLNameSuffix>
<DeltaCRLAllowed>.crl.
Por exemplo, se o servidor Web for chamado WEB1 e o registro CNAME do alias DNS
para o servidor Web for "pki", seu domínio será corp.contoso.com e seu diretório virtual
for nomeado pki, o local do CDP será:
http:\/\/pki.corp.contoso.com\/pki\/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
O local do AIA que você deve inserir tem o formato:

http:\/\/*DNSAlias\
(CNAME\)RecordName*.*Domain*.com\/*VirtualDirectoryName*\/<ServerDNSName>\_<CaName>
<CertificateName>.crt.
Por exemplo, se o servidor Web for chamado WEB1 e o registro CNAME do alias DNS
para o servidor Web for "pki", seu domínio será corp.contoso.com e seu diretório virtual
for nomeado pki, o local do AIA será:
http:\/\/pki.corp.contoso.com\/pki\/<ServerDNSName>\_<CaName><CertificateName>.crt
Planejar a operação de cópia entre a AC e o

servidor Web
Para publicar o certificado CRL e CA da AC no diretório virtual do servidor Web, você
pode executar o comando certutil -crl depois de configurar os locais do CDP e do AIA
na AC. Verifique se você configurou os caminhos corretos na guia Extensões de
Propriedades da AC antes de executar este comando usando as instruções neste guia.
Além disso, para copiar o certificado Enterprise AC para o servidor Web, você já deve ter
criado o diretório virtual no servidor Web e configurado a pasta como uma pasta
compartilhada.
Planejar a configuração do modelo de

certificado do servidor na AC
Para implantar certificados de servidor com registro automático, você deve copiar o
modelo de certificado chamado RAS e Servidor IAS. Por padrão, essa cópia é
denominada Cópia do RAS e do Servidor IAS. Se você quiser renomear essa cópia de
modelo, planeje o nome que deseja usar durante essa etapa de implantação.
７ Observação
As três últimas seções de implantação neste guia – que permitem configurar o

registro automático de certificado do servidor, atualizar o Política de Grupo em
servidores e verificar se os servidores receberam um certificado de servidor válido
da AC – não exigem etapas de planejamento adicionais.
Implantação de certificados de servidor
Siga estas etapas para instalar uma AC (autoridade de certificação) raiz corporativa e
implantar certificados de servidor para uso com PEAP e EAP.
） Importante
Antes de instalar Serviços de Certificados do Active Directory, você deve nomear o

computador, configurar o computador com um endereço IP estático e ingressar o
computador no domínio. Depois de instalar AD CS, não é possível alterar o nome
do computador ou a associação de domínio do computador, no entanto, você
pode alterar o endereço IP, se necessário. Para obter mais informações sobre como
realizar essas tarefas, consulte o Guia de rede Windows Server® 2016 Core.
Instalar o servidor Web WEB1
Criar um registro de alias (CNAME) em DNS para WEB1
Configurar o WEB1 para distribuir CRLs (listas de certificados revogados)
Preparar o arquivo de inf CAPolicy
Instalar a autoridade de certificação
Configurar as extensões CDP e AIA na CA1
Copiar o certificado de Autoridade de Certificação e CRL para o diretório virtual
Configurar o modelo de certificado do servidor
Configurar o registro automático de certificados do servidor
Atualizar Política de Grupo
Verificar o registro de servidor de um certificado do servidor
７ Observação
Os procedimentos deste guia não incluem instruções para os casos em que a caixa
de diálogo Controle de Conta de Usuário é aberta para solicitar sua permissão
para continuar. Caso essa caixa de diálogo seja aberta durante a execução dos
procedimentos deste guia e em resposta às suas ações, clique em Continuar.
Instalar o servidor Web WEB1
A função servidor Web (IIS) no Windows Server 2016 fornece uma plataforma segura,
fácil de gerenciar, modular e extensível para hospedar sites, serviços e aplicativos de
forma confiável. Com o IIS, você pode compartilhar informações com usuários na
Internet, em uma intranet ou em uma extranet. O IIS é uma plataforma Web unificada
que integra IIS, ASP.NET, serviços FTP, PHP e WCF (Windows Communication
Foundation).
Quando você implanta certificados de servidor, seu servidor Web fornece um local em
que você pode publicar a CRL (lista de certificados revogados) para sua AC (autoridade
de certificação). Após a publicação, a CRL fica acessível a todos os computadores em
sua rede para que eles possam usar essa lista durante o processo de autenticação para
verificar se os certificados apresentados por outros computadores não são revogados.
Se um certificado estiver na CRL como revogado, o esforço de autenticação falhará e

seu computador será protegido contra confiar em uma entidade que tenha um
certificado que não seja mais válido.
Antes de instalar a função servidor Web (IIS), verifique se você configurou o nome do
servidor e o endereço IP e ingressou o computador no domínio.
Para instalar a função de servidor Servidor Web

(IIS)
７ Observação
Para executar esse procedimento usando o Windows PowerShell, abra o

PowerShell, digite o comando a seguir e pressione ENTER.
Web-Server -IncludeManagementTools

Nota A página Antes de Começar do Assistente para Adicionar Funções e Recursos não
será exibida se você já tiver executado o Assistente para Adicionar Funções e Recursos e
tiver selecionado Ignorar esta página por padrão nesse momento.
3. Na página Tipo de Instalação, clique em Avançar.

4. Na página Seleção de servidor , clique em Próximo.
5. Na página Funções de servidor , selecione Servidor Web (IIS) e clique em
Próximo.
6. Clique em Avançar até ter aceitado todas as configurações padrão do servidor
Web e clique em Instalar.
7. Confirme se todas as instalações tiveram êxito e clique em Fechar.
Criar um registro de alias (CNAME) em
DNS para WEB1
Você pode usar esse procedimento para adicionar um registro de recurso CNAME
(nome canônico do Alias) para seu servidor Web a uma zona no DNS no controlador de
domínio. Com registros CNAME, você pode usar mais de um nome para apontar para
um único host, facilitando a realização de coisas como hospedar um servidor FTP
(Protocolo de Transferência de Arquivo) e um servidor Web no mesmo computador.
Por isso, você é livre para usar seu servidor Web para hospedar a CRL (lista de
revogação de certificados) para sua AC (autoridade de certificação), bem como para
executar serviços adicionais, como FTP ou servidor Web.
Ao executar esse procedimento, substitua o nome do Alias e outras variáveis por

valores apropriados para sua implantação.
Para executar esse procedimento, você deve ser membro dos Administradores de
Domínio.
Para adicionar um registro de recurso CNAME

(alias) a uma zona
７ Observação
Para executar esse procedimento usando Windows PowerShell, consulte Add-

DnsServerResourceRecordCName.
1. No DC1, em Gerenciador do Servidor, clique em Ferramentas e clique em DNS. O

MMC (Console de Gerenciamento da Microsoft) do Gerenciador DNS é aberto.
2. Na árvore de console, clique duas vezes em Encaminhar Zonas de Pesquisa, clique

com o botão direito do mouse na zona de pesquisa para frente, na qual você
deseja adicionar o registro de recurso do Alias e clique em Novo Alias (CNAME)..
A caixa de diálogo Novo Registro de Recurso é aberta.
3. No nome do Alias, digite o nome do alias pki.

4. Quando você digita um valor para o nome do Alias, o FQDN (nome de domínio
totalmente qualificado) preenche automaticamente na caixa de diálogo. Por
exemplo, se o nome do alias for "pki" e seu domínio estiver corp.contoso.com, o
valor pki.corp.contoso.com será preenchido automaticamente para você.
5. Em FQDN (nome de domínio totalmente qualificado) para host de destino,

digite o FQDN do servidor Web. Por exemplo, se o servidor Web for chamado
WEB1 e seu domínio estiver corp.contoso.com, digite WEB1.corp.contoso.com.
6. Clique em OK para adicionar o novo registro à zona.

Configurar o WEB1 para distribuir listas
de certificados revogados (CRLs)
Você pode usar este procedimento para configurar o servidor Web WEB1 para distribuir
CRLs.
Nas extensões da CA raiz, foi mencionado que a CRL da CA raiz estaria disponível via
https://pki.corp.contoso.com/pki . Atualmente, não há um diretório virtual PKI em
WEB1, portanto, é necessário criá-lo.
Para executar esse procedimento, você deve ser membro de Admins. do domínio.
７ Observação
No procedimento abaixo, substitua o nome da conta de usuário, o nome do

servidor Web, os nomes de pasta e os locais e outros valores que são apropriados
para sua implantação.
Para configurar o WEB1 para distribuir certificados e CRLs

1. em WEB1, execute Windows PowerShell como administrador, digite explorer c:\
e pressione ENTER. o Windows Explorer é aberto para a unidade C.
2. Crie uma nova pasta chamada PKI na unidade C:. Para fazer isso, clique em inícioe,
em seguida, clique em nova pasta. Uma nova pasta é criada com o nome
temporário realçado. Digite PKI e pressione Enter.
3. no Windows Explorer, clique com o botão direito do mouse na pasta que você
acabou de criar, passe o cursor do mouse sobre compartilhar come clique em
pessoas específicas. A caixa de diálogo Compartilhamento de Arquivos será
aberta.
4. Em compartilhamento de arquivos, digite editores de certificadoe clique em

Adicionar. O grupo Publicadores de certificados é adicionado à lista. Na lista, em
nível de permissão, clique na seta ao lado de editores de certificadoe, em
seguida, clique em leitura/gravação. Clique em compartilhare, em seguida, clique
em concluído.
5. Feche o Windows Explorer.
6. Abra o console do IIS. No Gerenciador do Servidor, clique em Ferramentas e

depois em Gerenciador de Serviços de Informações da Internet (IIS).
7. na árvore de console do gerenciador do Serviços de Informações da Internet (IIS),

expanda WEB1. Se for convidado a começar a usar o Microsoft Web Platform,
clique em Cancelar.
8. Expanda Sites, clique com o botão direito do mouse no Default Web Site e clique
em Adicionar Diretório Virtual.
9. Em alias, digite PKI. Em caminho físico , digite C:\pkie clique em OK.
10. Habilite o acesso anônimo ao diretório virtual PKI, para que qualquer cliente possa
verificar a validade dos certificados e das CRLs da AC. Para fazer isso:
a. No painel Conexões, verifique se pki está selecionado.
b. Na Página Inicial da pki clique em Autenticação.
c. No painel Ações, clique em Editar Permissões.
d. Na guia Segurança, clique em Editar.
e. Na caixa de diálogo Permissões para pki, clique em Adicionar.
f. Em Selecionar usuários, computadores, contas de serviço ou grupos, digite

logon anônimo; Todos e, em seguida, clique em verificar nomes. Clique em OK.
g. Clique em OK na caixa de diálogo Selecionar usuários, computadores, contas

de serviço ou grupos .
h. Clique em OK na caixa de diálogo permissões para PKI .
11. Clique em OK na caixa de diálogo Propriedades PKI .
12. No painel Página Inicial da pki, clique duas vezes em Filtragem de Solicitações.
13. A guia Extensões de Nome de Arquivo é selecionada por padrão no painel

Filtragem de Solicitações. No painel Ações, clique em Editar Configurações de
Recurso.
14. Em Editar Configurações de Filtragem de Solicitações, selecione Permitir saída

dupla e clique em OK.
15. no MMC do gerenciador de Serviços de Informações da Internet (IIS), clique no
nome do servidor Web. Por exemplo, se o servidor Web for denominado WEB1,
clique em WEB1.
16. Em ações, clique em reiniciar. Os serviços de Internet são interrompidos e

reiniciados.
Sintaxe CAPolicy.inf
Aplica-se a: Windows Server 2016
O CAPolicy.inf é um arquivo de configuração que define as extensões, restrições e

outras configurações que são aplicadas a um certificado de autoridade de certificação
raiz e a todos os certificados emitidos pela AC raiz. O arquivo CAPolicy.inf deve ser
instalado em um servidor host antes que a rotina de instalação da AC raiz comece.
Quando as restrições de segurança em uma AC raiz devem ser modificadas, o
certificado raiz deve ser renovado e um arquivo CAPolicy.inf atualizado deve ser
instalado no servidor antes que o processo de renovação comece.
O CAPolicy.inf é:
Criado e definido manualmente por um administrador
Utilizados durante a criação de certificados de AC raiz e subordinados
Definido na AC de assinatura em que você assina e emite o certificado (não a AC

em que a solicitação é concedida)
Depois de criar o arquivo CAPolicy.inf, você deve copiá-lo para a pasta %systemroot%
do servidor antes de instalar o ADCS ou renovar o certificado de AUTORIDADE.
O CAPolicy.inf possibilita especificar e configurar uma ampla variedade de atributos e

opções de AC. A seção a seguir descreve todas as opções para você criar um arquivo .inf
adaptado às suas necessidades específicas.
Estrutura de arquivos CAPolicy.inf

Os seguintes termos são usados para descrever a estrutura de arquivos .inf:
Seção – é uma área do arquivo que abrange um grupo lógico de chaves. Os nomes
de seção em arquivos .inf são identificados aparecendo entre colchetes. Muitas,
mas não todas, seções são usadas para configurar extensões de certificado.
Chave – é o nome de uma entrada e aparece à esquerda do sinal de igual.
Valor – é o parâmetro e aparece à direita do sinal de igual.
No exemplo abaixo, [Versão] é a seção, Assinatura é a chave e "$Windows NT$" é o

valor.
Exemplo:
[Version]
Versão
Identifica o arquivo como um arquivo .inf. A versão é a única seção necessária e deve
estar no início do arquivo CAPolicy.inf.
PolicyStatementExtension
Lista as políticas que foram definidas pela organização e se elas são opcionais ou
obrigatórias. Várias políticas são separadas por vírgulas. Os nomes têm significado no
contexto de uma implantação específica ou em relação a aplicativos personalizados que
verificam a presença dessas políticas.
Para cada política definida, deve haver uma seção que defina as configurações dessa
política específica. Para cada política, você precisa fornecer um OID (identificador de
objeto definido pelo usuário) e o texto desejado exibido como a instrução de política ou
um ponteiro de URL para a instrução de política. A URL pode estar na forma de uma
URL HTTP, FTP ou LDAP.
Se você tiver um texto descritivo na instrução de política, as próximas três linhas do

CAPolicy.inf serão semelhantes:
[InternalPolicy]
OID=1.1.1.1.1.1.1
Notice="Legal policy statement text"
Se você usar uma URL para hospedar a instrução de política de AC, as próximas três
linhas serão semelhantes a:
[InternalPolicy]
OID=1.1.1.1.1.1.2
URL=https://pki.wingtiptoys.com/policies/legalpolicy.asp
Além disso:
Há suporte para várias chaves de URL e aviso.
Há suporte para chaves de aviso e URL na mesma seção de política.
URLs com espaços ou texto com espaços devem ser cercadas por aspas. Isso é
verdadeiro para a chave de URL , independentemente da seção na qual ela
aparece.
Um exemplo de vários avisos e URLs em uma seção de política seria semelhante a:
[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
Você pode especificar OS CDPs (Pontos de Distribuição de CRL) para um certificado de
AC raiz no CAPolicy.inf. Depois de instalar a AC, você pode configurar as URLs de CDP
que a AC inclui em cada certificado emitido. O certificado de AC raiz mostra as URLs
especificadas nesta seção do arquivo CAPolicy.inf.
[CRLDistributionPoint]
URL=http://pki.wingtiptoys.com/cdp/WingtipToysRootCA.crl
Algumas informações adicionais sobre esta seção:
Oferece suporte a:
HTTP
URLs de arquivo
LDAP URLs
Várias URLs
） Importante
Não dá suporte a URLs HTTPS.

As aspas devem cercar URLs com espaços.
Se nenhuma URL for especificada , ou seja, se a seção [CRLDistributionPoint]

existir no arquivo, mas estiver vazia, a extensão do Ponto de Distribuição crl será
omitida do certificado de AUTORIDADE raiz. Geralmente, isso é preferível ao
configurar uma AC raiz. Windows não executa verificação de revogação em um
certificado de autoridade de certificação raiz, portanto, a extensão CDP é
supérférica em um certificado de AC raiz.
A AC pode publicar no FILE UNC, por exemplo, em um compartilhamento que

representa a pasta de um site em que um cliente recupera via HTTP.
Use esta seção somente se você estiver configurando uma AC raiz ou renovando o
certificado de autoridade de certificação raiz. A AC determina as extensões cdp de
AC subordinadas.
AuthorityInformationAccess
Você pode especificar os pontos de acesso de informações de autoridade no
CAPolicy.inf para o certificado de autoridade de certificação raiz.
[AuthorityInformationAccess]
URL=http://pki.wingtiptoys.com/Public/myCA.crt
Algumas notas adicionais sobre a seção de acesso a informações da autoridade:
Há suporte para várias URLs.
Há suporte para URLs HTTP, FTP, LDAP e FILE. Não há suporte para URLs HTTPS.
Esta seção só será usada se você estiver configurando uma AC raiz ou renovando o
certificado de autoridade de certificação raiz. As extensões subordinadas da AC
AIA são determinadas pela AC que emitiu o certificado da AC subordinada.
AS URLs com espaços devem ser cercadas por aspas.
Se nenhuma URL for especificada , ou seja, se a seção

[AuthorityInformationAccess] existir no arquivo, mas estiver vazia, a extensão
acesso de informações da autoridade será omitida do certificado de AUTORIDADE
raiz. Novamente, essa seria a configuração preferencial no caso de um certificado
de AC raiz, pois não há autoridade superior a uma AC raiz que precisaria ser
referenciada por um link para seu certificado.
certsrv_Server
Outra seção opcional do CAPolicy.inf é [certsrv_server], que é usada para especificar o
comprimento da chave de renovação, o período de validade de renovação e o período
de validade da CRL (lista de revogação de certificado) para uma AC que está sendo
renovada ou instalada. Nenhuma das chaves nesta seção é necessária. Muitas dessas
configurações têm valores padrão suficientes para a maioria das necessidades e podem
simplesmente ser omitidos do arquivo CAPolicy.inf. Como alternativa, muitas dessas
configurações podem ser alteradas após a instalação da AC.
Um exemplo seria semelhante a:
[certsrv_server]
CRLPeriod=Days
CRLPeriodUnits=2
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=4
ClockSkewMinutes=20
LoadDefaultTemplates=True
ForceUTF8=0
EnableKeyCounting=0
RenewalKeyLength define o tamanho da chave somente para renovação. Isso só é

usado quando um novo par de chaves é gerado durante a renovação do certificado de
autoridade de certificação. O tamanho da chave para o certificado de autoridade de
certificação inicial é definido quando a AC é instalada.
Ao renovar um certificado de autoridade de certificação com um novo par de chaves, o

comprimento da chave pode ser aumentado ou reduzido. Por exemplo, se você tiver
definido um tamanho raiz de chave de AC de 4096 bytes ou superior e descobrir que
você tem aplicativos Java ou dispositivos de rede que só podem dar suporte a
tamanhos de chave de 2048 bytes. Se você aumentar ou diminuir o tamanho, deverá
reemitir todos os certificados emitidos por essa AC.
RenewalValidityPeriod e RenewalValidityPeriodUnits estabelecem o tempo de vida do

novo certificado de AC raiz ao renovar o certificado de AC raiz antigo. Ela só se aplica a
uma AC raiz. O tempo de vida do certificado de uma AC subordinada é determinado por
seu superior. RenewalValidityPeriod pode ter os seguintes valores: Horas, Dias, Semanas,
Meses e Anos.
CRLPeriod e CRLPeriodUnits estabelecem o período de validade para a CRL base. O
CRLPeriod pode ter os seguintes valores: Horas, Dias, Semanas, Meses e Anos.
CRLDeltaPeriod e CRLDeltaPeriodUnits estabelecem o período de validade da CRL

delta. CRLDeltaPeriod pode ter os seguintes valores: Horas, Dias, Semanas, Meses e
Anos.
Cada uma dessas configurações pode ser configurada após a instalação da AC:
Certutil -setreg CACRLPeriod Weeks
Certutil -setreg CACRLPeriodUnits 1
Certutil -setreg CACRLDeltaPeriod Days
Certutil -setreg CACRLDeltaPeriodUnits 1
Lembre-se de reiniciar os Serviços de Certificados do Active Directory para que as

alterações entrem em vigor.
LoadDefaultTemplates só se aplica durante a instalação de uma AC Enterprise. Essa

configuração, True ou False (ou 1 ou 0), determina se a AC está configurada com
qualquer um dos modelos padrão.
Em uma instalação padrão da AC, um subconjunto dos modelos de certificado padrão é

adicionado à pasta Modelos de Certificado no snap-in autoridade de certificação. Isso
significa que, assim que o serviço do AD CS for iniciado após a instalação da função, um
usuário ou computador com permissões suficientes poderá se registrar imediatamente
para um certificado.
Talvez você não deseje emitir certificados imediatamente após a instalação de uma AC,
portanto, você pode usar a configuração LoadDefaultTemplates para impedir que os
modelos padrão sejam adicionados à AC Enterprise. Se não houver modelos
configurados na AC, ele não poderá emitir certificados.
AlternateSignatureAlgorithm configura a AC para dar suporte ao formato de assinatura

PKCS nº 1 V2.1 para as solicitações de certificado e certificado de AUTORIDADE. Quando
definido como 1 em uma AC raiz, o certificado de AC incluirá o formato de assinatura
PKCS nº 1 V2.1. Quando definido em uma AC subordinada, a AC subordinada criará uma
solicitação de certificado que inclui o formato de assinatura PKCS nº 1 V2.1.
ForceUTF8 altera a codificação padrão de RDNs (nomes distintos relativos) em nomes

diferenciados de Assunto e Emissor para UTF-8. Somente os RDNs que dão suporte a
UTF-8, como aqueles definidos como tipos de cadeia de caracteres de diretório por um
RFC, são afetados. Por exemplo, o RDN para DC (Componente de Domínio) dá suporte à
codificação como IA5 ou UTF-8, enquanto o RDN do país (C) dá suporte apenas à
codificação como uma cadeia de caracteres imprimível. A diretiva ForceUTF8 afetará,
portanto, um RDN DC, mas não afetará um RDN C.
EnableKeyCounting configura a AC para incrementar um contador sempre que a chave

de assinatura da AC é usada. Não habilite essa configuração, a menos que você tenha
um HSM (Módulo de Segurança de Hardware) e um CSP (provedor de serviço
criptográfico) associado que dê suporte à contagem de chaves. Nem o CSP forte da
Microsoft nem o Provedor de Armazenamento de Chave de Software da Microsoft (KSP)
dão suporte à contagem de chaves.
Criar o arquivo CAPolicy.inf

Antes de instalar o AD CS, configure o arquivo CAPolicy.inf com configurações
específicas para sua implantação.
Pré-requisito: Você deve ser membro do grupo Administradores.
1. No computador em que você planeja instalar o AD CS, abra Windows PowerShell,

digite o bloco de notas c:\CAPolicy.inf e pressione ENTER.
2. Quando ele perguntar se você deseja criar um novo arquivo, clique em Sim.
3. Insira o seguinte como o conteúdo do arquivo:
[Version]
[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]
CRLPeriod=weeks
CRLPeriodUnits=1
LoadDefaultTemplates=0
[CRLDistributionPoint]
[AuthorityInformationAccess]
4. Clique em Arquivo e clique em Salvar como.

5. Navegue até a pasta %systemroot%.
6. Verifique o seguinte:
Nome do arquivo é definido como CAPolicy. inf
Salvar como tipo está definido como Todos os Arquivos
Codificação é ANSI
7. Clique em Salvar.
8. Quando o programa perguntar se você deseja substituir o arquivo, clique em Sim.
Ｕ Cuidado
Verifique se você salvou o CAPolicy.inf com a extensão inf. Se você não digitar
.inf especificamente no final do nome de arquivo e selecionar as opções
conforme descrito, o arquivo será salvo como um arquivo de texto e não será
usado durante a instalação da AC.
9. Feche o Bloco de notas.
） Importante
No CAPolicy.inf, você pode ver que há uma linha especificando a URL

https://pki.corp.contoso.com/pki/cps.txt . A seção Política Interna do
CAPolicy.inf é mostrada apenas como um exemplo de como você poderia
especificar o local de uma CPS (declaração de prática de certificação). Neste guia,
você não será instruído a criar a instrução de prática de certificado (CPS).
Instalar a autoridade de certificação
Você pode usar este procedimento para instalar Active Directory serviços de certificados
(AD CS) para que você possa registrar um certificado do servidor em servidores que
estejam executando o servidor de diretivas de rede (NPS), o serviço de roteamento e
acesso remoto (RRAS) ou ambos.
） Importante
Antes de instalar Active Directory serviços de certificados, você deve nomear

o computador, configurar o computador com um endereço IP estático e
ingressar o computador no domínio. para obter mais informações sobre
como realizar essas tarefas, consulte o guia de rede Windows Server 2016
Core.
Para executar este procedimento, o computador no qual você está instalando
o AD CS deve estar associado a um domínio no qual o AD DS (Serviços de
Domínio Active Directory) esteja instalado.
A associação aos grupos Administradores de Empresa e Admins. do Domínio do

domínio raiz é o mínimo exigido para executar este procedimento.
７ Observação
para executar esse procedimento usando Windows PowerShell, abra Windows

PowerShell e digite o comando a seguir e pressione ENTER.
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools
Após a instalação do AD CS, digite o comando a seguir e pressione ENTER.
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA
Para instalar os Serviços de Certificados do Active

Directory
 Dica
se você quiser usar Windows PowerShell para instalar Active Directory serviços de
certificados, consulte install-AdcsCertificationAuthority para obter cmdlets e
parâmetros opcionais.
1. Faça logon como membro do grupo Administradores de Empresa e do grupo

Admins. do Domínio do domínio raiz.

７ Observação



local está selecionado. Clique em Avançar.
6. Em selecionar funções de servidor, em funções, selecione Active Directory

serviços de certificados. Quando for solicitado a adicionar os recursos necessários,
clique em Adicionar recursose, em seguida, clique em Avançar.
7. Em selecionar recursos, clique em Avançar.
8. Em Active Directory serviços de certificados, leia as informações fornecidas e

clique em Avançar.
9. Em Confirmar seleções de instalação, clique em Instalar. Não feche o assistente

durante o processo de instalação. Quando a instalação for concluída, clique em
configurar Active Directory serviços de certificados no servidor de destino. O
assistente de configuração do AD CS é aberto. leia as informações de credenciais
e, se necessário, forneça as credenciais para uma conta que seja membro do grupo
Enterprise admins. Clique em Avançar.
10. Em serviços de função, clique em autoridade de certificaçãoe em Avançar.
11. na página tipo de instalação , verifique se Enterprise ac está selecionada e clique

em avançar.
12. Na página especificar o tipo da autoridade de certificação , verifique se AC raiz

está selecionada e clique em Avançar.
13. Na página especificar o tipo da chave privada , verifique se criar uma nova chave
privada está selecionado e clique em Avançar.
14. na página criptografia para CA , mantenha as configurações padrão para o CSP

(RSA # Microsoft Software Key Armazenamento Provider) e o algoritmo de hash
(SHA2) e determine o melhor comprimento de caractere de chave para sua
implantação. Comprimentos de caracteres de chave grandes fornecem segurança
ideal; no entanto, eles podem afetar o desempenho do servidor e podem não ser
compatíveis com os aplicativos herdados. É recomendável que você mantenha a
configuração padrão de 2048. Clique em Avançar.
15. Na página nome da autoridade de certificação , mantenha o nome comum

sugerido para a autoridade de certificação ou altere o nome de acordo com seus
requisitos. Verifique se você tem certeza de que o nome da autoridade de
certificação é compatível com suas convenções de nomenclatura e fins, porque
você não pode alterar o nome da autoridade de certificação depois de ter
instalado o AD CS. Clique em Avançar.
16. Na página período de validade , em especificar o período de validade, digite o

número e selecione um valor de hora (anos, meses, semanas ou dias). A
configuração padrão de cinco anos é recomendada. Clique em Avançar.
17. Na página banco de dados de CA , em especificar os locais do banco de dados,

especifique o local da pasta para o banco de dados do certificado e o log do
banco de dados do certificado Se você especificar localizações diferentes do
padrão, verifique se as pastas estão protegidas com ACLs (listas de controle de
acesso) que impedem que usuários ou computadores não autorizados acessem os
arquivos de log e o banco de dados da autoridade de certificação. Clique em
Avançar.
18. Em confirmação, clique em Configurar para aplicar suas seleções e, em seguida,

clique em Fechar.
Configurar as extensões CDP e AIA em
CA1
Você pode usar este procedimento para definir as configurações de CDP (Ponto de
Distribuição da CRL) e AIA (Acesso de Informações da Autoridade) na CA1.
Para executar este procedimento, você deve ser um membro de Administradores de

Domínio.
Para configurar as extensões CDP e AIA na CA1

1. No Gerenciador do Servidor, clique em Ferramentas e depois em Autoridade de
Certificação.
2. Na árvore de console da Autoridade de Certificação, clique com o botão direito do

mouse em corp-CA1-CA e clique em Propriedades.
７ Observação
O nome da ac é diferente se você não nomeou o computador CA1 e o nome

de domínio é diferente do deste exemplo. O nome da AC está no formato
domainCAComputerName-CA.
3. Clique na guia Extensões . Verifique se Selecionar extensão está definida como

CDP (Ponto de Distribuição de CRL) e, em Especificar locais dos quais os usuários
podem obter uma CRL (lista de certificados revogados), faça o seguinte:
a. Selecione a entrada file://\\<ServerDNSName>\CertEnroll\<CaName>

<CRLNameSuffix><DeltaCRLAllowed>.crl e clique em file://\\
<ServerDNSName>\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl . Em
Confirmar remoção, clique em Sim.
b. Selecione a entrada http://<ServerDNSName>/CertEnroll/<CaName>

<CRLNameSuffix><DeltaCRLAllowed>.crl e clique em
http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix>
<DeltaCRLAllowed>.crl . Em Confirmar remoção, clique em Sim.
c. Selecione a entrada que começa com o caminho ldap:///CN=<CATruncatedName>
<CRLNameSuffix>,CN=<ServerShortName> e clique em ldap:///CN=
<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName> . Em Confirmar
remoção, clique em Sim.
4. Em Especificar locais dos quais os usuários podem obter uma CRL (lista de
certificados revogados), clique em Adicionar. A caixa de diálogo Adicionar Local
é aberta.
5. Em Adicionar Local, em Local, digite e clique em OK. Isso retorna você para a caixa
de diálogo Propriedades da AC.
6. Na guia Extensões , marque as seguintes caixas de seleção:
Incluir nas CRLs. Os clientes usam isso para encontrar os locais da CRL
Delta
Incluir na extensão CDP de certificados emitidos
7. Em Especificar locais dos quais os usuários podem obter uma CRL (lista de
certificados revogados), clique em Adicionar. A caixa de diálogo Adicionar Local
é aberta.
9. Na guia Extensões , marque as seguintes caixas de seleção:
Publicar CRLs neste local
Publicar CRLs Delta nesse local
10. Alterar Selecione a extensão para Acesso a Informações da Autoridade (AIA) e, em

Especificar locais dos quais os usuários podem obter uma CRL (lista de
certificados revogados), faça o seguinte:
a. Selecione a entrada que começa com o caminho ldap:///CN=

<CATruncatedName>,CN=AIA,CN=Public Key Services e clique em ldap:///CN=
<CATruncatedName>,CN=AIA,CN=Public Key Services . Em Confirmar remoção,
clique em Sim.
b. Selecione a entrada
http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName>
<CertificateName>.crt e clique em
http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName>
<CertificateName>.crt . Em Confirmar remoção, clique em Sim.
c. Selecione a entrada file://\\<ServerDNSName>\CertEnroll\<ServerDNSName>

<CaName><CertificateName>.crt e clique em file://\\
<ServerDNSName>\CertEnroll\<ServerDNSName><CaName><CertificateName>.crt . Em
Confirmar remoção, clique em Sim.
11. Em Especificar locais dos quais os usuários podem obter o certificado para essa
AC, clique em Adicionar. A caixa de diálogo Adicionar Local é aberta.
13. Na guia Extensões , selecione Incluir no AIA de certificados emitidos.
14. Quando for solicitado que você reinicie Serviços de Certificados do Active
Directory, clique em Não. Você reiniciará o serviço mais tarde.
Copiar o certificado de autoridade de
certificação e a CRL para o Diretório
Virtual
Você pode usar esse procedimento para copiar a Lista de Revogação de Certificados e
Enterprise certificado de autoridade de certificação raiz de sua autoridade de
certificação para um diretório virtual em seu servidor Web e garantir que o AD CS esteja
configurado corretamente. Antes de executar os comandos abaixo, verifique se você
substitui os nomes de diretório e servidor pelos que são apropriados para sua
implantação.
Para executar esse procedimento, você deve ser membro dos Administradores de
Domínio.
Para copiar a lista de revogação de certificados de CA1 para WEB1
1. No CA1, execute Windows PowerShell como administrador e, em seguida,

publique a CRL com o seguinte comando:
Digite certutil -crl e pressione ENTER.
Para copiar o certificado CA1 para o compartilhamento de arquivos no

servidor Web, digite copy C:\Windows\system32\certsrv\certenroll\*.crt
\\WEB1\pki e pressione ENTER.
Para copiar as listas de revogação de certificado para o compartilhamento de

arquivos no servidor Web, digite copy
C:\Windows\system32\certsrv\certenroll\*.crl \\WEB1\pki e pressione
ENTER.
2. Para verificar se os locais de extensão CDP e AIA estão configurados corretamente,

digite pkiview.msc e pressione ENTER. O Pkiview Enterprise PKI MMC é aberto.
3. No painel esquerdo, clique no nome da AC.
Por exemplo, se o nome da AC for corp-CA1-CA, clique em corp-CA1-CA.

4. Na coluna Status do painel de resultados, verifique se os valores para o seguinte
mostram OK:
Certificado de Autoridade de Certificação

Local do AIA nº 1
Local do CDP nº 1
 Dica
Se o status de qualquer item não estiver OK, faça o seguinte:
Abra o compartilhamento em seu servidor Web para verificar se os arquivos

da lista de certificados e certificados revogados foram copiados com êxito
para o compartilhamento. Se eles não tiverem sido copiados com êxito para o
compartilhamento, modifique os comandos de cópia com a origem do
arquivo correta e compartilhe o destino e execute os comandos novamente.
Verifique se você inseriu os locais corretos para o CDP e o AIA na guia
Extensões de AC. Verifique se não há espaços extras ou outros caracteres nos
locais que você forneceu.
Verifique se você copiou o certificado crl e ac para o local correto em seu
servidor Web e se o local corresponde ao local que você forneceu para os
locais cdp e AIA na AC.
Verifique se você configurou corretamente as permissões para a pasta virtual
em que o certificado de autoridade de certificação e a CRL estão
armazenados.
Configurar o modelo de certificado do
servidor
Você pode usar este procedimento para configurar o modelo de certificado que o AD
CS (Serviços de Certificados do Active Directory®) usa como base para certificados de
servidor que estão inscritos em servidores em sua rede.
Ao configurar esse modelo, você pode especificar os servidores por grupo do Active
Directory que devem receber automaticamente um certificado do servidor AD CS.
O procedimento a seguir inclui instruções para configurar o modelo para emitir

certificados para todos os seguintes tipos de servidor:
Servidores que executam o serviço de Acesso Remoto, incluindo servidores de

Gateway RAS, que são membros do grupo de Servidores RAS e IAS .
Servidores que executam o serviço NPS (Servidor de Políticas de Rede) que são
membros do grupo de Servidores RAS e IAS .
A associação aos grupos Administradores de Empresa e Admins. do Domínio do

Para configurar o modelo de certificado

1. Em CA1, no Gerenciador do Servidor, clique em Ferramentase clique em
Autoridade de Certificação. A MMC (Autoridade Console de Gerenciamento
Microsoft de Certificação) é aberta.
2. No MMC, clique duas vezes no nome da AC, clique com o botão direito do mouse
em Modelos de Certificado e clique em Gerenciar.
3. O console modelos de certificado é aberto. Todos os modelos de certificado são

exibidos no painel de detalhes.
4. No painel de detalhes, clique no modelo RAS e servidor IAS .
5. Clique no menu Ação e clique em Duplicar Modelo. A caixa de diálogo

Propriedades do modelo é aberta.
6. Clique na guia Segurança .

7. Na guia Segurança , em Nomes de grupo ou de usuário, clique em SERVIDORES
RAS e IAS.
8. Em Permissões para servidores RAS e IAS, em Permitir, verifique se Registrar está

selecionado e marque a caixa de seleção Registro automático. Clique em OK e
feche o MMC de Modelos de Certificado.
9. No MMC da Autoridade de Certificação, clique em Modelos de Certificado. No

menu Ação , aponte para Novo e clique em Modelo de Certificado para Emitir. A
caixa de diálogo Ativar Modelos de Certificado é aberta.
10. Em Habilitar Modelos de Certificado, clique no nome do modelo de certificado

que você acabou de configurar e clique em OK. Por exemplo, se você não alterou o
nome do modelo de certificado padrão, clique em Copiar de RAS e Servidor IAS e
clique em OK.
Configurar o registro automático de
certificado
７ Observação
Antes de executar este procedimento, você deve configurar um modelo de

certificado de servidor usando o snap-in Console de Gerenciamento Microsoft para
Modelos de Certificado em uma autoridade de certificação que execute AD CS.
A
associação aos grupos Administradores de Empresa e Admins. do Domínio do
Configurar o registro automático de certificado

do servidor
1. No computador em que AD DS está instalado, abra Windows PowerShell ®, digite
mmc e pressione ENTER. O Console de Gerenciamento Microsoft será aberto.
2. No menu Arquivo , clique em Adicionar/Remover Snap-in. A caixa de diálogo

Adicionar ou Remover Snap-ins é aberta.
3. Em Snap-ins disponíveis, role para baixo e clique duas vezes Editor de

Gerenciamento de Política de Grupo. A caixa de diálogo Selecionar Política de
Grupo Objeto é aberta.
） Importante
Certifique-se de selecionar Editor de Gerenciamento de Política de Grupo e

não Política de Grupo Gerenciamento. Se você selecionar Política de Grupo
Gerenciamento, sua configuração usando essas instruções falhará e um
certificado do servidor não será automaticamente feito no NPSs.
4. Em Selecionar Objeto de Diretiva de Grupo, clique em Procurar. A caixa de

diálogo Procurar um Objeto de Diretiva de Grupo é aberta.
5. Em Domínios, OUs e Objetos de Diretiva de Grupo conectados, clique em
Diretiva de Domínio Padrão, e em OK.
6. Clique em Concluir e em OK.
7. Clique duas vezes em Diretiva de Domínio Padrão. No console do , expanda o

seguinte caminho: Configuração do Computador, Políticas, Windows
Configurações, Segurança Configurações e Políticas de Chave Pública.
8. Clique em Diretivas de Chave Pública. No painel de detalhes, clique duas vezes em

Cliente dos Serviços de Certificados - Inscrição Automática. A caixa de diálogo
Propriedades é aberta. Configure os seguintes itens e clique em OK:
a. Em Modelo de Configuração, selecione Habilitado.
b. Marque a caixa de seleção Renovar certificados expirados, atualizar
certificados pendentes e remover certificados revogados.
c. Marque a caixa de seleção Atualizar certificados que usam modelos de
certificados.
9. Clique em OK.
Configurar o registro automático de certificado

de usuário
1. No computador em que AD DS está instalado, abra Windows PowerShell ®, digite
mmc e pressione ENTER. O Console de Gerenciamento Microsoft será aberto.
2. No menu Arquivo , clique em Adicionar/Remover Snap-in. A caixa de diálogo

Adicionar ou Remover Snap-ins é aberta.
3. Em Snap-ins disponíveis, role para baixo e clique duas vezes Editor de

Gerenciamento de Política de Grupo. A caixa de diálogo Selecionar Política de
Grupo Objeto é aberta.
） Importante
Certifique-se de selecionar Editor de Gerenciamento de Política de Grupo e

não Política de Grupo Gerenciamento. Se você selecionar Política de Grupo
Gerenciamento, sua configuração usando essas instruções falhará e um
certificado do servidor não será automaticamente feito no NPSs.
4. Em Selecionar Objeto de Diretiva de Grupo, clique em Procurar. A caixa de

diálogo Procurar um Objeto de Diretiva de Grupo é aberta.
5. Em Domínios, OUs e Objetos de Diretiva de Grupo conectados, clique em
Diretiva de Domínio Padrão, e em OK.
6. Clique em Concluir e em OK.
7. Clique duas vezes em Diretiva de Domínio Padrão. No console do , expanda o

seguinte caminho: Configuração do Usuário, Políticas, Windows Configurações,
Segurança Configurações.
8. Clique em Diretivas de Chave Pública. No painel de detalhes, clique duas vezes em

Cliente dos Serviços de Certificados - Inscrição Automática. A caixa de diálogo
Propriedades é aberta. Configure os seguintes itens e clique em OK:
a. Em Modelo de Configuração, selecione Habilitado.
b. Marque a caixa de seleção Renovar certificados expirados, atualizar
certificados pendentes e remover certificados revogados.
c. Marque a caixa de seleção Atualizar certificados que usam modelos de
certificados.
9. Clique em OK.
Próximas etapas
Atualizar Política de Grupo
Atualizar Diretiva de Grupo
Você pode usar este procedimento para atualizar manualmente a Diretiva de Grupo no
computador local. Quando a Diretiva de Grupo é atualizada, se o registro automático de
certificados estiver configurado e funcionando corretamente, o computador local terá o
registro automático de um certificado pela autoridade de certificação (CA).
７ Observação
A Diretiva de Grupo é atualizada automaticamente quando você reinicia ou um

usuário faz logon em um computador membro do domínio. Além disso, a Diretiva
de Grupo é atualizada periodicamente. Por padrão, essa atualização periódica é
realizada a cada 90 minutos com uma diferença de horário aleatória de até 30
minutos.
A associação a administradores ou equivalentes é o mínimo necessário para concluir

este procedimento.
Para atualizar a Diretiva de Grupo no

computador local
1. No computador em que o NPS (Servidor de Política de Rede) está instalado, abra o
PowerShell usando o ícone na barra de tarefas.
2. No prompt do PowerShell, digite gpupdate e pressione Enter .

Verificar registro de servidor de um
Você pode usar este procedimento para verificar se os servidores do servidor de

diretivas de rede (NPS) registraram um certificado de servidor da autoridade de
certificação (CA).
７ Observação
A associação no grupo Admins . do domínio é o mínimo necessário para concluir

esses procedimentos.
Verificar o registro do servidor de políticas de

rede (NPS) de um certificado do servidor
Como o NPS é usado para autenticar e autorizar solicitações de conexão de rede, é
importante garantir que o certificado do servidor emitido para NPSs seja válido quando
usado em políticas de rede.
Para verificar se um certificado de servidor está configurado corretamente e registrado

no NPS, você deve configurar uma política de rede de teste e permitir que o NPS
Verifique se o NPS pode usar o certificado para autenticação.
Para verificar o registro de NPS de um certificado de

servidor
1. No Gerenciador do Servidor, clique em Ferramentase, em seguida, clique em
Servidor de Políticas de Rede. O console de gerenciamento Microsoft (MMC) do
servidor de diretivas de rede é aberto.
2. Clique duas vezes em políticas, clique com o botão direito do mouse em políticas
de redee clique em novo. O assistente Nova Diretiva de Rede é exibido.
3. Em especificar nome da política de rede e tipo de conexão, em nome da política,

digite política de teste. Verifique se o tipo de servidor de acesso à rede tem o
valor não especificadoe clique em Avançar.
4. Em especificar condições, clique em Adicionar. em selecionar condição, clique em

Windows grupose, em seguida, clique em adicionar.
5. Em grupos, clique em Adicionar grupos. Em selecionar grupo, digite usuários do

domínioe pressione Enter. Clique em OK e em Avançar.
6. Em especificar permissão de acesso, verifique se acesso concedido está

selecionado e clique em Avançar.
7. Em Configurar métodos de autenticação, clique em Adicionar. Em Adicionar EAP,

clique em Microsoft: EAP protegido (PEAP)e clique em OK. Em tipos de EAP,
selecione Microsoft: EAP protegido (PEAP)e clique em Editar. A caixa de diálogo
Editar propriedades EAP protegidas é aberta.
8. Na caixa de diálogo Editar propriedades EAP protegidas , em certificado emitido

para, o NPS exibe o nome do certificado do servidor no formato ComputerName.
Domínio. Por exemplo, se o seu NPS for chamado de NPS-01 e seu domínio for
example.com, o NPS exibirá o certificado NPS-01.example.com. Além disso, no
emissor, o nome da autoridade de certificação é exibido e, na data de expiração, a
data de expiração do certificado do servidor é mostrada. Isso demonstra que o
NPS registrou um certificado de servidor válido que pode ser usado para provar
sua identidade para os computadores cliente que estão tentando acessar a rede
por meio de seus servidores de acesso à rede, como servidores de rede virtual
privada (VPN), pontos de acesso sem fio compatíveis com 802.1 X, servidores de
gateway Área de Trabalho Remota e comutadores Ethernet compatíveis com 802.1
X.
） Importante
Se o NPS não exibir um certificado de servidor válido e se ele fornecer a

mensagem de que esse certificado não pode ser encontrado no computador
local, haverá duas razões possíveis para esse problema. É possível que Política
de Grupo não tenha sido atualizada corretamente, e o NPS não registrou um
certificado da autoridade de certificação. Nessa circunstância, reinicie o NPS.
Quando o computador for reiniciado, Política de Grupo será atualizado e você
poderá executar esse procedimento novamente para verificar se o certificado
do servidor está registrado. Se a atualização Política de Grupo não resolver
esse problema, o modelo de certificado, o registro automático de certificado
ou ambos não estão configurados corretamente. Para resolver esses
problemas, comece no início deste guia e execute todas as etapas novamente
para garantir que as configurações fornecidas sejam precisas.
9. Depois de verificar a presença de um certificado de servidor válido, você pode

clicar em OK e em Cancelar para sair do assistente de nova política de rede.
７ Observação
Como você não está concluindo o assistente, a política de rede de teste não é
criada no NPS.
Implantar acesso sem fio autenticado
802.1X baseado em senha
Este é um guia complementar para o Guia de Rede Principal do Windows Server® 2016.
O Guia de Rede Principal fornece instruções para planejar e implantar os componentes
necessários para uma rede totalmente funcional e um novo domínio do Active
Directory® em uma nova floresta.
Este guia explica como desenvolver uma rede principal e fornece instruções sobre como
implantar o acesso sem fio IEEE 802.11 com autenticação 802.1 X do Instituto de
Engenheiros Eletricistas e Eletrônicos usando o Protocolo de Autenticação Extensível
Protegido – Microsoft Challenge Handshake Authentication Protocol versão 2 (PEAP-
MS-CHAP v2).
Como o PEAP-MS-CHAP v2 exige que os usuários forneçam credenciais baseadas em

senha em vez de um certificado durante o processo de autenticação, normalmente é
mais fácil e menos caro implantar do que EAP-TLS ou PEAP-TLS.
７ Observação
Neste guia, o Acesso Sem Fio Autenticado IEEE 802.1X com PEAP-MS-CHAP v2 é
abreviado para "acesso sem fio" e "acesso WiFi".
Sobre este guia

Este guia, em combinação com os guias de pré-requisito descritos abaixo, fornece
instruções sobre como implantar a seguinte infraestrutura de acesso WiFi.
Um ou mais pontos de acesso sem fio 802.11 com capacidade para 802.11 (APs).
Active Directory Domain Services (AD DS) usuários e computadores.
Gerenciamento de Política de Grupo.
Um ou mais servidores NPS (Servidor de Política de Rede).
Certificados de servidor para computadores que executam o NPS.

Computadores cliente sem fio que executam o Windows® 10, Windows 8.1 ou
Windows 8.
Dependências deste guia

Para implantar sem fio autenticado com êxito com este guia, você deve ter um ambiente
de rede e domínio com todas as tecnologias necessárias implantadas. Você também
deve ter certificados de servidor implantados em seus NPSs de autenticação.
As seções a seguir fornecem links para a documentação que mostra como implantar
essas tecnologias.
Dependências de ambiente de rede e domínio

Este guia foi projetado para administradores de rede e sistema que seguiram as
instruções no Guia de Rede do Windows Server 2016 Core para implantar uma rede
principal ou para aqueles que já implantaram as principais tecnologias incluídas na rede
principal, incluindo AD DS, DNS (Sistema de Nomes de Domínio), DHCP (Protocolo de
Configuração de Host Dinâmico), TCP/IP, NPS e WINS (Serviço de Nome de Internet do
Windows).
O Windows Server 2016 Core Network Guide está disponível na Biblioteca Técnica
Dependências de certificado do servidor
Há duas opções disponíveis para registrar servidores de autenticação com certificados

de servidor para uso com autenticação 802.1X – implantar sua própria infraestrutura de
chave pública usando o AD CS (Active Directory Certificate Services) ou usar certificados
de servidor registrados por uma AC (autoridade de certificação pública).
AD CS
Os administradores de rede e sistema que implantam o wireless autenticado devem

seguir as instruções no guia complementar de rede Windows Server 2016 Core,
implantar certificados de servidor para implantações com fio e sem fio 802.1X. Este
guia explica como implantar e usar o AD CS para registrar automaticamente certificados
de servidor em computadores que executam o NPS.
Este guia está disponível no local a seguir.

O guia complementar de rede Windows Server 2016 principal implanta certificados
de servidor para implantações com fio e sem fio 802.1X no formato HTML na
Biblioteca Técnica.
CA Pública
Você pode comprar certificados de servidor de uma AC pública, como VeriSign, em que
os computadores cliente já confiam.
Um computador cliente confia em uma AC quando o certificado de autoridade de

certificação é instalado no repositório de certificados autoridades de certificação raiz
confiáveis. Por padrão, os computadores que executam o Windows têm vários
certificados públicos de AUTORIDADE de Certificação instalados no repositório de
certificados autoridades de certificação raiz confiáveis.
É recomendável que você examine os guias de design e implantação de cada uma das
tecnologias usadas neste cenário de implantação. Esses guias podem ajudar a
determinar se o cenário de implantação fornece os serviços e as configurações que você
precisa para a rede de sua organização.
Requisitos
A seguir estão os requisitos para implantar uma infraestrutura de acesso sem fio usando
o cenário documentado neste guia:
Antes de implantar esse cenário, primeiro você deve comprar pontos de acesso
sem fio compatíveis com 802,1X para fornecer cobertura sem fio nos locais
desejados em seu site. A seção de planejamento deste guia ajuda a determinar os
recursos aos quais seus APs devem dar suporte.
Active Directory Domain Services (AD DS) está instalado, assim como as outras
tecnologias de rede necessárias, de acordo com as instruções no Guia de Rede do
Windows Server 2016 Core.
O AD CS é implantado e os certificados de servidor são registrados em NPSs. Esses

certificados são necessários quando você implanta o método de autenticação
baseada em certificado PEAP-MS-CHAP v2 usado neste guia.
Um membro da sua organização está familiarizado com os padrões do IEEE 802.11

compatíveis com seus APs sem fio e os adaptadores de rede sem fio instalados nos
computadores e dispositivos cliente em sua rede. Por exemplo, alguém em sua
organização está familiarizado com tipos de radiofrequência, autenticação sem fio
802.11 (WPA2 ou WPA) e criptografias (AES ou TKIP).
A seguir estão alguns itens que este guia não fornece:
Diretrizes abrangentes para selecionar pontos de acesso

sem fio compatíveis com 802.1X
Como existem muitas diferenças entre marcas e modelos de APs sem fio compatíveis
com 802.1X, este guia não fornece informações detalhadas sobre:
Determinar qual marca ou modelo de AP sem fio é mais adequado às suas

necessidades.
A implantação física de APs sem fio em sua rede.
Configuração avançada de AP sem fio, como para VLANs (Redes de Área Local)
virtuais sem fio.
Instruções sobre como configurar atributos específicos do fornecedor de AP sem

fio no NPS.
Além disso, a terminologia e os nomes das configurações variam entre marcas e

modelos de AP sem fio e podem não corresponder aos nomes de configuração
genéricos usados neste guia. Para obter detalhes de configuração de AP sem fio, você
deve examinar a documentação do produto fornecida pelo fabricante de seus APs sem
fio.
Instruções para implantar certificados NPS

Há duas alternativas para implantar certificados NPS. Este guia não fornece diretrizes
abrangentes para ajudá-lo a determinar qual alternativa atenderá melhor às suas
necessidades. Em geral, no entanto, as escolhas que você enfrenta são:
Comprar certificados de uma AC pública, como o VeriSign, que já são confiáveis

por clientes baseados no Windows. Normalmente, essa opção é recomendada
para redes menores.
Implantando uma PKI (infraestrutura de chave pública) em sua rede usando o AD

CS. Isso é recomendado para a maioria das redes e as instruções de como
implantar certificados de servidor com o AD CS estão disponíveis no guia de
implantação mencionado anteriormente.
Políticas de rede NPS e outras configurações de NPS
Exceto pelas configurações feitas quando você executa o assistente Configurar 802.1X ,
conforme documentado neste guia, este guia não fornece informações detalhadas para
definir manualmente condições, restrições ou outras configurações de NPS.
DHCP
Este guia de implantação não fornece informações sobre como projetar ou implantar
sub-redes DHCP para LANs sem fio.

Veja a seguir as visões gerais de tecnologia para implantar o acesso sem fio:
IEEE 802.1X
O padrão IEEE 802.1X define o controle de acesso à rede baseado em porta usado para
fornecer acesso de rede autenticado às redes Ethernet. Esse controle de acesso à rede
baseado em porta usa as características físicas da infraestrutura de LAN comutada para
autenticar dispositivos anexados a uma porta LAN. O acesso à porta pode ser negado se
o processo de autenticação falhar. Embora esse padrão tenha sido projetado para redes
Ethernet com fio, ele foi adaptado para uso em LANs sem fio 802.11.
Pontos de acesso sem fio com capacidade para 802.1X

(APs)
Esse cenário requer a implantação de um ou mais APs sem fio compatíveis com 802.1X
compatíveis com o protocolo RADIUS (Serviço de Usuário Discado de Autenticação
Remota).
802.1X e APs compatíveis com RADIUS, quando implantados em uma infraestrutura

RADIUS com um servidor RADIUS, como um NPS, são chamados de clientes RADIUS.
Clientes sem fio

Este guia fornece detalhes de configuração abrangentes para fornecer acesso
autenticado 802.1X para usuários membros do domínio que se conectam à rede com
computadores cliente sem fio executando Windows 10, Windows 8.1 e Windows 8. Os
computadores devem ser ingressados no domínio para estabelecer com êxito o acesso
autenticado.
７ Observação
Você também pode usar computadores que estão executando Windows Server
2016, Windows Server 2012 R2 e Windows Server 2012 como clientes sem fio.
Suporte para padrões IEEE 802.11

Os sistemas operacionais Windows e Windows Server com suporte fornecem suporte
interno para rede sem fio 802.11. Nesses sistemas operacionais, um adaptador de rede
sem fio 802.11 instalado aparece como uma conexão de rede sem fio no Centro de
Rede e Compartilhamento.
Embora haja suporte interno para rede sem fio 802.11, os componentes sem fio do
Windows dependem do seguinte:
Os recursos do adaptador de rede sem fio. O adaptador de rede sem fio instalado
deve dar suporte à LAN sem fio ou aos padrões de segurança sem fio necessários.
Por exemplo, se o adaptador de rede sem fio não der suporte a Wi-Fi WPA (Acesso
Protegido), você não poderá habilitar ou configurar opções de segurança do WPA.
Os recursos do driver do adaptador de rede sem fio. Para permitir que você
configure opções de rede sem fio, o driver do adaptador de rede sem fio deve dar
suporte ao relatório de todos os seus recursos para o Windows. Verifique se o
driver do adaptador de rede sem fio foi gravado para os recursos do sistema
operacional. Verifique também se o driver é a versão mais atual verificando o
Microsoft Update ou o site do fornecedor do adaptador de rede sem fio.
A tabela a seguir mostra as taxas de transmissão e as frequências para padrões comuns

sem fio IEEE 802.11.
Padrões Freqüências Taxas de Uso

transmissão
de bits
802.11 Intervalo de 2 megabits Obsoleto. Não é comumente usado.

frequência industrial, por segundo
científica e médica (Mbps)
(ISM) de banda S (2,4
a 2,5 GHz)
Padrões Freqüências Taxas de Uso
transmissão
de bits
802.11b S-Band ISM 11 Mbps Comumente usado.
802.11a ISM de banda C (5,725 54 Mbps Normalmente, não é usado devido a

a 5,875 GHz) despesas e intervalo limitado.
802.11g S-Band ISM 54 Mbps Amplamente usado. Os dispositivos 802.11g

são compatíveis com dispositivos 802.11b.
802,11n C-Band e S-Band ISM 250 Mbps Os dispositivos baseados no padrão IEEE
\2.4 e 802.11n de pré-ratificação ficaram disponíveis
5.0 GHz em agosto de 2007. Muitos dispositivos
802.11n são compatíveis com dispositivos
802.11a, b e g.
802.11ac 5 GHz 6,93 Gbps O 802.11ac, aprovado pelo IEEE em 2014, é

mais escalonável e mais rápido que 802,11n e
é implantado onde os APs e clientes sem fio
dão suporte a ele.
Métodos de segurança de rede sem fio

Os métodos de segurança de rede sem fio são um agrupamento informal de
autenticação sem fio (às vezes chamado de segurança sem fio) e criptografia de
segurança sem fio. A autenticação e a criptografia sem fio são usadas em pares para
impedir que usuários não autorizados acessem a rede sem fio e para proteger
transmissões sem fio.
Ao definir configurações de segurança sem fio nas Políticas de Rede Sem Fio do Política
de Grupo, há várias combinações para escolher. No entanto, somente os padrões de
autenticação WPA2-Enterprise, WPA-Enterprise e Open com 802.1X têm suporte para
implantações sem fio autenticadas 802.1X.
７ Observação
Ao configurar políticas de rede sem fio, você deve selecionar WPA2-Enterprise,

WPA-Enterprise ou Open com 802.1X para obter acesso às configurações de EAP
necessárias para implantações sem fio autenticadas 802.1X.
Autenticação sem fio

Este guia recomenda o uso dos seguintes padrões de autenticação sem fio para
implantações sem fio autenticadas 802.1X.
Acesso Protegido por Wi-Fi – Enterprise (WPA-Enterprise) O WPA é um padrão

provisório desenvolvido pela WiFi Alliance para cumprir o protocolo de segurança sem
fio 802.11. O protocolo WPA foi desenvolvido em resposta a uma série de falhas graves
que foram descobertas no protocolo WEP (Wired Equivalent Privacy) anterior.
WPA-Enterprise fornece segurança aprimorada em relação ao WEP:
1. Exigir autenticação que usa a estrutura EAP 802.1X como parte da infraestrutura
que garante a autenticação mútua centralizada e o gerenciamento dinâmico de
chaves
2. Aprimorando o ICV (Valor de Verificação de Integridade) com uma MIC (Verificação

de Integridade da Mensagem), para proteger o cabeçalho e o conteúdo
3. Implementando um contador de quadros para desencorajar ataques de

reprodução
Acesso Protegido por Wi-Fi 2 – Enterprise (WPA2-Enterprise) Assim como o padrão

WPA-Enterprise, WPA2-Enterprise usa a estrutura 802.1X e EAP. WPA2-Enterprise
fornece proteção de dados mais forte para vários usuários e grandes redes gerenciadas.
WPA2-Enterprise é um protocolo robusto projetado para impedir o acesso não
autorizado à rede verificando os usuários de rede por meio de um servidor de
autenticação.
Criptografia de segurança sem fio

A criptografia de segurança sem fio é usada para proteger as transmissões sem fio
enviadas entre o cliente sem fio e a AP sem fio. A criptografia de segurança sem fio é
usada em conjunto com o método de autenticação de segurança de rede selecionado.
Por padrão, os computadores que executam Windows 10, Windows 8.1 e Windows 8
dão suporte a dois padrões de criptografia:
1. O Protocolo TKIP (Temporal Key Integrity Protocol) é um protocolo de criptografia

mais antigo que foi originalmente projetado para fornecer criptografia sem fio
mais segura do que o que foi fornecido pelo protocolo WEP (Privacidade
Equivalente com Fio) inerentemente fraco. O TKIP foi projetado pelo grupo de
tarefas IEEE 802.11i e pela Wi-Fi Alliance para substituir o WEP sem exigir a
substituição do hardware herdado. O TKIP é um conjunto de algoritmos que
encapsula o conteúdo do WEP e permite que os usuários de equipamentos WiFi
herdados atualizem para o TKIP sem substituir o hardware. Assim como o WEP, o
TKIP usa o algoritmo de criptografia de fluxo RC4 como base. No entanto, o novo
protocolo criptografa cada pacote de dados com uma chave de criptografia
exclusiva e as chaves são muito mais fortes do que as do WEP. Embora o TKIP seja
útil para atualizar a segurança em dispositivos mais antigos que foram projetados
para usar apenas o WEP, ele não aborda todos os problemas de segurança
enfrentados por LANs sem fio e, na maioria dos casos, não é suficientemente
robusto para proteger transmissões de dados confidenciais governamentais ou
corporativas.
2. O AES (Advanced Encryption Standard) é o protocolo de criptografia preferencial

para a criptografia de dados comerciais e governamentais. O AES oferece um nível
mais alto de segurança de transmissão sem fio do que TKIP ou WEP. Ao contrário
do TKIP e do WEP, o AES requer hardware sem fio que dê suporte ao padrão AES.
O AES é um padrão de criptografia de chave simétrica que usa três criptografias de
bloco, AES-128, AES-192 e AES-256.
Em Windows Server 2016, os seguintes métodos de criptografia sem fio baseados em

AES estão disponíveis para configuração em propriedades de perfil sem fio quando você
seleciona um método de autenticação do WPA2-Enterprise, o que é recomendado.
1. AES-CCMP. O Protocolo CCMP implementa o padrão 802.11i e foi projetado para

uma criptografia de segurança mais alta do que a fornecida pelo WEP e usa chaves
de criptografia AES de 128 bits.
2. AES-GCMP. O GCMP (Galois Counter Mode Protocol) é compatível com o
802.11ac, é mais eficiente que o AES-CCMP e fornece melhor desempenho para
clientes sem fio. O GCMP usa chaves de criptografia AES de 256 bits.
） Importante
A WEP (Privacidade de Equivalência com Fio) era o padrão de segurança sem fio
original que era usado para criptografar o tráfego de rede. Você não deve
implantar o WEP em sua rede porque há vulnerabilidades conhecidas nessa forma
de segurança desatualizada.
Active Directory Domain Services (AD DS)

O AD DS fornece um banco de dados distribuído que armazena e gerencia informações
sobre recursos da rede e dados específicos de aplicativos habilitados por diretório. Os
administradores podem usar AD DS para organizar elementos de uma rede, como
usuários, computadores e outros dispositivos, em uma estrutura de confinamento
hierárquica. A estrutura de confinamento hierárquica inclui a floresta do Active
Directory, domínios na floresta e unidades organizacionais (OUs) em cada domínio. Um
servidor que está executando o AD DS é chamado de controlador de domínio.
O AD DS contém as contas de usuário, as contas de computador e as propriedades da

conta exigidas pelo IEEE 802.1X e PEAP-MS-CHAP v2 para autenticar as credenciais do
usuário e avaliar a autorização para conexões sem fio.
Usuários e computadores do Active Directory

Usuários e Computadores do Active Directory é um componente do AD DS que contém
contas que representam entidades físicas, como um computador, uma pessoa ou um
grupo de segurança. Um grupo de segurança é uma coleção de contas de usuário ou
computador que os administradores podem gerenciar como uma única unidade. Contas
de usuário e computador que pertencem a um grupo específico são conhecidas como
membros do grupo.
Gerenciamento de Política de Grupo

Política de Grupo Management permite o gerenciamento de configurações e alterações
baseadas em diretório das configurações do usuário e do computador, incluindo
informações de segurança e de usuário. Você usa Política de Grupo para definir
configurações para grupos de usuários e computadores. Com Política de Grupo, você
pode especificar configurações para entradas do Registro, segurança, instalação de
software, scripts, redirecionamento de pastas, serviços de instalação remota e
manutenção do Internet Explorer. As configurações de Política de Grupo criadas estão
contidas em um GPO (objeto Política de Grupo). Ao associar um GPO a contêineres de
sistema do Active Directory selecionados — sites, domínios e UOs — você pode aplicar
as configurações do GPO aos usuários e computadores nesses contêineres do Active
Directory. Para gerenciar Política de Grupo objetos em uma empresa, você pode usar o
MMC (Console de Gerenciamento Microsoft) do Editor de Gerenciamento Política de
Grupo.
Este guia fornece instruções detalhadas sobre como especificar configurações na

extensão de Políticas de Rede Sem Fio (IEEE 802.11) do Gerenciamento de Política de
Grupo. As políticas de Rede Sem Fio (IEEE 802.11) configuram computadores cliente sem
fio membros do domínio com as configurações de conectividade e sem fio necessárias
para acesso sem fio autenticado 802.1X.
Certificados do servidor
Esse cenário de implantação requer certificados de servidor para cada NPS que executa
a autenticação 802.1X.
Um certificado de servidor é um documento digital que normalmente é usado para

autenticação e para proteger informações em redes abertas. O certificado liga de forma
segura uma chave pública à entidade que mantém a chave privada correspondente. Os
certificados são assinados digitalmente pela AC emissora e podem ser emitidos para um
usuário, um computador ou um serviço.
Uma AC (autoridade de certificação) é uma entidade responsável por estabelecer e

atestar a autenticidade das chaves públicas pertencentes a entidades (geralmente
usuários ou computadores) ou outras ACs. As atividades de uma autoridade de
certificação podem incluir a associação de chaves públicas a nomes diferenciados por
meio de certificados assinados, gerenciamento de números de série de certificados e
revogação de certificados.
O AD CS (Serviços de Certificados do Active Directory) é uma função de servidor que

emite certificados como uma AC de rede. Uma infraestrutura de certificado do AD CS,
também conhecida como PKI (infraestrutura de chave pública), fornece serviços
personalizáveis para emissão e gerenciamento de certificados para a empresa.
EAP, PEAP e PEAP-MS-CHAP v2

O Protocolo de Autenticação Extensível (EAP) estende o protocolo PPP permitindo
métodos de autenticação adicionais que usam credenciais e trocas de informações de
comprimentos arbitrários. Com a autenticação EAP, o cliente de acesso à rede e o
autenticador (como o NPS) devem dar suporte ao mesmo tipo de EAP para que a
autenticação bem-sucedida ocorra. Windows Server 2016 inclui uma infraestrutura de
EAP, dá suporte a dois tipos de EAP e à capacidade de passar mensagens EAP para
NPSs. Usando o EAP, você pode dar suporte a esquemas de autenticação adicionais,
conhecidos como tipos EAP. Os tipos de EAP compatíveis com Windows Server 2016
são:
Protocolo TLS
Microsoft Challenge Handshake Authentication Protocol versão 2 (MS-CHAP v2)
） Importante
Tipos de EAP fortes (como aqueles baseados em certificados) oferecem melhor

segurança contra ataques de força bruta, ataques de dicionário e ataques de
adivinhação de senha do que protocolos de autenticação baseados em senha
(como CHAP ou MS-CHAP versão 1).
O PEAP (EAP protegido) usa TLS para criar um canal criptografado entre um cliente
PEAP de autenticação, como um computador sem fio, e um autenticador PEAP, como
um NPS ou outros servidores RADIUS. O PEAP não especifica um método de
autenticação, mas fornece segurança adicional para outros protocolos de autenticação
EAP (como EAP-MS-CHAP v2) que podem operar por meio do canal criptografado TLS
fornecido pelo PEAP. O PEAP é usado como um método de autenticação para acessar
clientes que estão se conectando à rede da sua organização por meio dos seguintes
tipos de NASs (servidores de acesso à rede):
Pontos de acesso sem fio compatíveis com 802.1X
Opções de autenticação compatíveis com 802.1X
Computadores que executam Windows Server 2016 e o RAS (Serviço de Acesso

Remoto) configurados como servidores VPN (rede virtual privada), servidores
DirectAccess ou ambos
Computadores que executam Windows Server 2016 e Serviços de Área de Trabalho

Remota
PEAP-MS-CHAP v2 é mais fácil de implantar do que EAP-TLS porque a autenticação de

usuário é executada usando credenciais baseadas em senha (nome de usuário e senha),
em vez de certificados ou cartões inteligentes. Somente servidores NPS ou outros
RADIUS são necessários para ter um certificado. O certificado NPS é usado pelo NPS
durante o processo de autenticação para provar sua identidade para clientes PEAP.
Este guia fornece instruções para configurar seus clientes sem fio e seus NPS para usar o
PEAP-MS-CHAP v2 para acesso autenticado 802.1X.
Servidor de Políticas de Rede

O NPS (Servidor de Política de Rede) permite que você configure e gerencie
centralmente as políticas de rede usando o servidor RADIUS (Serviço de Usuário Discado
de Autenticação Remota) e o proxy RADIUS. O NPS é necessário quando você implanta
o acesso sem fio 802.1X.
Quando você configura seus pontos de acesso sem fio 802.1X como clientes RADIUS no
NPS, o NPS processa as solicitações de conexão enviadas pelos APs. Durante o
processamento da solicitação de conexão, o NPS executa a autenticação e a
autorização. A autenticação determina se o cliente apresentou credenciais válidas. Se o
NPS autenticar com êxito o cliente solicitante, o NPS determinará se o cliente está
autorizado a fazer a conexão solicitada e permite ou nega a conexão. Isso é explicado
com mais detalhes da seguinte maneira:
Autenticação
A autenticação mútua PEAP-MS-CHAP v2 com êxito tem duas partes principais:
1. O cliente autentica o NPS. Durante essa fase de autenticação mútua, o NPS envia
seu certificado de servidor para o computador cliente para que o cliente possa
verificar a identidade do NPS com o certificado. Para autenticar o NPS com êxito, o
computador cliente deve confiar na AC que emitiu o certificado NPS. O cliente
confia nessa AC quando o certificado da AC está presente no repositório de
certificados autoridades de certificação raiz confiáveis no computador cliente.
Se você implantar sua própria AC privada, o certificado de AC será instalado

automaticamente no repositório de certificados Autoridades de Certificação Raiz
Confiáveis para o Usuário Atual e para o Computador Local quando Política de
Grupo for atualizado no computador cliente membro do domínio. Se você decidir
implantar certificados de servidor de uma AC pública, verifique se o certificado de
autoridade de certificação pública já está no repositório de certificados
autoridades de certificação raiz confiáveis.
2. O NPS autentica o usuário. Depois que o cliente autentica o NPS com êxito, o
cliente envia as credenciais baseadas em senha do usuário para o NPS, que verifica
as credenciais do usuário no banco de dados de contas de usuário no AD DS
(Active Directory Domain Services).
Se as credenciais forem válidas e a autenticação for bem-sucedida, o NPS iniciará a fase

de autorização do processamento da solicitação de conexão. Se as credenciais não
forem válidas e a autenticação falhar, o NPS enviará uma mensagem de Rejeição de
Acesso e a solicitação de conexão será negada.
Autorização
O servidor que executa o NPS executa a autorização da seguinte maneira:
1. O NPS verifica se há restrições nas propriedades de discagem da conta de usuário

ou computador no AD DS. Cada conta de usuário e computador no Usuários e
Computadores do Active Directory inclui várias propriedades, incluindo aquelas
encontradas na guia Discagem. Nessa guia, em Permissão de Acesso à Rede, se o
valor for Permitir acesso, o usuário ou computador estará autorizado a se conectar
à rede. Se o valor for Negar acesso, o usuário ou computador não estará
autorizado a se conectar à rede. Se o valor for Controlar o acesso por meio da
Política de Rede do NPS, o NPS avaliará as políticas de rede configuradas para
determinar se o usuário ou o computador está autorizado a se conectar à rede.
2. Em seguida, o NPS processa suas políticas de rede para encontrar uma política que
corresponda à solicitação de conexão. Se uma política correspondente for
encontrada, o NPS concederá ou negará a conexão com base na configuração
dessa política.
Se a autenticação e a autorização forem bem-sucedidas e se a política de rede

correspondente conceder acesso, o NPS concederá acesso à rede e o usuário e o
computador poderão se conectar aos recursos de rede para os quais eles têm
permissões.
７ Observação
Para implantar o acesso sem fio, você deve configurar políticas NPS. Este guia
fornece instruções para usar o assistente Configurar 802.1X no NPS para criar
políticas NPS para acesso sem fio autenticado 802.1X.
Perfis de inicialização
Em redes sem fio autenticadas em 802.1X, os clientes sem fio devem fornecer
credenciais de segurança autenticadas por um servidor RADIUS para se conectarem à
rede. Para o Protocolo de Autenticação de Handshake do EAP Protegido [PEAP]-
Microsoft Challenge Handshake versão 2 [MS-CHAP v2], as credenciais de segurança
são um nome de usuário e uma senha. Para EAP-Transport TLS [Layer Security] ou PEAP-
TLS, as credenciais de segurança são certificados, como certificados de usuário cliente e
computador ou cartões inteligentes.
Ao se conectar a uma rede configurada para executar a autenticação PEAP-MS-CHAP

v2, PEAP-TLS ou EAP-TLS, por padrão, os clientes sem fio do Windows também devem
validar um certificado de computador enviado pelo servidor RADIUS. O certificado do
computador enviado pelo servidor RADIUS para cada sessão de autenticação é
comumente chamado de certificado de servidor.
Conforme mencionado anteriormente, você pode emitir seus servidores RADIUS seu
certificado de servidor de uma das duas maneiras: de uma AC comercial (como VeriSign,
Inc., ) ou de uma AC privada que você implanta em sua rede. Se o servidor RADIUS
enviar um certificado de computador emitido por uma AC comercial que já tenha um
certificado raiz instalado no repositório de certificados autoridades de certificação raiz
confiáveis do cliente, o cliente sem fio poderá validar o certificado de computador do
servidor RADIUS, independentemente de o cliente sem fio ter ingressado no domínio do
Active Directory. Nesse caso, o cliente sem fio pode se conectar à rede sem fio e, em
seguida, você pode ingressar o computador no domínio.
７ Observação
O comportamento que exige que o cliente valide o certificado do servidor pode ser
desabilitado, mas não é recomendável desabilitar a validação de certificado do
servidor em ambientes de produção.
Os perfis de inicialização sem fio são perfis temporários configurados de forma a

permitir que os usuários cliente sem fio se conectem à rede sem fio autenticada 802.1X
antes que o computador seja ingressado no domínio e/ou antes que o usuário tenha
feito logon com êxito no domínio usando um determinado computador sem fio pela
primeira vez. Esta seção resume o problema encontrado ao tentar ingressar um
computador sem fio no domínio ou para um usuário usar um computador sem fio
ingressado no domínio pela primeira vez para fazer logon no domínio.
Para implantações nas quais o usuário ou o administrador de TI não podem conectar

fisicamente um computador à rede Ethernet com fio para ingressar o computador no
domínio e o computador não tem o certificado de AUTORIDADE de Certificação raiz
necessário instalado em seu repositório de certificados autoridades de certificação raiz
confiáveis , você pode configurar clientes sem fio com um perfil de conexão sem fio
temporário, chamado de perfil de inicialização, para se conectar à rede sem fio.
Um perfil de inicialização remove o requisito de validar o certificado de computador do

servidor RADIUS. Essa configuração temporária permite que o usuário sem fio ingresse
o computador no domínio, momento em que as Políticas de Rede Sem Fio (IEEE 802.11)
são aplicadas e o certificado de AUTORIDADE raiz apropriado é instalado
automaticamente no computador.
Quando Política de Grupo é aplicado, um ou mais perfis de conexão sem fio que
impõem o requisito de autenticação mútua são aplicados no computador; o perfil de
inicialização não é mais necessário e é removido. Depois de ingressar o computador no
domínio e reiniciar o computador, o usuário pode usar uma conexão sem fio para fazer
logon no domínio.
Para obter uma visão geral do processo de implantação de acesso sem fio usando essas
tecnologias, consulte Visão geral da implantação de acesso sem fio.
Visão geral da implantação de acesso
sem fio
A ilustração a seguir mostra os componentes necessários para implantar o acesso sem

fio autenticado 802.1X com PEAP-MS-CHAP v2.
Componentes de implantação de acesso sem

fio
A seguinte infraestrutura é necessária para essa implantação de acesso sem fio:
Pontos de acesso sem fio compatíveis com 802.1X

Depois que os serviços de infraestrutura de rede necessários que dão suporte à rede
local sem fio estiverem em vigor, você poderá iniciar o processo de design para o local
dos APs sem fio. O processo de design de implantação de AP sem fio envolve estas
etapas:
Identifique as áreas de cobertura para usuários sem fio. Ao identificar as áreas de

cobertura, certifique-se de identificar se deseja fornecer serviço sem fio fora do
prédio e, se sim, determinar especificamente onde essas áreas externas estão.
Determine quantos APs sem fio implantar para garantir a cobertura adequada.
Determine onde colocar APs sem fio.
Selecione as frequências de canal para APs sem fio.
Active Directory Domain Services

Os elementos a seguir do AD DS são necessários para implantação de acesso sem fio.
Usuários e computadores
Use o snap-in Usuários e Computadores do Active Directory para criar e gerenciar
contas de usuário e para criar um grupo de segurança sem fio que inclua cada membro
de domínio a quem você deseja conceder acesso sem fio.
Políticas de rede sem fio (IEEE 802.11)
Você pode usar a extensão de políticas de rede sem fio (IEEE 802.11) do Gerenciamento
de Política de Grupo para configurar políticas aplicadas a computadores sem fio quando
eles tentam acessar a rede.
No Editor de Gerenciamento Política de Grupo, ao clicar com o botão direito do mouse

em Políticas de Rede Sem Fio (IEEE 802.11), você tem as duas opções a seguir para o
tipo de política sem fio que você cria.
Criar uma nova política de rede sem fio para versões posteriores e Windows
Vista
Criar uma nova política XP Windows

 Dica
Ao configurar uma nova política de rede sem fio, você tem a opção de alterar o
nome e a descrição da política. Se você alterar o nome da política, a alteração será
refletida no painel Detalhes do Editor de Gerenciamento de Política de Grupo e na
barra de título da caixa de diálogo política de rede sem fio. Independentemente de
como você renomeia suas políticas, a Nova Política Sem Fio XP sempre será listada
no Editor de Gerenciamento Política de Grupo com o Tipo exibindo XP. Outras
políticas são listadas com o Tipo mostrando Versões Posteriores e Vista.
A Política de Rede Sem Fio para Windows Versões Posteriores e Vista permite que você
configure, priorize e gerencie vários perfis sem fio. Um perfil sem fio é uma coleção de
configurações de conectividade e segurança que são usadas para se conectar a uma
rede sem fio específica. Quando Política de Grupo é atualizado em seus computadores
cliente sem fio, os perfis criados na Política de Rede Sem Fio são adicionados
automaticamente à configuração em seus computadores cliente sem fio aos quais a
Política de Rede Sem Fio se aplica.
Permitindo conexões com várias redes sem fio
Se você tiver clientes sem fio movidos entre locais físicos em sua organização, como
entre uma sede e uma filial, talvez queira que os computadores se conectem a mais de
uma rede sem fio. Nessa situação, você pode configurar um perfil sem fio que contém
as configurações de conectividade e segurança específicas para cada rede.
Por exemplo, suponha que sua empresa tenha uma rede sem fio para o escritório
corporativo principal, com um identificador de conjunto de serviços (SSID) WlanCorp.
Sua filial também tem uma rede sem fio à qual você também deseja se conectar. A filial
tem o SSID configurado como WlanBranch.
Nesse cenário, você pode configurar um perfil para cada rede e computadores ou
outros dispositivos que são usados na filial e na filial corporativa podem se conectar a
qualquer uma das redes sem fio quando elas estiverem fisicamente no intervalo da área
de cobertura de uma rede.
Redes sem fio de modo misto
Como alternativa, suponha que sua rede tenha uma mistura de computadores sem fio e
dispositivos que dão suporte a diferentes padrões de segurança. Talvez alguns
computadores mais antigos tenham adaptadores sem fio que só podem usar o WPA-
Enterprise, enquanto os dispositivos mais recentes podem usar o padrão de WPA2-
Enterprise mais forte.
Você pode criar dois perfis diferentes que usam o mesmo SSID e configurações de
conectividade e segurança quase idênticas.
Em um perfil, você pode definir a autenticação sem fio para WPA2-Enterprise com o AES
e, no outro perfil, você pode especificar WPA-Enterprise com TKIP.
Isso é comumente conhecido como uma implantação de modo misto e permite que
computadores de diferentes tipos e recursos sem fio compartilhem a mesma rede sem
fio.
NPS (Servidor de Políticas de Rede)

O NPS permite que você crie e imponha políticas de acesso à rede para autenticação e
autorização de solicitação de conexão.
Ao usar o NPS como um servidor RADIUS, você configura servidores de acesso à rede,
como pontos de acesso sem fio, como clientes RADIUS no NPS. Você também configura
as políticas de rede que o NPS usa para autenticar clientes de acesso e autorizar suas
solicitações de conexão.
Computadores cliente sem fio

Para este guia, computadores cliente sem fio são computadores e outros dispositivos
equipados com adaptadores de rede sem fio IEEE 802.11 e que estão executando
Windows sistemas operacionais cliente ou servidor Windows.
Computadores de servidor como clientes sem fio
Por padrão, a funcionalidade para 802.11 sem fio está desabilitada em computadores
que estão executando Windows Server.
Para habilitar a conectividade sem fio em computadores que executam sistemas

operacionais de servidor, você deve instalar e habilitar o recurso de Serviço de LAN Sem
Fio (WLAN) usando Windows PowerShell ou o Assistente para Adicionar Funções e
Recursos em Gerenciador do Servidor.
Quando você instala o recurso Serviço de LAN Sem Fio , a nova Configuração
Automática WLAN do serviço é instalada nos Serviços. Quando a instalação for
concluída, você deverá reiniciar o servidor.
Depois que o servidor for reiniciado, você poderá acessar a Configuração Automática da
WLAN ao clicar em Iniciar, Windows Ferramentas Administrativas e Serviços.
Após a instalação e a reinicialização do servidor, o serviço de Configuração Automática

da WLAN está em um estado interrompido com um tipo de inicialização automático.
Para iniciar o serviço, clique duas vezes na Configuração Automática da WLAN. Na guia
Geral , clique em Iniciar e clique em OK.
O serviço de Configuração Automática da WLAN enumera adaptadores sem fio e

gerencia as conexões sem fio e os perfis sem fio que contêm configurações necessárias
para configurar o servidor para se conectar a uma rede sem fio.
Para obter uma visão geral da implantação de acesso sem fio, consulte o Processo de
Implantação de Acesso Sem Fio.
Processo da implantação de acesso sem
fio
O processo usado para implantar o acesso sem fio ocorre nestes estágios:
Estágio 1 – Implantação de AP
Planeje, implante e configure seus APs para conectividade de cliente sem fio e para uso
com NPS. Dependendo de sua preferência e dependências de rede, você pode pré-
configurar as configurações em seus APs sem fio antes de instalá-las em sua rede ou
configurá-las remotamente após a instalação.
Estágio 2 – Configuração AD DS grupo

No AD DS, você deve criar um ou mais grupos de segurança de usuários sem fio.
Em seguida, identifique os usuários que têm permissão de acesso sem fio à rede.
Por fim, adicione os usuários aos grupos de segurança de usuários sem fio apropriados
que você criou.
７ Observação
Por padrão, a configuração permissão de acesso à rede nas propriedades discadas

da conta de usuário é configurada com a configuração Controlar o acesso por
meio da Política de Rede NPS. A menos que você tenha motivos específicos para
alterar essa configuração, é recomendável manter o padrão. Isso permite controlar
o acesso à rede por meio das políticas de rede configuradas no NPS.
Estágio 3 – configuração Política de Grupo

configuração
Configure a extensão de políticas de rede sem fio (IEEE 802.11) do Política de Grupo
usando o Editor de Gerenciamento de Política de Grupo Console de Gerenciamento
Microsoft (MMC).
Para configurar computadores membros do domínio usando as configurações nas

políticas de rede sem fio, você deve aplicar Política de Grupo. Quando um computador é
ingressado pela primeira vez no domínio, Política de Grupo é aplicado
automaticamente. Se as alterações são feitas no Política de Grupo, as novas
configurações são aplicadas automaticamente:
Por Política de Grupo em intervalos pré-determinados
Se um usuário de domínio faz logo off e, em seguida, volta para a rede
Reiniciando o computador cliente e fazendo logona no domínio
Você também pode forçar Política de Grupo atualizar enquanto estiver conectado a um
computador executando o comando gpupdate no prompt de comando.
Estágio 4 – Configuração do NPS

Use um assistente de configuração no NPS para adicionar pontos de acesso sem fio
como clientes RADIUS e para criar as políticas de rede que o NPS usa ao processar
Ao usar o assistente para criar as políticas de rede, especifique PEAP como o tipo de
EAP e o grupo de segurança de usuários sem fio que foi criado no segundo estágio.
Estágio 5 – Implantar clientes sem fio

Use computadores cliente para se conectar à rede.
Para computadores membros do domínio que podem fazer logoff na LAN com fio, as
definições de configuração sem fio necessárias são aplicadas automaticamente quando
Política de Grupo é atualizada.
Se você habilitar a configuração em Políticas de Rede Sem Fio (IEEE 802.11) para se
conectar automaticamente quando o computador estiver dentro do intervalo de difusão
da rede sem fio, seus computadores sem fio ingressados no domínio tentarão se
conectar automaticamente à LAN sem fio.
Para se conectar à rede sem fio, os usuários só precisam fornecer suas credenciais de
nome de usuário de domínio e senha quando solicitados por Windows.
Para planejar sua implantação de acesso sem fio, consulte Planejamento de implantação
de acesso sem fio.
Planejamento da implantação de acesso
sem fio
Antes de implantar o acesso sem fio, você deve planejar os seguintes itens:
Instalação de APs (pontos de acesso sem fio) em sua rede
Configuração e acesso do cliente sem fio
As seções a seguir fornecem detalhes sobre essas etapas de planejamento.
Planejando instalações de AP sem fio

Ao projetar sua solução de acesso à rede sem fio, você deve fazer o seguinte:
1. Determinar quais padrões seus APs sem fio devem dar suporte
2. Determinar as áreas de cobertura nas quais você deseja fornecer serviço sem fio
3. Determinar onde você deseja localizar APs sem fio
Além disso, você deve planejar um esquema de endereço IP para clientes sem fio e AP
sem fio. Consulte a seção Planejar a configuração de APs sem fio no NPS abaixo para
obter informações relacionadas.
Verificar o suporte de AP sem fio para padrões

Para fins de consistência e facilidade de implantação e gerenciamento de AP, é
recomendável implantar APs sem fio da mesma marca e modelo.
Os APs sem fio implantados devem dar suporte ao seguinte:
IEEE 802.1X
Autenticação RADIUS
Autenticação sem fio e criptografia. Listado na ordem da maioria para a menos

preferencial:
1. WPA2-Enterprise com AES

2. WPA2-Enterprise com TKIP
3. WPA-Enterprise com AES
4. WPA-Enterprise com TKIP
７ Observação
Para implantar o WPA2, você deve usar adaptadores de rede sem fio e APs sem fio
que também suportam WPA2. Caso contrário, use WPA-Enterprise.
Além disso, para fornecer segurança aprimorada para a rede, os APs sem fio devem dar
suporte às seguintes opções de segurança:
Filtragem de DHCP. A AP sem fio deve filtrar em portas IP para impedir a

transmissão de mensagens de difusão DHCP nos casos em que o cliente sem fio
está configurado como um servidor DHCP. A AP sem fio deve impedir que o
cliente envie pacotes IP da porta UDP 68 para a rede.
Filtragem de DNS. A AP sem fio deve filtrar em portas IP para impedir que um
cliente seja um servidor DNS. A AP sem fio deve impedir que o cliente envie
pacotes IP da porta TCP ou UDP 53 para a rede.
Isolamento do cliente Se o ponto de acesso sem fio fornece recursos de

isolamento do cliente, você deve habilitar o recurso para evitar possíveis
explorações de fraude do Protocolo de Resolução de Endereço (ARP).
Identificar áreas de cobertura para usuários sem fio

Use desenhos arquitetônicos de cada andar para cada prédio para identificar as áreas
em que você deseja fornecer cobertura sem fio. Por exemplo, identifique os escritórios
apropriados, as salas de conferências, os loção, as cafeterias ou os quartos apropriados.
Nos desenhos, indique os dispositivos que interferem nos sinais sem fio, como
equipamentos médicos, câmeras de vídeo sem fio, telefones sem fio que operam no
intervalo de 2,4 a 2,5 GHz de ISM (Industrial, Científico e Médico) e dispositivos
habilitados para Bluetooth.
No desenho, marque aspectos do prédio que podem interferir em sinais sem fio;
Objetos de metal usados na construção de um prédio podem afetar o sinal sem fio. Por
exemplo, os objetos comuns a seguir podem interferir na propagação de sinal:
elevadores, aquecimento e ar-condicionado e fitas concretas de suporte.
Consulte seu fabricante de AP para obter informações sobre fontes que podem causar
atenuação de frequência de rádio de AP sem fio. A maioria dos APs fornece software de
teste que você pode usar para verificar a intensidade do sinal, a taxa de erro e a taxa de
transferência de dados.
Determinar onde instalar APs sem fio

Nos desenhos de arquitetura, localize seus APs sem fio próximos o suficiente para
fornecer uma ampla cobertura sem fio, mas distante o suficiente para que eles não
interfiram entre si.
A distância necessária entre os APs depende do tipo de antena AP e AP, aspectos do

prédio que bloqueia sinais sem fio e outras fontes de interferência. Você pode marcar
posicionamentos de AP sem fio para que cada AP sem fio não seja superior a 300 pés
de qualquer AP sem fio adjacente. Confira a documentação do fabricante de AP sem fio
para ver as especificações e diretrizes de AP para posicionamento.
Instale temporariamente os APs sem fio nos locais especificados em seus desenhos de
arquitetura. Em seguida, usando um laptop equipado com um adaptador sem fio 802.11
e o software de pesquisa do site que normalmente é fornecido com adaptadores sem
fio, determine a intensidade do sinal em cada área de cobertura.
Em áreas de cobertura em que a intensidade do sinal é baixa, posicione a AP para

melhorar a intensidade do sinal para a área de cobertura, instale APs sem fio adicionais
para fornecer a cobertura necessária, realocar ou remover fontes de interferência de
sinal.
Atualize seus desenhos de arquitetura para indicar o posicionamento final de todos os

APs sem fio. Ter um mapa de posicionamento de AP preciso ajudará posteriormente
durante as operações de solução de problemas ou quando você deseja atualizar ou
substituir os APs.
Planejar a configuração do cliente RADIUS de AP e NPS

sem fio
Você pode usar o NPS para configurar APs sem fio individualmente ou em grupos.
Se você estiver implantando uma rede sem fio grande que inclui muitos APs, será muito
mais fácil configurar APs em grupos. Para adicionar os APs como grupos de clientes
RADIUS no NPS, você deve configurar os APs com essas propriedades.
Os APs sem fio são configurados com endereços IP do mesmo intervalo de
endereços IP.
Todos os APs sem fio são configurados com o mesmo segredo compartilhado.
Planejar o uso do PEAP Fast Reconnect

Em uma infraestrutura 802.1X, os pontos de acesso sem fio são configurados como
clientes RADIUS para servidores RADIUS. Quando a reconexão rápida do PEAP é
implantada, um cliente sem fio que se móvel entre dois ou mais pontos de acesso não
precisa ser autenticado com cada nova associação.
A reconexão rápida do PEAP reduz o tempo de resposta para autenticação entre o

cliente e o autenticador porque a solicitação de autenticação é encaminhada do novo
ponto de acesso para o NPS que originalmente realizou autenticação e autorização para
a solicitação de conexão do cliente.
Como o cliente PEAP e o NPS usam propriedades de conexão TLS (Transport Layer
Security) armazenadas anteriormente em cache (a coleção da qual é chamada de
identificador TLS), o NPS pode determinar rapidamente que o cliente está autorizado a
se reconectar.
） Importante
Para que a reconexão rápida funcione corretamente, os APs devem ser

configurados como clientes RADIUS do mesmo NPS.
Se o NPS original ficar indisponível ou se o cliente mudar para um ponto de acesso

configurado como um cliente RADIUS para um servidor RADIUS diferente, a
autenticação completa deverá ocorrer entre o cliente e o novo autenticador.
Configuração de AP sem fio

A lista a seguir resume os itens normalmente configurados em APs sem fio com
capacidade para 802.1X:
７ Observação
Os nomes de item podem variar de acordo com a marca e o modelo e podem ser
diferentes daqueles da lista a seguir. Consulte a documentação da AP sem fio para
obter detalhes específicos da configuração.
Identificador do conjunto de serviços (SSID). Esse é o nome da rede sem fio (por
exemplo, ExampleWlan) e o nome que é anunciado para clientes sem fio. Para
reduzir a confusão, o SSID que você opta por anunciar não deve corresponder ao
SSID que é transmitido por nenhuma rede sem fio que está dentro do intervalo de
recepção de sua rede sem fio.
Nos casos em que vários APs sem fio são implantados como parte da mesma rede
sem fio, configure cada AP sem fio com o mesmo SSID. Nos casos em que vários
APs sem fio são implantados como parte da mesma rede sem fio, configure cada
AP sem fio com o mesmo SSID.
Nos casos em que você precisa implantar diferentes redes sem fio para atender às
necessidades de negócios específicas, as AP's sem fio em uma rede devem
transmitir um SSID diferente do SSID de suas outras redes. Por exemplo, se você
precisar de uma rede sem fio separada para seus funcionários e convidados,
poderá configurar seus APs sem fio para a rede de negócios com o SSID definido
para transmitir ExampleWLAN. Para sua rede convidada, você pode definir o SSID
de cada AP sem fio para transmitir GuestWLAN. Dessa forma, seus funcionários e
convidados podem se conectar à rede pretendida sem confusão desnecessária.
 Dica
Algumas APs sem fio têm a capacidade de transmitir vários SSIDs para
acomodar implantações de várias redes. As AP's sem fio que podem transmitir
vários SSIDs podem reduzir os custos de implantação e manutenção
operacional.
Autenticação e criptografia sem fio.
A autenticação sem fio é a autenticação de segurança usada quando o cliente sem

fio é associado a um ponto de acesso sem fio.
A criptografia sem fio é a criptografia de segurança usada com autenticação sem

fio para proteger as comunicações enviadas entre a AP sem fio e o cliente sem fio.
Endereço IP de AP sem fio (estático). Em cada AP sem fio, configure um endereço

IP estático exclusivo. Se a sub-rede for a serviço de um servidor DHCP, verifique se
todos os endereços IP de AP estão dentro de um intervalo de exclusão DHCP para
que o servidor DHCP não tente emitir o mesmo endereço IP para outro
computador ou dispositivo. Os intervalos de exclusão são documentados no
procedimento "Para criar e ativar um novo Escopo DHCP" no Guia de Rede
Principal. Se você estiver planejando configurar APs como clientes RADIUS por
grupo no NPS, cada AP no grupo deverá ter um endereço IP do mesmo intervalo
de endereços IP.
Nome DNS. Alguns APs sem fio podem ser configurados com um nome DNS.
Configure cada AP sem fio com um nome exclusivo. Por exemplo, se você tiver um
APs sem fio implantado em um prédio de várias histórias, poderá nomear os três
primeiros APs sem fio implantados no terceiro andar AP3-01, AP3-02 e AP3-03.
Máscara de sub-rede ap sem fio. Configure a máscara para designar qual parte do
endereço IP é a ID de rede e qual parte do endereço IP é o host.
Serviço DHCP de AP. Se seu AP sem fio tiver um serviço DHCP integrado,
desabilite-o.
Segredo compartilhado RADIUS. Use um segredo compartilhado RADIUS

exclusivo para cada AP sem fio, a menos que você esteja planejando configurar
clientes NPS RADIUS em grupos – em que circunstância você deve configurar
todos os APs no grupo com o mesmo segredo compartilhado. Os segredos
compartilhados devem ser uma sequência aleatória de pelo menos 22 caracteres,
com letras maiúsculas e minúsculas, números e pontuação. Para garantir a
aleatoriedade, você pode usar um programa de geração de caracteres aleatórios
para criar seus segredos compartilhados. É recomendável que você grave o
segredo compartilhado para cada AP sem fio e armazene-o em um local seguro,
como um cofre de escritório. Ao configurar clientes RADIUS no console do NPS,
você criará uma versão virtual de cada AP. O segredo compartilhado que você
configura em cada AP virtual no NPS deve corresponder ao segredo
compartilhado no AP físico real.
Endereço IP do servidor RADIUS. Digite o endereço IP do NPS que você deseja

usar para autenticar e autorizar solicitações de conexão para esse ponto de acesso.
Porta(s) UDP. Por padrão, o NPS usa as portas UDP 1812 e 1645 para mensagens
de autenticação RADIUS e as portas UDP 1813 e 1646 para mensagens de
contabilidade RADIUS. É recomendável que você não altere as configurações
padrão de portas UDP RADIUS.
VSAs. Alguns APs sem fio exigem VSAs (atributos específicos do fornecedor) para
fornecer funcionalidade de AP sem fio completa.
Filtragem de DHCP. Configure APs sem fio para impedir que clientes sem fio
enviem pacotes IP da porta UDP 68 para a rede. Consulte a documentação do seu
AP sem fio para configurar a filtragem de DHCP.
Filtragem de DNS. Configure APs sem fio para impedir que clientes sem fio
enviem pacotes IP da porta TCP ou UDP 53 para a rede. Consulte a documentação
do SEU AP sem fio para configurar a filtragem de DNS.
Planejando a configuração e o acesso do

cliente sem fio
Ao planejar a implantação do acesso sem fio autenticado 802.1X, você deve considerar
vários fatores específicos do cliente:
Suporte de planejamento para vários padrões.
Determine se todos os computadores sem fio estão usando a mesma versão do

Windows ou se eles são uma combinação de computadores que executam
sistemas operacionais diferentes. Se eles são diferentes, verifique se você entendeu
as diferenças nos padrões com suporte dos sistemas operacionais.
Determine se todos os adaptadores de rede sem fio em todos os computadores

cliente sem fio suportam os mesmos padrões sem fio ou se você precisa dar
suporte a padrões variados. Por exemplo, determine se alguns drivers de hardware
do adaptador de rede são WPA2-Enterprise e AES, enquanto outros só são WPA-
Enterprise e TKIP.
Planejando o modo de autenticação do cliente. Os modos de autenticação

definem como Windows clientes processam credenciais de domínio. Você pode
selecionar entre os três modos de autenticação de rede a seguir nas políticas de
rede sem fio.
1. Reautenticação do usuário. Esse modo especifica que a autenticação sempre

é executada usando credenciais de segurança com base no estado atual do
computador. Quando nenhum usuário está conectado ao computador, a
autenticação é executada usando as credenciais do computador. Quando um
usuário está conectado ao computador, a autenticação é sempre executada
usando as credenciais do usuário.
2. Computador somente. O modo somente computador especifica que a

autenticação sempre é executada usando apenas as credenciais do
computador.
3. Autenticação do usuário. O modo de autenticação do usuário especifica que

a autenticação só é executada quando o usuário está conectado ao
computador. Quando não há usuários conectados ao computador, as
tentativas de autenticação não são executadas.
Planejando restrições sem fio. Determine se você deseja fornecer a todos os

usuários sem fio o mesmo nível de acesso à sua rede sem fio ou se deseja
restringir o acesso para alguns de seus usuários sem fio. Você pode aplicar
restrições no NPS em grupos específicos de usuários sem fio. Por exemplo, você
pode definir dias e horas específicos em que determinados grupos têm permissão
de acesso à rede sem fio.
Métodos de planejamento para adicionar novos computadores sem fio. Para

computadores sem fio que ingressaram em seu domínio antes de implantar sua
rede sem fio, se o computador estiver conectado a um segmento da rede com fio
que não está protegido pelo 802.1X, as definições de configuração sem fio serão
aplicadas automaticamente depois que você configurar políticas de Rede Sem Fio
(IEEE 802.11) no controlador de domínio e depois que o Política de Grupo for
atualizado no cliente sem fio.
No entanto, para computadores que ainda não ingressaram em seu domínio, você
deve planejar um método para aplicar as configurações necessárias para o acesso
autenticado 802.1X. Por exemplo, determine se você deseja ingressar o
computador no domínio usando um dos métodos a seguir.
1. Conexão o computador em um segmento da rede com fio que não é

protegida pelo 802.1X e, em seguida, insinte o computador ao domínio.
2. Forneça aos usuários sem fio as etapas e as configurações necessárias para

adicionar seu próprio perfil de inicialização sem fio, o que permite que eles
insinuem o computador ao domínio.
3. Atribua a equipe de IT para ingressar clientes sem fio no domínio.
Suporte de planejamento para vários padrões

A extensão de Políticas de Rede Sem Fio (IEEE 802.11) no Política de Grupo fornece uma
ampla variedade de opções de configuração para dar suporte a uma variedade de
opções de implantação.
Você pode implantar APs sem fio configurados com os padrões aos quais deseja dar
suporte e, em seguida, configurar vários perfis sem fio em Políticas de Rede Sem Fio
(IEEE 802.11), com cada perfil especificando um conjunto de padrões necessários.
Por exemplo, se sua rede tiver computadores sem fio que suportam WPA2-Enterprise e
AES, outros computadores que deem suporte a WPA-Enterprise e AES e outros
computadores que suportam apenas WPA-Enterprise e TKIP, você deverá determinar se
deseja:
Configure um único perfil para dar suporte a todos os computadores sem fio
usando o método de criptografia mais fraco que todos os seus computadores
suportam– nesse caso, WPA-Enterprise e TKIP.
Configure dois perfis para fornecer a melhor segurança possível com suporte em
cada computador sem fio. Nesse caso, você configuraria um perfil que especifica a
criptografia mais forte (WPA2-Enterprise e AES) e um perfil que usa a criptografia
WPA-Enterprise e TKIP mais fracas. Neste exemplo, é essencial que você coloque o
perfil que usa WPA2-Enterprise E AES mais alto na ordem de preferência. Os
computadores que não são capazes de usar o WPA2-Enterprise e o AES ignorarão
automaticamente para o próximo perfil na ordem de preferência e processarão o
perfil que especifica WPA-Enterprise e TKIP.
） Importante
Você deve colocar o perfil com os padrões mais seguros mais altos na lista
ordenada de perfis, pois os computadores que se conectam usam o primeiro perfil
que eles são capazes de usar.
Planejando o acesso restrito à rede sem fio

Em muitos casos, talvez você queira fornecer aos usuários sem fio diferentes níveis de
acesso à rede sem fio. Por exemplo, talvez você queira permitir acesso irrestrito a alguns
usuários, a qualquer hora do dia, todos os dias da semana. Para outros usuários, talvez
você queira apenas permitir o acesso durante o horário principal, de segunda a sexta-
feira e negar acesso aos sábados e aos domingo.
Este guia fornece instruções para criar um ambiente de acesso que coloca todos os
usuários sem fio em um grupo com acesso comum a recursos sem fio. Você cria um
grupo de segurança de usuários sem fio no snap-in Usuários e Computadores do Active
Directory e, em seguida, torna cada usuário para o qual você deseja conceder acesso
sem fio a um membro desse grupo.
Ao configurar políticas de rede NPS, você especifica o grupo de segurança de usuários

sem fio como o objeto que o NPS processa ao determinar a autorização.
No entanto, se sua implantação exigir suporte para diferentes níveis de acesso, você só
precisará fazer o seguinte:
1. Crie mais de um Grupo de Segurança de Usuários Sem Fio para criar grupos de
segurança sem fio adicionais Usuários e Computadores do Active Directory. Por
exemplo, você pode criar um grupo que contém usuários que têm acesso
completo, um grupo para aqueles que só têm acesso durante o horário de
trabalho regular e outros grupos que se ajustam a outros critérios que
corresponderem aos seus requisitos.
2. Adicione usuários aos grupos de segurança apropriados que você criou.
3. Configure políticas de rede NPS adicionais para cada grupo de segurança sem fio
adicional e configure as políticas para aplicar as condições e restrições necessárias
para cada grupo.
Métodos de planejamento para adicionar novos

computadores sem fio
O método preferencial para ingressar novos computadores sem fio no domínio e, em
seguida, fazer logon no domínio é usar uma conexão com fio para um segmento da
LAN que tem acesso a controladores de domínio e não é protegido por um comutdor
Ethernet de autenticação 802.1X.
Em alguns casos, no entanto, pode não ser prático usar uma conexão com fio para
ingressar computadores no domínio ou, para que um usuário use uma conexão com fio
para sua primeira tentativa de logoff usando computadores que já ingressaram no
domínio.
Para ingressar um computador no domínio usando uma conexão sem fio ou para que os
usuários faça logoff no domínio pela primeira vez usando um computador ingressado
no domínio e uma conexão sem fio, os clientes sem fio devem primeiro estabelecer uma
conexão com a rede sem fio em um segmento que tenha acesso aos controladores de
domínio de rede usando um dos métodos a seguir.
1. Um membro da equipe de IT insinuou um computador sem fio ao domínio e, em

seguida, configura um perfil sem fio de inicialização de logon único. Com esse
método, um administrador de IT conecta o computador sem fio à rede Ethernet
com fio e, em seguida, une o computador ao domínio. Em seguida, o
administrador distribui o computador para o usuário. Quando o usuário inicia o
computador, as credenciais de domínio especificadas manualmente para o
processo de logon do usuário são usadas para estabelecer uma conexão com a
rede sem fio e fazer logon no domínio.
2. O usuário configura manualmente o computador sem fio com o perfil sem fio
de inicialização e, em seguida, insinuou no domínio. Com esse método, os
usuários configuram manualmente seus computadores sem fio com um perfil sem
fio de inicialização com base nas instruções de um administrador de IT. O perfil
sem fio de inicialização permite que os usuários estabeleçam uma conexão sem fio
e, em seguida, insinuem o computador ao domínio. Depois de ingressar o
computador no domínio e reiniciar o computador, o usuário pode fazer logoff no
domínio usando uma conexão sem fio e suas credenciais de conta de domínio.
Para implantar o acesso sem fio, consulte Implantação de acesso sem fio.
Implantação de acesso sem fio
Siga estas etapas para implantar o acesso sem fio:
Implantar e configurar APs Sem Fio
Criar um grupo de segurança de usuários sem fio
Configurar políticas de rede sem fio (IEEE 802.11)
Configurar NPSs
Unir novos computadores sem fio ao domínio
Implantar e configurar APs Sem Fio

Siga estas etapas para implantar e configurar seus APs sem fio:
Especificar frequências de canal ap sem fio
Configurar APs Sem Fio
７ Observação
Especificar frequências de canal ap sem fio

Ao implantar vários APs sem fio em um único site geográfico, você deve configurar APs
sem fio que têm sinais sobrepostos para usar frequências de canal exclusivas para
reduzir a interferência entre APs sem fio.
Você pode usar as seguintes diretrizes para ajudá-lo a escolher frequências de canal que
não entram em conflito com outras redes sem fio na localização geográfica da rede sem
fio.
Se houver outras organizações que têm escritórios próximos ou no mesmo prédio
que sua organização, identifique se há redes sem fio pertencentes a essas
organizações. Descubra o posicionamento e as frequências de canal atribuídas de
suas APs sem fio, pois você precisa atribuir diferentes frequências de canal às ap's
e você precisa determinar o melhor local para instalar as AP's.
Identifique sinais sem fio sobrepostos em andares adjacentes em sua própria

organização. Depois de identificar áreas de cobertura sobrepostas fora e dentro de
sua organização, atribua frequências de canal para seus APs sem fio, garantindo
que todos os dois APs sem fio com cobertura sobreposta sejam atribuídos a
diferentes frequências de canal.
Configurar APs Sem Fio

Use as informações a seguir junto com a documentação do produto fornecida pelo
fabricante de AP sem fio para configurar seus APs sem fio.
Esse procedimento enumera itens normalmente configurados em uma AP sem fio. Os

nomes dos itens podem variar de acordo com a marca e o modelo e podem ser
diferentes daqueles da lista a seguir. Para obter detalhes específicos, consulte a
documentação da AP sem fio.
Para configurar seus APs sem fio
SSID. Especifique o nome das redes sem fio (por exemplo, ExampleWLAN). Esse é
o nome que é anunciado para clientes sem fio.
Criptografia. Especifique WPA2-Enterprise (preferencial) ou WPA-Enterprise e a

criptografia AES (preferencial) ou TKIP, dependendo de quais versões são
compatíveis com os adaptadores de rede do computador cliente sem fio.
Endereço IP de AP sem fio (estático). Em cada AP, configure um endereço IP

estático exclusivo que se enquadra no intervalo de exclusão do escopo DHCP da
sub-rede. O uso de um endereço excluído da atribuição pelo DHCP impede que o
servidor DHCP atribua o mesmo endereço IP a um computador ou outro
dispositivo.
Máscara de sub-rede. Configure isso para corresponder às configurações de

máscara de sub-rede da LAN à qual você conectou a AP sem fio.
Nome DNS. Alguns APs sem fio podem ser configurados com um nome DNS. O
serviço DNS na rede pode resolver nomes DNS para um endereço IP. Em cada AP
sem fio compatível com esse recurso, insira um nome exclusivo para resolução
DNS.
Serviço DHCP. Se a AP sem fio tiver um serviço DHCP interno, desabilite-o.
Segredo compartilhado RADIUS. Use um segredo compartilhado RADIUS

exclusivo para cada AP sem fio, a menos que você esteja planejando configurar
APs como clientes RADIUS no NPS por grupo. Se você planeja configurar APs por
grupo no NPS, o segredo compartilhado deve ser o mesmo para cada membro do
grupo. Além disso, cada segredo compartilhado usado deve ser uma sequência
aleatória de pelo menos 22 caracteres que mistura letras maiúsculas e minúsculas,
números e pontuação. Para garantir a aleatoriedade, você pode usar um gerador
de caracteres aleatório, como o gerador de caracteres aleatório encontrado no
assistente NPS Configure 802.1X , para criar os segredos compartilhados.
 Dica
Registre o segredo compartilhado para cada AP sem fio e armazene-o em um local

seguro, como um cofre do escritório. Você deve saber o segredo compartilhado
para cada AP sem fio ao configurar clientes RADIUS no NPS.
Endereço IP do servidor RADIUS. Digite o endereço IP do servidor que executa o

NPS.
Porta(s) UDP. Por padrão, o NPS usa as portas UDP 1812 e 1645 para mensagens
de autenticação e portas UDP 1813 e 1646 para mensagens contábeis. É
recomendável que você use essas mesmas portas UDP em seus APs, mas se você
tiver um motivo válido para usar portas diferentes, certifique-se de não apenas
configurar os APs com os novos números de porta, mas também reconfigurar
todos os seus NPSs para usar os mesmos números de porta que os APs. Se os APs
e os NPSs não estiverem configurados com as mesmas portas UDP, o NPS não
poderá receber ou processar solicitações de conexão dos APs e todas as tentativas
de conexão sem fio na rede falharão.
VSAs. Alguns APs sem fio exigem que os VSAs (atributos específicos do
fornecedor) forneçam a funcionalidade completa de AP sem fio. OS VSAs são
adicionados na política de rede NPS.
Filtragem DHCP. Configure os APs sem fio para impedir que clientes sem fio
enviem pacotes IP da porta UDP 68 para a rede, conforme documentado pelo
fabricante de AP sem fio.
Filtragem DNS. Configure os APs sem fio para impedir que clientes sem fio enviem
pacotes IP da porta TCP ou UDP 53 para a rede, conforme documentado pelo
fabricante de AP sem fio.
Criar grupos de segurança para usuários sem

fio
Siga estas etapas para criar um ou mais grupos de segurança de usuários sem fio e
adicione usuários ao grupo de segurança de usuários sem fio apropriado:
Adicionar usuários ao grupo de segurança sem fio

Você pode usar esse procedimento para criar um grupo de segurança sem fio no snap-
in do Usuários e Computadores do Active Directory Microsoft Management Console
(MMC).

Para criar um grupo de segurança de usuários sem fio

1. Clique em Iniciar, Ferramentas Administrativas e em Usuários e Computadores
do Active Directory. O snap-in Usuários e Computadores do Active Directory é
aberto. Caso ainda não esteja selecionado, clique no nó do seu domínio. Por
exemplo, se o seu domínio for exemplo.com, clique em exemplo.com.
2. No painel de detalhes, clique com o botão direito do mouse na pasta na qual você
deseja adicionar um novo grupo (por exemplo, clique com o botão direito do
mouse em Usuários), aponte para Novo e clique em Grupo.
3. Em Novo Objeto – Grupo, em Nome do grupo, digite o nome do novo grupo. Por
exemplo, digite Grupo Sem Fio.
4. Em Escopo do grupo, selecione uma das seguintes opções:
Local de domínio
Global
Universal
5. Em Tipo de grupo, selecione Segurança.
6. Clique em OK.
Se você precisar de mais de um grupo de segurança para usuários sem fio, repita essas
etapas para criar grupos de usuários sem fio adicionais. Posteriormente, você pode criar
políticas de rede individuais no NPS para aplicar diferentes condições e restrições a cada
grupo, fornecendo-lhes permissões de acesso e regras de conectividade diferentes.
Adicionar usuários ao grupo de segurança de usuários

sem fio
Você pode usar esse procedimento para adicionar um usuário, computador ou grupo ao
seu grupo de segurança sem fio no snap-in Usuários e Computadores do Active
Directory Microsoft Management Console (MMC).

Para adicionar usuários ao grupo de segurança sem fio

1. Clique em Iniciar, Ferramentas Administrativas e em Usuários e Computadores
do Active Directory. O MMC Usuários e Computadores do Active Directory é
aberto. Caso ainda não esteja selecionado, clique no nó do seu domínio. Por
exemplo, se o seu domínio for exemplo.com, clique em exemplo.com.
2. No painel de detalhes, clique duas vezes na pasta que contém seu grupo de
segurança sem fio.
3. No painel de detalhes, clique com o botão direito do mouse no grupo de

segurança sem fio e clique em Propriedades. A caixa de diálogo Propriedades do
grupo de segurança é aberta.
4. Na guia Membros , clique em Adicionar e conclua um dos procedimentos a seguir

para adicionar um computador ou adicionar um usuário ou grupo.
Para adicionar um usuário ou grupo
1. Insira os nomes de objeto a serem selecionados, digite o nome do usuário ou

grupo que você deseja adicionar e clique em OK.
2. Para atribuir a associação de grupo a outros usuários ou grupos, repita a etapa 1
deste procedimento.
Para adicionar um computador
1. Clique em Tipos de Objeto. A caixa de diálogo Tipos de Objeto é aberta.
2. Em tipos de objeto, selecione Computadores e clique em OK.
3. Insira os nomes de objeto a serem selecionados, digite o nome do computador

que você deseja adicionar e clique em OK.
4. Para atribuir a associação de grupo a outros computadores, repita as etapas 1 a 3

deste procedimento.
Configurar políticas de rede sem fio (IEEE

802.11)
Siga estas etapas para configurar políticas de rede sem fio (IEEE 802.11) Política de
Grupo extensão:
Abrir ou adicionar e abrir um objeto Política de Grupo
Ativar políticas padrão de rede sem fio (IEEE 802.11)
Configurar a nova política de rede sem fio
Abrir ou adicionar e abrir um objeto Política de Grupo

Por padrão, o recurso gerenciamento de Política de Grupo é instalado em
computadores que executam Windows Server 2016 quando a função de servidor do
Active Directory Domain Services (AD DS) é instalada e o servidor é configurado como
um controlador de domínio. O procedimento a seguir que descreve como abrir o GPMC
(Console de Gerenciamento de Política de Grupo) no controlador de domínio. Em
seguida, o procedimento descreve como abrir um GPO (objeto de Política de Grupo) de
nível de domínio existente para edição ou criar um GPO de domínio e abri-lo para
edição.

Para abrir ou adicionar e abrir um objeto Política de Grupo

1. No controlador de domínio, clique em Iniciar, clique em Windows Ferramentas
Administrativas e clique em Política de Grupo Gerenciamento. O Console de
Gerenciamento de Política de Grupo é aberto.
2. No painel esquerdo, clique duas vezes na floresta. Por exemplo, clique duas vezes
em Floresta: example.com.
3. No painel esquerdo, clique duas vezes em Domínios e, em seguida, clique duas

vezes no domínio para o qual você deseja gerenciar um objeto de Política de
Grupo. Por exemplo, clique duas vezes em example.com.
4. Realize um dos seguintes procedimentos:
Para abrir um GPO de nível de domínio existente para edição, clique duas
vezes no domínio que contém o objeto Política de Grupo que você deseja
gerenciar, clique com o botão direito do mouse na política de domínio que
você deseja gerenciar, como a Política de Domínio Padrão, e clique em Editar.
Política de Grupo Editor de Gerenciamento é aberto.
Para criar um novo objeto Política de Grupo e abrir para edição, clique com
o botão direito do mouse no domínio para o qual você deseja criar um novo
objeto Política de Grupo e clique em Criar um GPO neste domínio e vincule-
o aqui.
Em Novo GPO, em Nome, digite um nome para o novo objeto de Política de

Grupo e clique em OK.
Clique com o botão direito do mouse no novo objeto Política de Grupo e

clique em Editar. Política de Grupo Editor de Gerenciamento é aberto.
Na próxima seção, você usará Política de Grupo Editor de Gerenciamento para criar uma
política sem fio.
Ativar políticas padrão de rede sem fio (IEEE 802.11)

Este procedimento descreve como ativar as políticas padrão de Rede Sem Fio (IEEE
802.11) usando o GPME (Editor de Gerenciamento de Política de Grupo).
７ Observação
Depois de ativar a versão Windows Vista e Versões Posteriores das Políticas de

Rede Sem Fio (IEEE 802.11) ou da versão do Windows XP, a opção de versão será
removida automaticamente da lista de opções quando você clicar com o botão
direito do mouse em Políticas de Rede Sem Fio (IEEE 802.11). Isso ocorre porque
depois que você seleciona uma versão da política, a política é adicionada no painel
de detalhes do GPME quando você seleciona o nó de Políticas de Rede Sem Fio
(IEEE 802.11). Esse estado permanece, a menos que você exclua a política sem fio,
momento em que a versão da política sem fio retorna ao menu de clique com o
botão direito do mouse para políticas de rede sem fio (IEEE 802.11) no GPME.
Além disso, as políticas sem fio só são listadas no painel de detalhes do GPME
quando o nó de Políticas de Rede Sem Fio (IEEE 802.11) é selecionado.

Para ativar políticas padrão de rede sem fio (IEEE 802.11)

1. Siga o procedimento anterior para abrir ou adicionar e abrir um objeto Política
de Grupo para abrir o GPME.
2. No GPME, no painel esquerdo, clique duas vezes na Configuração do

Computador, clique duas vezes em Políticas, clique duas vezes Windows
Configurações e clique duas vezes em Configurações de Segurança.
3. No Configurações de Segurança, clique com o botão direito do mouse em

Políticas de Rede Sem Fio (IEEE 802.11) e clique em Criar uma nova Política Sem
Fio para Windows Versões Posteriores e Vista.
4. A caixa de diálogo Novas Propriedades da Política de Rede Sem Fio é aberta. No
Nome da Política, digite um novo nome para a política ou mantenha o nome
padrão. Clique em OK para salvar a política. A política padrão é ativada e listada no
painel de detalhes do GPME com o novo nome fornecido ou com o nome padrão
Nova Política de Rede Sem Fio.
5. No painel de detalhes, clique duas vezes em Nova Política de Rede Sem Fio para
abri-la.
Na próxima seção, você pode executar configuração de política, ordem de preferência

de processamento de política e permissões de rede.
Configurar a nova política de rede sem fio

Você pode usar os procedimentos nesta seção para configurar a Política de Rede Sem
Fio (IEEE 802.11). Essa política permite que você defina as configurações de segurança e
autenticação, gerencie perfis sem fio e especifique permissões para redes sem fio que
não estão configuradas como redes preferenciais.
Configurar um perfil de conexão sem fio para PEAP-MS-CHAP v2
Definir a ordem de preferência para perfis de conexão sem fio
Definir permissões de rede
Configurar um perfil de conexão sem fio para PEAP-MS-CHAP v2

Este procedimento fornece as etapas necessárias para configurar um perfil sem fio
PEAP-MS-CHAP v2.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para

concluir este procedimento.
Para configurar um perfil de conexão sem fio para PEAP-MS-CHAP

v2
1. No GPME, na caixa de diálogo propriedades de rede sem fio para a política que
você acabou de criar, na guia Geral e na Descrição, digite uma breve descrição
para a política.
2. Para especificar que a Configuração Automática do WLAN é usada para definir as

configurações do adaptador de rede sem fio, verifique se o serviço de
Configuração Automática da WLAN Windows para clientes está selecionado.
3. Em Conexão para redes disponíveis na ordem dos perfis listados abaixo, clique
em Adicionar e selecione Infraestrutura. A caixa de diálogo Propriedades do
Novo Perfil é aberta.
4. Na caixa de diálogo Propriedades do Novo Perfil , na guia Conexão , no campo

Nome do Perfil , digite um novo nome para o perfil. Por exemplo, digite
Example.com perfil WLAN para Windows 10.
5. No SSID (Nome da Rede), digite o SSID que corresponde ao SSID configurado em

seus APs sem fio e clique em Adicionar.
Se sua implantação utiliza vários SSIDs e cada PA sem fio utiliza as mesmas
configurações de segurança sem fio, repita essa etapa para adicionar o SSID de
cada PA sem fio ao qual você deseja que esse perfil seja aplicado.
Se sua implantação utiliza vários SSIDs e as configurações de segurança para cada

SSID não são correspondentes, configure um perfil separado para cada grupo de
SSIDs que usam as mesmas configurações de segurança. Por exemplo, se você
tiver um grupo de PAs sem fio configurados para usar WPA2-Enterprise e AES, e
outro grupo de PAs sem fio para usar WPA-Enterprise e TKIP, configure um perfil
para cada grupo de PAs sem fio.
6. Se o texto padrão NEWSSID estiver presente, selecione-o e clique em Remover.
7. Se você implantou pontos de acesso sem fio configurados para suprimir o

sinalizador de difusão, selecione Conectar mesmo que não haja difusão na rede.
７ Observação
Habilitar essa opção pode criar um risco de segurança porque os clientes sem
fio investigarão e tentarão conexões com qualquer rede sem fio. Por padrão,
essa configuração não está habilitada.
8. Clique na guia Segurança, clique em Avançado e configure:
a. Para definir as configurações 802.1X avançadas, em IEEE 802.1X, selecione

Aplicar configurações 802.1X avançadas.
Quando as configurações avançadas de 802.1X são impostas, os valores padrão

para o Máximo Eapol-Start Msgs, Período de Espera, Período de Início e
Período de Autenticação são suficientes para implantações sem fio típicas. Por
isso, você não precisa alterar os padrões, a menos que tenha um motivo
específico para fazer isso.
b. Para habilitar o Logon Único, selecione Habilitar Logon Único para esta rede.
c. Os valores padrão restantes em Logon único são suficientes para implantações

sem fio típicas.
d. Em Roaming Rápido, se seu PA sem fio estiver configurado para pré-

autenticação, selecione Esta rede usa pré-autenticação.
9. Para especificar que as comunicações sem fio atendem aos padrões FIPS 140-2,
selecione Executar criptografia no modo certificado FIPS 140-2.
10. Clique em OK para retornar à guia Segurança. Em Selecionar os métodos de

segurança para essa rede, em Autenticação, selecione WPA2-Enterprise se houver
suporte para seus adaptadores de rede de cliente sem fio e AP sem fio. Caso
contrário, selecione WPA-Enterprise.
11. Em Criptografia, se houver suporte para seus adaptadores de rede de cliente sem
fio e AP sem fio, selecione AES-CCMP. Se você estiver usando pontos de acesso e
adaptadores de rede sem fio que dão suporte a 802.11ac, selecione AES-GCMP.
Caso contrário, selecione TKIP.
７ Observação
As configurações de Autenticação e Criptografia devem corresponder às

configurações configuradas em seus APs sem fio. As configurações padrão
para o Modo de Autenticação, Falhas máximas de autenticação e
informações de usuário do Cache para conexões subsequentes com essa
rede são suficientes para implantações sem fio típicas.
12. Em Selecionar método de autenticação de rede, selecione EAP protegido (PEAP),

e clique em Propriedades. A caixa de diálogo Propriedades EAP Protegidas é
aberta.
13. Em Propriedades EAP Protegidas, confirme se Verificar a identidade do servidor

validando se o certificado está selecionado.
14. Em Autoridades de Certificação raiz confiáveis, selecione a AC (autoridade de

certificação raiz) confiável que emitiu o certificado do servidor para o NPS.
７ Observação
Essa configuração limita as ACs raiz que os clientes confiam para as ACs
selecionadas. Se nenhum CAs raiz confiável estiver selecionado, os clientes
confiarão em todos os CAs raiz listados no repositório de certificados
15. Na lista Selecionar Método de Autenticação, selecione Senha segura (EAP-MS-

CHAP v2).
16. Clique em Configurar. Na caixa de diálogo Propriedades EAP MSCHAPv2,

verifique se usar automaticamente meu Windows nome de logon e senha (e
domínio, se houver) está selecionado e clique em OK.
17. Para habilitar a Reconexão Rápida do PEAP, verifique se Habilitar Reconexão

Rápida está selecionado.
18. Para exigir a criptografia de servidor TLV em tentativas de conexão, selecione

Desconectar se o servidor não apresentar TLV de criptografia.
19. Para especificar que a identidade do usuário está mascarada na fase um da

autenticação, selecione Habilitar Privacidade de Identidade e, na caixa de texto,
digite um nome de identidade anônimo ou deixe a caixa de texto em branco.
[! ANOTAÇÕES]
A política NPS para o 802.1X Wireless deve ser criada usando a Política
de Solicitação de Conexão NPS. Se a política NPS for criada usando a
Política de Rede NPS, a privacidade de identidade não funcionará.
A privacidade de identidade EAP é fornecida por determinados métodos
EAP em que uma identidade vazia ou anônima (diferente da identidade
real) é enviada em resposta à solicitação de identidade EAP. O PEAP
envia a identidade duas vezes durante a autenticação. Na primeira fase, a
identidade é enviada em texto sem formatação e essa identidade é usada
para fins de roteamento, não para autenticação do cliente. A identidade
real, usada para autenticação, é enviada durante a segunda fase da
autenticação, dentro do túnel seguro estabelecido na primeira fase. Se a
caixa de seleção Habilitar Privacidade de Identidade estiver selecionada,
o nome de usuário será substituído pela entrada especificada na caixa de
texto. Por exemplo, suponha que Enable Identity Privacy esteja
selecionado e o alias de privacidade de identidade anônimo seja
especificado na caixa de texto. Para um usuário com um alias
jdoe@example.comde identidade real, a identidade enviada na primeira
fase da autenticação será alterada para anonymous@example.com. A
parte realm da identidade da 1ª fase não é modificada, pois é usada para
fins de roteamento.
20. Clique em OK para fechar a caixa de diálogo Propriedades EAP Protegidas .
21. Clique em OK para fechar a guia Segurança .
22. Se você quiser criar perfis adicionais, clique em Adicionar e repita as etapas
anteriores, fazendo escolhas diferentes para personalizar cada perfil para os
clientes sem fio e a rede à qual você deseja que o perfil seja aplicado. Quando
terminar de adicionar perfis, clique em OK para fechar a caixa de diálogo
Propriedades da Política de Rede Sem Fio.
Na próxima seção, você pode ordenar os perfis de política para uma segurança ideal.
Definir a ordem de preferência para perfis de conexão sem fio

Você pode usar esse procedimento se tiver criado vários perfis sem fio em sua política
de rede sem fio e quiser ordenar os perfis para a eficácia e a segurança ideais.
Para garantir que os clientes sem fio se conectem com o mais alto nível de segurança
que podem dar suporte, coloque suas políticas mais restritivas no topo da lista.
Por exemplo, se você tiver dois perfis, um para clientes que dão suporte ao WPA2 e
outro para clientes que dão suporte ao WPA, coloque o perfil WPA2 mais alto na lista.
Isso garante que os clientes que dão suporte ao WPA2 usem esse método para a
conexão em vez do WPA menos seguro.
Este procedimento fornece as etapas para especificar a ordem na qual os perfis de
conexão sem fio são usados para conectar clientes sem fio membros do domínio a
redes sem fio.

Para definir a ordem de preferência para perfis de conexão sem

fio
1. No GPME, na caixa de diálogo propriedades de rede sem fio para a política que
você acabou de configurar, clique na guia Geral .
2. Na guia Geral, em Conexão para redes disponíveis na ordem dos perfis listados
abaixo, selecione o perfil que você deseja mover na lista e clique no botão "seta
para cima" ou "seta para baixo" para mover o perfil para o local desejado na lista.
3. Repita a etapa 2 para cada perfil que você deseja mover na lista.
4. Clique em OK para salvar todas as alterações.
Na seção a seguir, você pode definir permissões de rede para a política sem fio.
Definir permissões de rede

Você pode definir configurações na guia Permissões de Rede para os membros do
domínio aos quais as políticas de Rede Sem Fio (IEEE 802.11) se aplicam.
Você só pode aplicar as seguintes configurações para redes sem fio que não estão
configuradas na guia Geral na página Propriedades da Política de Rede Sem Fio :
Permitir ou negar conexões a redes sem fio específicas que você especificar por
tipo de rede e SSID (Identificador de Conjunto de Serviços)
Permitir ou negar conexões com redes ad hoc
Permitir ou negar conexões com redes de infraestrutura
Permitir ou negar que os usuários exibam tipos de rede (ad hoc ou infraestrutura)
aos quais eles têm acesso negado
Permitir ou negar que os usuários criem um perfil que se aplique a todos os

usuários
Os usuários só podem se conectar a redes permitidas usando perfis Política de
Grupo
A associação a administradores de domínio, ou equivalente, é o mínimo necessário

para concluir esses procedimentos.
Para permitir ou negar conexões a redes sem fio específicas
1. No GPME, na caixa de diálogo propriedades de rede sem fio, clique na guia

Permissões de Rede .
2. Na guia Permissões de Rede , clique em Adicionar. A caixa de diálogo Nova

Entrada de Permissões é aberta.
3. Na caixa de diálogo Nova Entrada de Permissão , no campo SSID (Nome de

Rede), digite o SSID de rede da rede para a qual você deseja definir permissões.
4. No Tipo de Rede, selecione Infraestrutura ou Ad hoc.
７ Observação
Se você não tiver certeza se a rede de difusão é uma infraestrutura ou uma

rede ad hoc, poderá configurar duas entradas de permissão de rede, uma
para cada tipo de rede.
5. Em Permissão, selecione Permitir ou Negar.
6. Clique em OK para retornar à guia Permissões de Rede .
Para especificar permissões de rede adicionais (opcional)
1. Na guia Permissões de Rede , configure qualquer um ou todos os seguintes:
Para negar aos membros do domínio acesso a redes ad hoc, selecione

Impedir conexões com redes ad hoc.
Para negar aos membros do domínio acesso a redes de infraestrutura,

selecione Impedir conexões com redes de infraestrutura.
Para permitir que seus membros de domínio exibam tipos de rede (ad hoc ou
infraestrutura) aos quais eles têm acesso negado, selecione Permitir que o
usuário exiba redes negadas.
Para permitir que os usuários criem perfis que se aplicam a todos os usuários,
selecione Permitir que todos criem todos os perfis de usuário.
Para especificar que os usuários só podem se conectar a redes permitidas

usando perfis Política de Grupo, selecione Usar somente Política de Grupo
perfis para redes permitidas.
Configurar seus NPSs

Siga estas etapas para configurar NPSs para executar a autenticação 802.1X para acesso
sem fio:
Registrar NPS no Active Directory Domain Services
Configurar uma AP Sem Fio como um cliente NPS RADIUS
Criar políticas NPS para o 802.1X Wireless usando um Assistente
Registrar NPS no Active Directory Domain Services

Você pode usar esse procedimento para registrar um servidor executando o NPS
(Servidor de Política de Rede) em Active Directory Domain Services (AD DS) no domínio
em que o NPS é membro. Para que os NPSs sejam autorizados a ler as propriedades de
discagem das contas de usuário durante o processo de autorização, cada NPS deve ser
registrado no AD DS. Registrar um NPS adiciona o servidor ao grupo de segurança RAS
e IAS Servers no AD DS.
７ Observação
Você pode instalar o NPS em um controlador de domínio ou em um servidor

dedicado. Execute o seguinte comando Windows PowerShell para instalar o NPS se
você ainda não tiver feito isso:
PowerShell


1. Em seu NPS, em Gerenciador do Servidor, clique em Ferramentas e, em seguida,
clique no Servidor de Política de Rede. O snap-in NPS é aberto.

Servidor no Active Directory. A caixa de diálogo Servidor de Políticas de Rede é
aberta.
Configurar uma AP Sem Fio como um cliente NPS

RADIUS
Você pode usar esse procedimento para configurar uma AP, também conhecida como
NAS (servidor de acesso à rede), como um cliente RADIUS (Serviço de Usuário Discado de
Autenticação Remota) usando o snap-in NPS.
） Importante
Computadores cliente, como computadores portáteis sem fio e outros

computadores que executam sistemas operacionais cliente, não são clientes
RADIUS. Os clientes RADIUS são servidores de acesso à rede, como pontos de
acesso sem fio, comutadores compatíveis com 802,1X, servidores VPN (rede virtual
privada) e servidores discados, porque usam o protocolo RADIUS para se
comunicar com servidores RADIUS, como NPSs.

Para adicionar um servidor de acesso à rede como um cliente

RADIUS no NPS
1. Em seu NPS, em Gerenciador do Servidor, clique em Ferramentas e, em seguida,
clique no Servidor de Política de Rede. O snap-in NPS é aberto.
2. No snap-in do NPS, clique duas vezes em Clientes RADIUS e Servidores. Clique

com o botão direito do mouse em Clientes RADIUS e clique em Novo.
3. Em Novo Cliente RADIUS, verifique se a caixa de seleção Habilitar esse cliente

RADIUS está selecionada.
4. Em Novo Cliente RADIUS, em nome amigável, digite um nome de exibição para o

ponto de acesso sem fio.
Por exemplo, se você quiser adicionar um AP (ponto de acesso sem fio) chamado
AP-01, digite AP-01.
5. Em Endereço (IP ou DNS), digite o endereço IP ou o FQDN (nome de domínio

totalmente qualificado) para o NAS.
Se você inserir o FQDN, para verificar se o nome está correto e mapear para um
endereço IP válido, clique em Verificar e, em Verificar Endereço, no campo
Endereço , clique em Resolver. Se o nome FQDN for mapeado para um endereço
IP válido, o endereço IP desse NAS será exibido automaticamente no endereço IP.
Se o FQDN não for resolvido para um endereço IP, você receberá uma mensagem
indicando que nenhum host desse tipo é conhecido. Se isso ocorrer, verifique se
você tem o nome AP correto e se a AP está ativada e conectada à rede.
Clique em OK para fechar o Endereço de Verificação.
6. No Novo Cliente RADIUS, em Segredo Compartilhado, faça um dos seguintes

procedimentos:
Para configurar manualmente um segredo compartilhado RADIUS, selecione

Manual e, em segredo compartilhado, digite a senha forte que também é
inserida no NAS. Digite novamente o segredo compartilhado em Confirmar
segredo compartilhado.
Para gerar automaticamente um segredo compartilhado, selecione a caixa de

seleção Gerar e clique no botão Gerar . Salve o segredo compartilhado
gerado e use esse valor para configurar o NAS para que ele possa se
comunicar com o NPS.
） Importante
O segredo compartilhado RADIUS que você insere para suas AP virtuais

no NPS deve corresponder exatamente ao segredo compartilhado
RADIUS configurado em suas APs sem fio reais. Se você usar a opção
NPS para gerar um segredo compartilhado RADIUS, deverá configurar a
AP sem fio real correspondente com o segredo compartilhado RADIUS
gerado pelo NPS.
7. Em Novo Cliente RADIUS, na guia Avançado , no nome do fornecedor,

especifique o nome do fabricante NAS. Se você não tiver certeza do nome do
fabricante nas, selecione RADIUS standard.
8. Em Opções Adicionais, se você estiver usando métodos de autenticação diferentes
de EAP e PEAP e se o NAS der suporte ao uso do atributo autenticador de
mensagem, selecione As mensagens de Solicitação de Acesso deverão conter o
atributo Message-Authenticator.
9. Clique em OK. Seu NAS aparece na lista de clientes RADIUS configurados no NPS.
Criar políticas NPS para 802.1X sem fio usando um

assistente
Você pode usar esse procedimento para criar as políticas de solicitação de conexão e as
políticas de rede necessárias para implantar pontos de acesso sem fio compatíveis com
802,1X como clientes RADIUS (Serviço de Usuário Discado de Autenticação Remota) no
servidor RADIUS que executa o NPS (Servidor de Política de Rede).
Depois de executar o
assistente, as seguintes políticas são criadas:
Uma política de solicitação de conexão
Uma política de rede
７ Observação
Você pode executar o Assistente de Conexões Com Fio Seguro e Sem Fio do New
IEEE 802.1X sempre que precisar criar novas políticas para acesso autenticado
802.1X.

Criar políticas para o 802.1X autenticado sem fio usando um

assistente
1. Abra o snap-in do NPS. Se ainda não estiver selecionado, clique em NPS (Local).
Se você estiver executando o snap-in do NPS MMC e quiser criar políticas em um
NPS remoto, selecione o servidor.
2. Em Introdução, na Configuração Padrão, selecione o servidor RADIUS para

conexões sem fio ou com fio 802.1X. O texto e os links abaixo da alteração de
texto para refletir sua seleção.
3. Clique em Configurar 802.1X. O assistente Configurar 802.1X é aberto.

4. Na página assistente Selecionar Tipo de Conexões 802.1X , em Tipo de conexões
802.1X, selecione Conexões Sem Fio Seguras e, em Nome, digite um nome para
sua política ou deixe o nome padrão Conexões Sem Fio Seguras. Clique em
Avançar.
5. Na página Especificar 802.1X Switches assistente, em clientes RADIUS, todos os

comutadores 802.1X e pontos de acesso sem fio que você adicionou como clientes
RADIUS no snap-in NPS são mostrados. Execute um destes procedimentos:
Para adicionar NASs (servidores de acesso à rede adicionais), como APs sem
fio, em clientes RADIUS, clique em Adicionar e, em seguida, no novo cliente
RADIUS, insira as informações para: Nome amigável, endereço (IP ou DNS) e
Segredo Compartilhado.
Para modificar as configurações de qualquer NAS, em clientes RADIUS,

selecione a AP para a qual você deseja modificar as configurações e clique
em Editar. Modifique as configurações conforme necessário.
Para remover um NAS da lista, em clientes RADIUS, selecione o NAS e clique

em Remover.
２ Aviso
Remover um cliente RADIUS de dentro do assistente Configurar 802.1X

exclui o cliente da configuração do NPS. Todas as adições, modificações
e exclusões que você faz dentro do assistente Configurar 802.1X para
clientes RADIUS são refletidas no snap-in NPS, no nó Clientes RADIUS
em Clientes NPSRADIUS / e Servidores. Por exemplo, se você usar o
assistente para remover um comutador 802.1X, o comutador também
será removido do snap-in do NPS.
6. Clique em Avançar. Na página Configurar um Assistente de Método de

Autenticação, em Tipo (com base no método de acesso e configuração de rede),
selecioneMicrosoft: EAP protegido (PEAP) e clique em Configurar.
 Dica
Se você receber uma mensagem de erro indicando que um certificado não

pode ser encontrado para uso com o método de autenticação e configurou
os Serviços de Certificados do Active Directory para emitir certificados
automaticamente para servidores RAS e IAS em sua rede, primeiro verifique
se você seguiu as etapas para registrar o NPS no Active Directory Domain
Services e, em seguida, use as etapas a seguir para atualizar Política de Grupo:
Clique em Iniciar, clique em Windows Sistema, clique em Executar e, em
Abrir, digite gpupdate e pressione ENTER. Quando o comando retornar
resultados que indicam que o usuário e o computador Política de Grupo
foram atualizados com êxito, selecioneMicrosoft: EAP protegido (PEAP)
novamente e clique em Configurar.
Se depois de atualizar Política de Grupo você continuar recebendo a

mensagem de erro indicando que um certificado não pode ser encontrado
para uso com o método de autenticação, o certificado não será exibido
porque ele não atende aos requisitos mínimos de certificado do servidor,
conforme documentado no Guia Complementar de Rede Principal: Implantar
certificados de servidor para implantações com fio e sem fio 802.1X. Se isso
acontecer, você deve descontinuar a configuração do NPS, revogar o
certificado emitido para seus NPS e, em seguida, seguir as instruções para
configurar um novo certificado usando o guia de implantação de certificados
de servidor.
7. Na página Editar Propriedades do EAP Protegidas , no Certificado emitido,

verifique se o certificado NPS correto está selecionado e faça o seguinte:
７ Observação
Verifique se o valor no Emissor está correto para o certificado selecionado no

Certificado emitido. Por exemplo, o emissor esperado para um certificado
emitido por uma AC que executa o AD CS (Active Directory Certificate
Services) chamado corp\DC1, no domínio contoso.com, é corp-DC1-CA.
Para permitir que os usuários percorram seus computadores sem fio entre os
pontos de acesso sem exigir que eles sejam reautenticados sempre que
associarem a uma nova AP, selecione Habilitar Reconexão Rápida.
Para especificar que a conexão de clientes sem fio encerrará o processo de

autenticação de rede se o servidor RADIUS não apresentar TLV (Tipo-Length-
Value) de criptografia, selecione Desconectar Clientes sem Criptografia.
Para modificar as configurações de política para o tipo EAP, em Tipos EAP,

clique em Editar, em Propriedades EAP MSCHAPv2, modifique as
configurações conforme necessário e clique em OK.
8. Clique em OK. A caixa de diálogo Editar Propriedades EAP Protegidas é fechada,
retornando você para o assistente Configurar 802.1X . Clique em Avançar.
9. Em Especificar Grupos de Usuários, clique em Adicionar e digite o nome do grupo

de segurança configurado para seus clientes sem fio no snap-in Usuários e
Computadores do Active Directory. Por exemplo, se você nomeou seu grupo de
segurança sem fio Grupo Sem Fio, digite Grupo Sem Fio. Clique em Avançar.
10. Clique em Configurar para configurar atributos padrão RADIUS e atributos

específicos do fornecedor para LAN virtual (VLAN), conforme necessário, e
conforme especificado pela documentação fornecida pelo fornecedor de hardware
ap sem fio. Clique em Avançar.
11. Examine os detalhes do resumo da configuração e clique em Concluir.
Suas políticas NPS agora são criadas e você pode passar a unir computadores sem fio
ao domínio.
Unir novos computadores sem fio ao domínio

O método mais fácil para unir novos computadores sem fio ao domínio é anexar
fisicamente o computador a um segmento da LAN com fio (um segmento não
controlado por um comutador 802.1X) antes de ingressar o computador no domínio.
Isso é mais fácil porque as configurações de política de grupo sem fio são aplicadas
automaticamente e imediatamente e, se você implantou sua própria PKI, o computador
recebe o certificado de autoridade de certificação e o coloca no repositório de
certificados autoridades de certificação raiz confiáveis, permitindo que o cliente sem fio
confie em NPSs com certificados de servidor emitidos por sua AC.
Da mesma forma, depois que um novo computador sem fio é unido ao domínio, o
método preferido para os usuários fazer logon no domínio é executar logon usando
uma conexão com fio para a rede.
Outros métodos de junção de domínio

Nos casos em que não é prático ingressar computadores no domínio usando uma
conexão Ethernet com fio ou em casos em que o usuário não pode fazer logon no
domínio pela primeira vez usando uma conexão com fio, você deve usar um método
alternativo.
Configuração do computador da equipe de TI. Um membro da equipe de TI

ingressa um computador sem fio no domínio e configura um perfil sem fio de
inicialização de logon único. Com esse método, o administrador de TI conecta o
computador sem fio à rede Ethernet com fio e une o computador ao domínio. Em
seguida, o administrador distribui o computador para o usuário. Quando o usuário
inicia o computador sem usar uma conexão com fio, as credenciais de domínio
especificadas manualmente para o logon do usuário são usadas para estabelecer
uma conexão com a rede sem fio e fazer logon no domínio.
Para obter mais informações, consulte a seção Ingressar no Domínio e Fazer Logon
usando o Método de Configuração do Computador da Equipe de TI
Configuração de perfil sem fio de inicialização por usuários. O usuário configura

manualmente o computador sem fio com um perfil sem fio de inicialização e
ingressa no domínio, com base nas instruções adquiridas de um administrador de
TI. O perfil sem fio de inicialização permite que o usuário estabeleça uma conexão
sem fio e, em seguida, ingresse no domínio. Depois de ingressar o computador no
domínio e reiniciar o computador, o usuário pode fazer logon no domínio usando
uma conexão sem fio e suas credenciais de conta de domínio.
Para obter mais informações, consulte a seção Ingressar no Domínio e Fazer Logon
usando a Configuração de Perfil Sem Fio bootstrap por usuários.
Ingressar no domínio e fazer logon usando o método de

configuração do computador da equipe de TI
Usuários membros do domínio com computadores cliente sem fio ingressados no
domínio podem usar um perfil sem fio temporário para se conectar a uma rede sem fio
autenticada por 802,1X sem primeiro se conectar à LAN com fio. Esse perfil sem fio
temporário é chamado de perfil sem fio de inicialização.
Um perfil sem fio de inicialização exige que o usuário especifique manualmente suas
credenciais de conta de usuário de domínio e não valide o certificado do servidor
RADIUS (Serviço de Usuário Discado de Autenticação Remota) que executa o NPS
(Servidor de Política de Rede).
Depois que a conectividade sem fio é estabelecida, Política de Grupo é aplicado no

computador cliente sem fio e um novo perfil sem fio é emitido automaticamente. A
nova política usa as credenciais do computador e da conta de usuário para autenticação
do cliente.
Além disso, como parte da autenticação mútua PEAP-MS-CHAP v2 usando o novo perfil
em vez do perfil de inicialização, o cliente valida as credenciais do servidor RADIUS.
Depois de ingressar o computador no domínio, use este procedimento para configurar
um perfil sem fio de inicialização de logon único antes de distribuir o computador sem
fio para o usuário membro do domínio.
Para configurar um perfil sem fio de inicialização de logon único

1. Crie um perfil de inicialização usando o procedimento neste guia chamado
Configurar um perfil de conexão sem fio para PEAP-MS-CHAP v2 e use as
seguintes configurações:
Autenticação PEAP-MS-CHAP v2
Validar o certificado do servidor RADIUS desabilitado
Logon Único habilitado
2. Nas propriedades da Política de Rede Sem Fio na qual você criou o novo perfil de
inicialização, na guia Geral , selecione o perfil de inicialização e clique em Exportar
para exportar o perfil para um compartilhamento de rede, uma unidade flash USB
ou outro local facilmente acessível. O perfil é salvo como um arquivo *.xml no local
especificado.
3. Ingresse o novo computador sem fio no domínio (por exemplo, por meio de uma
conexão Ethernet que não exija autenticação IEEE 802.1X) e adicione o perfil sem
fio de inicialização ao computador usando o comando netsh wlan add profile .
７ Observação
Para obter mais informações, consulte Os comandos netsh para wlan (rede de
área local sem fio) em http://technet.microsoft.com/library/dd744890.aspx.
4. Distribua o novo computador sem fio para o usuário com o procedimento para
"Fazer logon no domínio usando computadores em execução Windows 10".
Quando o usuário inicia o computador, Windows solicita que o usuário insira o nome e
a senha da conta de usuário de domínio. Como o Logon Único está habilitado, o
computador usa as credenciais da conta de usuário de domínio para primeiro
estabelecer uma conexão com a rede sem fio e, em seguida, fazer logon no domínio.
Fazer logon no domínio usando computadores em execução

Windows 10
2. Pressione qualquer tecla no teclado ou clique na área de trabalho. A tela de logon

aparece com um nome de conta de usuário local exibido e um campo de entrada
de senha abaixo do nome. Não faça logon com a conta de usuário local.
3. No canto inferior esquerdo da tela, clique em Outro Usuário. O outro log de

usuário na tela aparece com dois campos, um para nome de usuário e outro para
senha. Abaixo do campo senha está o texto Entrar em: e, em seguida, o nome do
domínio em que o computador está ingressado. Por exemplo, se o domínio for
nomeado example.com, o texto lerá Logon em: EXEMPLO.
4. No nome de usuário, digite o nome de usuário do domínio.
７ Observação
Se a tela Outro Usuário não incluir o texto entrar em: e seu nome de domínio,
você deverá inserir seu nome de usuário no domínio de formato\usuário. Por
exemplo, para fazer logon no domínio example.com com uma conta chamada
User-01, digiteexemplo\User-01.
Ingressar no domínio e fazer logon usando a

configuração de perfil sem fio bootstrap por usuários
Com esse método, você conclui as etapas na seção Etapas Gerais e fornece aos usuários
membros do domínio as instruções sobre como configurar manualmente um
computador sem fio com um perfil sem fio de inicialização. O perfil sem fio de
inicialização permite que o usuário estabeleça uma conexão sem fio e, em seguida,
ingresse no domínio. Depois que o computador for ingressado no domínio e reiniciado,
o usuário poderá fazer logon no domínio por meio de uma conexão sem fio.
Etapas gerais
1. Configure uma conta de administrador de computador local, em Painel de
Controle, para o usuário.
） Importante
Para ingressar um computador em um domínio, o usuário deve estar
conectado ao computador com a conta de Administrador local. Como
alternativa, o usuário deve fornecer as credenciais para a conta de
Administrador local durante o processo de ingressar o computador no
domínio. Além disso, o usuário deve ter uma conta de usuário no domínio ao
qual o usuário deseja ingressar no computador. Durante o processo de junção
do computador ao domínio, o usuário será solicitado a obter credenciais de
conta de domínio (nome de usuário e senha).
2. Forneça aos usuários de domínio as instruções para configurar um perfil sem fio
de inicialização, conforme documentado no procedimento a seguir para
configurar um perfil sem fio de inicialização.
3. Além disso, forneça aos usuários as credenciais do computador local (nome de

usuário e senha) e as credenciais de domínio (nome de conta de usuário de
domínio e senha) no formulário DomainName\UserName, bem como os
procedimentos para "Ingressar o computador no domínio" e para "Fazer logon no
domínio", conforme documentado no Guia de Rede principal do Windows Server
2016.
Para configurar um perfil sem fio de inicialização
1. Use as credenciais fornecidas pelo administrador de rede ou pelo profissional de

suporte de TI para fazer logon no computador com a conta de Administrador do
computador local.
2. Clique com o botão direito do mouse no ícone de rede na área de trabalho e

clique em Abrir Rede e Centro de Compartilhamento. A Central de Rede e
Compartilhamento será aberta. Em Alterar as configurações de rede, clique em
Configurar uma nova conexão ou rede. A caixa de diálogo Configurar uma
Conexão ou Rede é aberta.
3. Clique manualmente em conectar-se a uma rede sem fio e clique em Avançar.
4. Na conexão manual a uma rede sem fio, no nome da rede, digite o nome SSID da
AP.
5. No tipo de segurança, selecione a configuração fornecida pelo administrador.
6. No tipo criptografia e na Chave de Segurança, selecione ou digite as

configurações fornecidas pelo administrador.
7. Selecione Iniciar essa conexão automaticamente e clique em Avançar.

8. Em SSID de Rede adicionadacom êxito, clique em Alterar configurações de
conexão.
9. Clique em Alterar configurações de conexão. A caixa de diálogo da propriedade

Rede Sem Fio SSID de Rede de Rede é aberta.
10. Clique na guia Segurança e, em Escolher um método de autenticação de rede,

selecione PEAP (Protected EAP).
11. Clique em Configurações. A página Propriedades do PEAP (Protected EAP) é

aberta.
12. Na página Propriedades do PEAP (Protected EAP ), verifique se o certificado do

servidor validado não está selecionado, clique em OK duas vezes e clique em
Fechar.
13. Windows tenta se conectar à rede sem fio. As configurações do perfil sem fio de
inicialização especificam que você deve fornecer suas credenciais de domínio.
Quando Windows solicitar um nome de conta e senha, digite suas credenciais de
conta de domínio da seguinte maneira: Nome de Domínio\Nome de Usuário, Senha
de Domínio.
Para ingressar um computador no domínio
2. Na caixa de texto de pesquisa, digite PowerShell. Nos resultados da pesquisa,

clique com o botão direito do mouse em Windows PowerShell e clique em
Executar como administrador. Windows PowerShell é aberto com um prompt
elevado.
3. No Windows PowerShell, digite o comando a seguir e pressione ENTER. Substitua

a variável DomainName pelo nome do domínio que você deseja ingressar.
Add-Computer DomainName
4. Quando solicitado, digite o nome de usuário e a senha do domínio e clique em

OK.
5. Reinicie o computador.
6. Siga as instruções na seção anterior Faça logon no domínio usando computadores

em execução Windows 10.
Implantar o modo Cache Hospedado do
BranchCache
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016,
O Windows Server 2016 De rede principal fornece instruções para planejar e implantar
os componentes principais necessários para uma rede totalmente funcional e um novo
domínio do Active Directory® em uma nova floresta.
Este guia explica como criar na rede principal fornecendo instruções para implantar o
BranchCache no modo de cache hospedado em uma ou mais filiais com um
Controlador de Domínio do Read-Only em que os computadores cliente ® estão
executando o Windows 10, Windows 8.1 ou Windows 8 e são ingressados no domínio.
） Importante
Não use este guia se você estiver planejando implantar ou já implantou um

servidor de cache hospedado do BranchCache que está executando o Windows
Server 2008 R2. Este guia fornece instruções para implantar o modo de cache
hospedado com um servidor de cache hospedado que está executando o Windows
Server® 2016, Windows Server 2012 R2 ou Windows Server 2012.
Sobre este guia
Visão geral da implantação do modo de cache hospedado do BranchCache
Planejamento de implantação do modo de cache hospedado do BranchCache
Implantação do modo de cache hospedado do BranchCache
Recursos adicionais
Este é um guia de adoção para o Windows Server 2016 Core Network Guide. Para
implantar o BranchCache no modo de cache hospedado com este guia, você deve
primeiro fazer o seguinte.
Implantar uma rede principal em seu escritório principal usando o Guia da rede
principal, ou já ter as tecnologias fornecidas no Guia da rede principal instaladas e
funcionando corretamente em sua rede. Essas tecnologias incluem TCP/IP v4,
DHCP, Active Directory Domain Services (AD DS) e DNS.
７ Observação
O Windows Server 2016 De rede principal está disponível na biblioteca

Windows Server 2016 técnica.
Implante servidores de conteúdo do BranchCache que estão executando Windows

Server 2016, Windows Server 2012 R2 ou Windows Server 2012 em seu escritório
principal ou em uma nuvem data center. Para obter informações sobre como
implantar servidores de conteúdo do BranchCache, consulte Recursos adicionais.
Estabelecer conexões de WAN (Rede de Longa Distância) entre o escritório da filial,

o escritório principal e, se apropriado, seus recursos de nuvem, usando uma VPN
(Rede Virtual Privada), o DirectAccess ou outro método de conexão.
Implante computadores cliente em sua filial que estão executando um dos

seguintes sistemas operacionais, que fornecem ao BranchCache suporte para
Serviço de Transferência Inteligente em Segundo Plano (BITS), PROTOCOLO HTTP e
protocolo SMB.
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
O Windows 8 Enterprise
７ Observação
Nos sistemas operacionais a seguir, o BranchCache não dá suporte à

funcionalidade HTTP e SMB, mas dá suporte à funcionalidade Bits do BranchCache.
- Windows 10 Pro, suporte somente bits - Windows 8.1 Pro, suporte bits somente -
Windows 8 Pro, suporte somente bits
Sobre este guia
Este guia foi projetado para administradores de rede e sistema que seguiram as
instruções no Guia de Rede Principal do Windows Server 2016 ou no Guia de Rede
Principal do Windows Server 2012 para implantar uma rede principal ou para aqueles
que implantaram anteriormente as tecnologias incluídas no Guia de Rede Principal,
incluindo Active Directory Domain Services (AD DS), DNS (Serviço de Nome de
Domínio), DHCP (Dynamic Host Configuration Protocol) e TCP/IP v4.
É recomendável que você examine os guias de design e implantação de cada uma das
tecnologias usadas neste cenário de implantação. Esses guias podem ajudar a
determinar se o cenário de implantação fornece os serviços e as configurações que você
precisa para a rede de sua organização.

Este guia não fornece informações conceituais sobre o BranchCache, incluindo
informações sobre recursos e modos do BranchCache.
Este guia não fornece informações sobre como implantar conexões WAN ou outras
tecnologias de filial, como DHCP, um RODC ou um servidor VPN.
Além disso, este guia não fornece orientação sobre o hardware que você deve usar ao
implantar um servidor de cache hospedado. É possível executar outros serviços e
aplicativos no seu servidor de cache hospedado. No entanto, você deve determinar,
com base na carga de trabalho, nos recursos de hardware e no tamanho da filial, se
quer instalar o servidor de cache hospedado do BranchCache em determinado
computador e quanto espaço em disco alocar para o cache.
Este guia não fornece
instruções para configurar computadores que estão executando Windows 7. Se você
tiver computadores cliente que executam o Windows 7 em suas filiais, deverá configurá-
los usando procedimentos diferentes daqueles fornecidos neste guia para
computadores cliente que executam Windows 10, Windows 8.1 e Windows 8.
Além disso, se você tiver computadores que executam o Windows 7, deverá configurar
o servidor de cache hospedado com um certificado de servidor emitido por uma
autoridade de certificação em que os computadores cliente confiam. (Se todos os seus
computadores cliente estão executando Windows 10, Windows 8.1 ou Windows 8, você
não precisa configurar o servidor de cache hospedado com um certificado do servidor.)
） Importante
Se os servidores de cache hospedados estão executando o Windows Server 2008
R2, use o Guia de Implantação do BranchCache do Windows Server 2008 R2 em
vez deste guia para implantar o BranchCache no modo de cache hospedado.
Aplique as Política de Grupo configurações descritas nesse guia a todos os clientes
do BranchCache que estão executando versões do Windows do Windows 7 ao
Windows 10. Computadores que executam Windows Server 2008 R2 não podem
ser configurados usando as etapas neste guia.

Para este guia complementar, o BranchCache é a única tecnologia que você precisa
instalar e configurar. Você deve executar comandos de BranchCache do Windows
PowerShell nos servidores de conteúdo, como servidores Web e de arquivos, porém
você não precisa alterar nem reconfigurar os servidores de conteúdo de qualquer outra
forma. Além disso, você deve configurar computadores cliente usando Política de Grupo
em seus controladores de domínio que estão executando AD DS em Windows Server
2016, Windows Server 2012 R2 ou Windows Server 2012.
BranchCache
ampla área) incluída em algumas edições dos sistemas operacionais Windows Server
2016 e Windows 10, bem como em algumas edições do Windows Server 2012 R2,
Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008 R2 e Windows 7.
Para otimizar a largura de banda da WAN quando os usuários acessam o conteúdo em

servidores remotos, o BranchCache baixa o conteúdo solicitado pelo cliente do
escritório principal ou dos servidores de conteúdo de nuvem hospedados e armazena
em cache o conteúdo em locais de filiais, permitindo que outros computadores cliente
em filiais acessem o mesmo conteúdo localmente em vez da WAN.
Quando você implanta o BranchCache no modo de cache hospedado, deve configurar

computadores cliente na filial como clientes do modo de cache hospedado e, em
seguida, implantar um servidor de cache hospedado na filial. Este guia demonstra como
implantar o servidor de cache hospedado com conteúdo com hash e pré-carregados de
servidores de conteúdo baseados em servidor e arquivo.
Política de Grupo
Política de Grupo em Windows Server 2016, Windows Server 2012 R2 e Windows Server
2012 é uma infraestrutura usada para fornecer e aplicar uma ou mais configurações de
política desejadas a um conjunto de usuários e computadores direcionados em um
ambiente do Active Directory.
Essa infraestrutura consiste em um mecanismo Política de Grupo e várias CSEs

(extensões do lado do cliente) que são responsáveis por ler as configurações de política
em computadores cliente de destino.
A Política de Grupo é usada neste cenário para configurar computadores cliente

membros do domínio com modo de cache hospedado do BranchCache.
Para continuar com este guia, consulte Visão geral da implantação do modo de cache
hospedado do BranchCache.
Visão geral da implantação do modo de
cache hospedado BranchCache
Você pode usar este guia para implantar um servidor de cache hospedado do
BranchCache em uma filial onde os computadores são ingressados em um domínio.
Você pode usar este tópico para obter uma visão geral do processo de implantação do
Modo de Cache Hospedado do BranchCache.
Essa visão geral inclui a infraestrutura branchcache de que você precisa, bem como uma
visão geral passo a passo simples da implantação.
Infraestrutura de implantação do Servidor de

Cache Hospedado
Nesta implantação, o servidor de cache hospedado é implantado usando pontos de
conexão de serviço no AD DS (Active Directory Domain Services) e você tem a opção
com o BranchCache em Windows Server 2016, Windows Server 2012 R2 e Windows
Server 2012 , para pré-exibir o conteúdo compartilhado em servidores de conteúdo
baseados na Web e em arquivos, pré-carregar o conteúdo em servidores de cache
hospedados.
A ilustração a seguir mostra a infraestrutura necessária para implantar um servidor de

cache hospedado do BranchCache.
） Importante
Embora essa implantação exiba servidores de conteúdo em um data center de

nuvem, você pode usar este guia para implantar um servidor de cache hospedado
do BranchCache, independentemente de onde você implantar seus servidores de
conteúdo – em seu escritório principal ou em um local de nuvem.
HCS1 na filial
Você deve configurar esse computador como um servidor de cache hospedado. Se você
optar por pré-exibir dados do servidor de conteúdo para que possa pré-carregar o
conteúdo em seus servidores de cache hospedados, poderá importar pacotes de dados
que contenham o conteúdo de seus servidores Web e de arquivos.
WEB1 no data center de nuvem

WEB1 é um servidor de conteúdo habilitado para BranchCache. Se você optar por pré-
exibir dados do servidor de conteúdo para que possa pré-carregar o conteúdo em seus
servidores de cache hospedados, poderá pré-exibir o conteúdo compartilhado na WEB1
e, em seguida, criar um pacote de dados copiado para o HCS1.
FILE1 no data center de nuvem

FILE1 é um servidor de conteúdo habilitado para BranchCache. Se você optar por pré-
exibir dados do servidor de conteúdo para que possa pré-carregar o conteúdo em seus
servidores de cache hospedados, poderá pré-exibir o conteúdo compartilhado em FILE1
e, em seguida, criar um pacote de dados copiado para o HCS1.
DC1 no escritório principal

DC1 é um controlador de domínio e você deve configurar a Política de Domínio Padrão
ou outra política mais apropriada para sua implantação, com o BranchCache Política de
Grupo configurações para habilitar a Descoberta Automática de Cache Hospedado pelo
Ponto de Conexão de Serviço.
Quando os computadores cliente na ramificação Política de Grupo atualizados e essa

configuração de política é aplicada, eles localizam e começam automaticamente a usar
o servidor de cache hospedado na filial.
Computadores cliente na filial

Você deve atualizar Política de Grupo em computadores cliente para aplicar novas
configurações do BranchCache Política de Grupo e permitir que os clientes localizem e
usem o servidor de cache hospedado.
Visão geral do processo de implantação do

Servidor de Cache Hospedado
７ Observação
Os detalhes de como executar essas etapas são fornecidos na seção BranchCache

Hosted Cache Mode Deployment.
O processo de implantação de um Servidor de Cache Hospedado do BranchCache

ocorre nestes estágios:
７ Observação
Algumas das etapas abaixo são opcionais, como as etapas que demonstram como
pré-exibir e pré-carregar conteúdo em servidores de cache hospedados. Quando
você implanta o BranchCache no modo de cache hospedado, não é necessário pré-
exibir conteúdo nos servidores de conteúdo da Web e do arquivo, criar um pacote
de dados e importar o pacote de dados para pré-carregar os servidores de cache
hospedados com conteúdo. As etapas são indicadas como opcionais nesta seção e
na seção Implantação do Modo de Cache Hospedado do BranchCache para que
você possa ignorá-las se preferir.
1. No HCS1, use Windows PowerShell comandos para configurar o computador

como um servidor de cache hospedado e registrar um Ponto de Conexão de
Serviço no Active Directory.
2. (Opcional) No HCS1, se os valores padrão do BranchCache não corresponderem às

suas metas de implantação para o servidor e o cache hospedado, configure a
quantidade de espaço em disco que você deseja alocar para o cache hospedado.
Configure também o local do disco que você prefere para o cache hospedado.
3. (Opcional) Pré-exibir conteúdo em servidores de conteúdo, criar pacotes de dados

e pré-carregar conteúdo no servidor de cache hospedado.
７ Observação
O pré-rastreamento e o pré-carregamento de conteúdo no servidor de cache

hospedado são opcionais, no entanto, se você optar por pré-ativar e pré-
carregar, deverá executar todas as etapas abaixo aplicáveis à sua implantação.
(Por exemplo, se você não tiver servidores Web, não precisará executar
nenhuma das etapas relacionadas ao pré-rastreamento e pré-carregamento
do conteúdo do servidor Web.)
a. Na WEB1, preaguiça o conteúdo do servidor Web e crie um pacote de dados.
b. Em FILE1, prehash file server content and create a data package.
c. De WEB1 e FILE1, copie os pacotes de dados para o servidor de cache

hospedado HCS1.
d. No HCS1, importe os pacotes de dados para pré-carregar o cache de dados.
4. No DC1, configure computadores cliente da filial ingressados no domínio para o

modo de cache hospedado configurando Política de Grupo com as configurações
de política do BranchCache.
5. Em computadores cliente, atualize Política de Grupo.
Para continuar com este guia, consulte o Planejamento de Implantação do Modo de

Cache Hospedado do BranchCache.
Planejamento da implantação do modo
de cache hospedado BranchCache
Você pode usar este tópico para planejar sua implantação do BranchCache no modo
cache hospedado.
） Importante
O servidor de cache hospedado deve estar executando Windows Server 2016,

Windows Server 2012 R2 ou Windows Server 2012.
Antes de implantar o servidor de cache hospedado, você deve planejar os seguintes

itens:
Planejar o local e o tamanho do cache hospedado
Planejar o compartilhamento para o qual os pacotes do servidor de conteúdo

devem ser copiados
Planejar a criação de pacotes de dados e prehashing em servidores de conteúdo

Se você estiver planejando usar um servidor existente em sua filial como seu servidor de
cache hospedado, não será necessário executar essa etapa de planejamento, pois o
computador já foi nomeado e tem uma configuração de endereço IP.
Depois de instalar Windows Server 2016 no servidor de cache hospedado, você deve
renomear o computador e atribuir e configurar um endereço IP estático para o
computador local.
７ Observação
Neste guia, o servidor de cache hospedado é denominado HCS1, no entanto, você
deve usar um nome de servidor apropriado para sua implantação.

Se você estiver planejando usar um servidor existente em sua filial como seu servidor de
cache hospedado, não precisará executar essa etapa de planejamento, a menos que o
computador não esteja ingressado no domínio no momento.

Além disso, você deve ingressar o computador no domínio com uma conta que tenha a
associação de grupo apropriada.
Planejar o local e o tamanho do cache

hospedado
No HCS1, determine onde no servidor de cache hospedado você deseja localizar o
cache hospedado. Por exemplo, decida o disco rígido, o volume e o local da pasta em
que você planeja armazenar o cache.
Além disso, decida qual percentual de espaço em disco você deseja alocar para o cache
hospedado.
Planejar o compartilhamento para o qual os

pacotes do servidor de conteúdo devem ser
copiados
Depois de criar pacotes de dados em seus servidores de conteúdo, você deve copiá-los
pela rede para um compartilhamento no servidor de cache hospedado.
Planeje o local da pasta e as permissões de compartilhamento para a pasta

compartilhada. Além disso, se os servidores de conteúdo hospedarem uma grande
quantidade de dados e os pacotes que você criar serão arquivos grandes, planeje
executar a operação de cópia fora do horário de pico para que a largura de banda wan
não seja consumida pela operação de cópia durante um período em que outras pessoas
precisem usar a largura de banda para operações normais de negócios.
Planejar a criação de pacotes de dados e
prehashing em servidores de conteúdo
Antes de pré-acesso ao conteúdo em seus servidores de conteúdo, você deve identificar
as pastas e arquivos que contêm o conteúdo que você deseja adicionar ao pacote de
dados.
Além disso, você deve planejar o local da pasta local em que você pode armazenar os
pacotes de dados antes de copiá-los para o servidor de cache hospedado.
Para continuar com este guia, consulte Implantação do Modo de Cache Hospedado do
BranchCache.
Implantação do modo de cache
hospedado BranchCache
Você pode usar este tópico para links para tópicos de procedimento detalhados que
orientam você pelo processo de implantação do modo de cache hospedado do
BranchCache.
Siga estas etapas para implantar o modo de cache hospedado do BranchCache.
Instalar o recurso BranchCache e configurar o servidor de cache hospedado por

ponto de conexão de serviço
Mover e reorganizar o cache hospedado (opcional)
Pré-hash e conteúdo de pré-carregamento no servidor de cache hospedado

(opcional)
Configurar a descoberta automática de cache hospedado do cliente por ponto de

conexão de serviço
７ Observação
Para continuar com este guia, consulte Instalar o recurso BranchCache e Configurar o
servidor de cache hospedado por ponto de conexão de serviço.
Instalar o recurso BranchCache e
configurar o servidor de cache
hospedado por ponto de conexão de
serviço
Você pode usar esse procedimento para instalar o recurso BranchCache em seu servidor
de cache hospedado, HCS1, e configurar o servidor para registrar um SCP (Ponto de
Conexão de Serviço) no Active Directory Domain Services (AD DS).
Quando você registra servidores de cache hospedados com um SCP no AD DS, o SCP
permite que os computadores cliente configurados corretamente descubram
automaticamente os servidores de cache hospedados consultando AD DS para o SCP.
Instruções sobre como configurar computadores cliente para executar essa ação são
fornecidas posteriormente neste guia.
） Importante
Antes de executar este procedimento, você deve ingressar o computador no

domínio e configurar o computador com um endereço IP estático.
Para executar esse procedimento, é necessário ser membro do grupo Administradores.
Para instalar o recurso BranchCache e

configurar o servidor de cache hospedado
1. No computador do servidor, execute Windows PowerShell como administrador.
Digite o comando a seguir e pressione ENTER.
Install-WindowsFeature BranchCache
2. Para configurar o computador como um servidor de cache hospedado após a

instalação do recurso BranchCache e registrar um Ponto de Conexão de Serviço no
AD DS, digite o comando a seguir no Windows PowerShell e pressione ENTER.
Enable-BCHostedServer -RegisterSCP
3. Para verificar a configuração do servidor de cache hospedado, digite o comando a

seguir e pressione ENTER.
Get-BCStatus
Os resultados do comando exibem o status de todos os aspectos da instalação do

BranchCache. A seguir estão algumas das configurações do BranchCache e o valor
correto para cada item:
BranchCacheIsEnabled: True
HostedCacheServerIsEnabled: True
HostedCacheScpRegistrationEnabled: True
4. Para se preparar para a etapa de copiar seus pacotes de dados de seus servidores
de conteúdo para seus servidores de cache hospedados, identifique um
compartilhamento existente no servidor de cache hospedado ou crie uma nova
pasta e compartilhe a pasta para que ela seja acessível de seus servidores de
conteúdo. Depois de criar seus pacotes de dados em seus servidores de conteúdo,
você copiará os pacotes de dados para essa pasta compartilhada no servidor de
cache hospedado.
5. Se você estiver implantando mais de um servidor de cache hospedado, repita esse

procedimento em cada servidor.
Para continuar com este guia, consulte Mover e reessular o cache hospedado (opcional).
Mover e redimensionar o cache
hospedado (opcional)
Você pode usar este procedimento para mover o cache hospedado para a unidade e a
pasta que preferir e especificar a quantidade de espaço em disco que o servidor de
cache hospedado pode usar para o cache hospedado.
Esse procedimento é opcional. Se o local de cache padrão

(%windir%\ServiceProfiles\NetworkService\AppData\Local\PeerDistPub) e o tamanho –
que é 5% do espaço total em disco rígido – são apropriados para sua implantação, você
não precisa alterá-los.
Você deve ser membro do grupo Administradores para executar esse procedimento.
Para mover e ressarcar o cache hospedado

1. Abra Windows PowerShell com privilégios de Administrador.
2. Digite o comando a seguir para mover o cache hospedado para outro local no
computador local e pressione ENTER.
） Importante
Antes de executar o comando a seguir, substitua os valores de parâmetro,

como –Path e –MoveTo, por valores apropriados para sua implantação.
Set-BCCache -Path C:\datacache –MoveTo D:\datacache
3. Digite o comando a seguir para reestilizar o cache hospedado (especificamente o

cache de dados) no computador local. Pressione ENTER.
） Importante
Antes de executar o comando a seguir, substitua os valores de parâmetro,
como -Percentage, por valores apropriados para sua implantação.
Set-BCCache -Percentage 20
4. Para verificar a configuração do servidor de cache hospedado, digite o comando a

Get-BCStatus
Os resultados do comando exibem o status de todos os aspectos da instalação do

BranchCache. A seguir estão algumas das configurações do BranchCache e o valor
correto para cada item:
DataCache | CacheFileDirectoryPath: exibe o local do disco rígido que

corresponde ao valor fornecido com o parâmetro –MoveTo do comando
SetBCCache. Por exemplo, se você forneceu o valor D:\datacache, esse valor
será exibido na saída do comando.
DataCache | MaxCacheSizeAsPercentageOfDiskVolume: exibe o número que

corresponde ao valor fornecido com o parâmetro –Percentage do comando
SetBCCache. Por exemplo, se você forneceu o valor 20, esse valor será exibido
na saída do comando.
Para continuar com este guia, consulte Prehash and Preload Content on the Hosted
Cache Server (Opcional).
Realizar hash prévio e pré-carregar
conteúdo no servidor de cache
Você pode usar os procedimentos nesta seção para pré-hash de conteúdo em seus
servidores de conteúdo, adicionar o conteúdo a pacotes de dados e, em seguida, pré-
carregar o conteúdo em seus servidores de cache hospedados.
Esses procedimentos são opcionais porque você não precisa pré-hash e pré-carregar
conteúdo em seus servidores de cache hospedados.
Se você não pré-carregar conteúdo, os dados serão adicionados ao cache hospedado

automaticamente à medida que os clientes os baixarem pela conexão WAN.
） Importante
Embora esses procedimentos sejam coletivamente opcionais, se você decidir pré-

hash e pré-carregar conteúdo em seus servidores de cache hospedados, a
execução de ambos os procedimentos será necessária.
Criar pacotes de dados do servidor de conteúdo para conteúdo da Web e do

arquivo (opcional)
Importar pacotes de dados no servidor de cache hospedado (opcional)
Para continuar com este guia, consulte Criar pacotes de dados do servidor de conteúdo
para conteúdo da Web e do arquivo (opcional).
Criar pacotes de dados do servidor de
conteúdo para conteúdo da Web e do
arquivo (opcional)
Você pode usar este procedimento para fazer o hash de conteúdo em servidores Web e
de arquivos e, em seguida, criar pacotes de dados para importar no servidor de cache
hospedado.
Esse procedimento é opcional porque não é necessário prefazer hash e pré-carregar

conteúdo em seus servidores de cache hospedados. Se você não pré-carregar o
conteúdo, os dados são adicionados automaticamente ao cache hospedado, pois os
clientes o baixam pela conexão WAN.
Este procedimento fornece instruções para o conteúdo de prehash em servidores de

arquivos e servidores Web. Se você não tiver um desses tipos de servidores de
conteúdo, não será necessário executar as instruções para esse tipo de servidor de
conteúdo.
） Importante
Antes de executar esse procedimento, você deve instalar e configurar o

BranchCache em seus servidores de conteúdo. Além disso, se você planeja alterar o
segredo do servidor em um servidor de conteúdo, faça isso antes do conteúdo de
pré-processamento, modificar o segredo do servidor invalida hashes gerados
anteriormente.
Para executar esse procedimento, é necessário ser membro do grupo Administradores.
Para criar pacotes de dados do servidor de

conteúdo
1. Em cada servidor de conteúdo, localize as pastas e os arquivos que você deseja
prehash e adicione a um pacote de dados. Identifique ou crie uma pasta na qual
você deseja salvar o pacote de dados posteriormente neste procedimento.
2. no computador servidor, abra Windows PowerShell com privilégios de

administrador.
3. Execute um ou ambos os itens a seguir, dependendo dos tipos de servidores de

conteúdo que você tem:
７ Observação
O valor do parâmetro – Path é a pasta na qual o conteúdo está localizado.

Você deve substituir os valores de exemplo nos comandos abaixo por um
local de pasta válido no servidor de conteúdo que contém os dados que você
deseja prehash e adicionar a um pacote.
Se o conteúdo que você deseja prehash estiver em um servidor de arquivos,

digite o comando a seguir e pressione ENTER.
Publish-BCFileContent -Path D:\share -StageData
Se o conteúdo que você deseja prehash estiver em um servidor Web, digite o

comando a seguir e pressione ENTER.
Publish-BCWebContent –Path D:\inetpub\wwwroot -StageData
4. Crie o pacote de dados executando o comando a seguir em cada um dos seus

servidores de conteúdo. Substitua o valor de exemplo (D:\temp) para o parâmetro
– Destination pelo local que você identificou ou criou no início deste
procedimento.
Export-BCDataPackage –Destination D:\temp
5. No servidor de conteúdo, acesse o compartilhamento nos servidores de cache

hospedados em que você deseja pré-carregar o conteúdo e copie os pacotes de
dados para os compartilhamentos nos servidores de cache hospedados.
Para continuar com este guia, consulte importar pacotes de dados no servidor de cache
hospedado (opcional).
Importar pacotes de dados no servidor
de cache hospedado (opcional)
Você pode usar esse procedimento para importar pacotes de dados e pré-carregar
Esse procedimento é opcional porque você não precisa pré-hash e pré-carregar

Se você não carregar previamente o conteúdo, os dados serão adicionados ao cache

hospedado automaticamente à medida que os clientes os baixarem pela conexão WAN.
Você deve ser membro do grupo Administradores para executar esse procedimento.
Para importar pacotes de dados no servidor de

cache hospedado
1. No computador do servidor, abra Windows PowerShell privilégios de
Administrador.
2. Digite o comando a seguir, substituindo o valor do parâmetro –Path pelo local da

pasta em que você armazenou seus pacotes de dados e pressione ENTER.
Import-BCCachePackage –Path D:\temp\PeerDistPackage.zip
3. Se você tiver mais de um servidor de cache hospedado no qual deseja pré-

carregar conteúdo, execute este procedimento em cada servidor de cache
hospedado.
Para continuar com este guia, consulte Configurar a descoberta automática de cache
hospedado do cliente por ponto de conexão de serviço.
Configurar descoberta automática de
cache hospedado cliente por ponto de
conexão de serviço
Com este procedimento, você pode usar o Política de Grupo para habilitar e configurar
o modo de cache hospedado do BranchCache em computadores ingressados no
domínio que executam os seguintes sistemas operacionais Windows branchCache.
７ Observação
Para configurar computadores ingressados no domínio que estão executando o

Windows Server 2008 R2 ou Windows 7, consulte o Guia de implantação do
BranchCache do Windows Server 2008 R2.

Para usar Política de Grupo configurar clientes para o

modo de cache hospedado
1. Em um computador no qual a função de Active Directory Domain Services servidor
está instalada, abra Gerenciador do Servidor, selecione o Servidor Local, clique em
Ferramentas e clique em Política de Grupo Gerenciamento. O console Política de
Grupo Management é aberto.
2. No console de Gerenciamento do Política de Grupo, expanda o seguinte caminho:

Forest:corp.contoso.com, Domains, corp.contoso.com, Política de Grupo Objects, em
que corp.contoso.com é o nome do domínio em que estão localizadas as contas de
computador cliente do BranchCache que você deseja configurar.
3. Clique com o botão direito do mouse em Objetos de Diretiva de Grupo e clique
em Novo. A caixa de diálogo Novo GPO é aberta. Em Nome, digite um nome para
o novo GPO (Objeto de Diretiva de Grupo). Por exemplo, se desejar denominar o
objeto como Computadores Cliente BranchCache, digite Computadores Cliente
BranchCache. Clique em OK.
4. No Console de Gerenciamento de Diretiva de Grupo, verifique se Objetos de

Diretiva de Grupo está selecionado e, no painel de detalhes, clique com o botão
direito do mouse no GPO que você acabou de criar. Por exemplo, se você
denominou seu GPO como Computadores Cliente BranchCache, clique com o
botão direito do mouse em Computadores Cliente BranchCache. Clique em
Editar. O console Editor de Gerenciamento de Política de Grupo é aberto.
5. No console Editor de Gerenciamento de Política de Grupo, expanda o seguinte

caminho: Configuração do Computador, Políticas, Modelos Administrativos:
Definições de política (arquivos ADMX) recuperados do computador local, Rede,
BranchCache.
6. Clique em BranchCache e, no painel de detalhes, clique duas vezes em Ativar o

BranchCache. A caixa de diálogo Ativar o BranchCache é aberta.
7. Na caixa de diálogo Ativar o BranchCache, clique em Habilitado e em OK.
8. No console Editor de Gerenciamento de Política de Grupo, verifique se

BranchCache ainda está selecionado e, no painel de detalhes, clique duas vezes
em Habilitar Descoberta Automática de Cache Hospedado por Ponto de Conexão
de Serviço. A caixa de diálogo configuração de política é aberta.
9. Na caixa de diálogo Habilitar Descoberta Automática de Cache Hospedado por

Ponto de Conexão de Serviço , clique em Habilitadoe clique emOK.
10. Para permitir que os computadores cliente baixem e armazenam em cache o

conteúdo de servidores de conteúdo baseados em servidor de arquivos
BranchCache: no console do Editor de Gerenciamento de Política de Grupo,
verifique se o BranchCache ainda está selecionado e, em seguida, no painel de
detalhes, clique duas vezes em BranchCache para arquivos de rede. A caixa de
diálogo Configurar o BranchCache para arquivos de rede é aberta.
11. Na caixa de diálogo Configurar o BranchCache para arquivos de rede, clique em

Habilitado. Em Opções, digite um valor numérico, em milissegundos, para o
tempo máximo de latência de rede completa e clique em OK.
７ Observação
Por padrão, os computadores cliente armazenam em cache o conteúdo de
servidores de arquivos se a latência da rede de ida e volta for maior que 80
milissegundos.
12. Para configurar a quantidade de espaço em disco rígido alocado em cada

computador cliente para o cache do BranchCache: no console do Editor de
Gerenciamento de Política de Grupo, verifique se o BranchCache ainda está
selecionado e, em seguida, no painel de detalhes, clique duas vezes em Definir
percentual de espaço em disco usado para o cache do computador cliente. A caixa
de diálogo Definir a porcentagem do espaço em disco usada pelo cache do
computador cliente é aberta. Clique em Habilitado e, em Opções, digite um valor
numérico que represente a porcentagem de espaço no disco rígido usado em cada
computador cliente para o cache do BranchCache. Clique em OK.
13. Para especificar a idade padrão, em dias, para os quais os segmentos são válidos
no cache de dados branchCache em computadores cliente: no console do Editor
de Gerenciamento de Política de Grupo, verifique se BranchCache ainda está
selecionado e, em seguida, no painel de detalhes, clique duas vezes em Definir
idade para segmentos no cache de dados. A caixa de diálogo Definir idade para
segmentos no cache de dados é aberta. Clique em Habilitado e, no painel de
detalhes, digite o número de dias que você preferir. Clique em OK.
14. De acordo com as configurações de política do BranchCache adicionais para

computadores cliente, conforme apropriado para sua implantação.
15. Atualize Política de Grupo computadores cliente da filial executando o comando

gpupdate /force ou reiniciando os computadores cliente.
A implantação do modo cache hospedado do BranchCache agora está concluída.
Para obter informações adicionais sobre as tecnologias neste guia, consulte Recursos
adicionais.
Recursos adicionais do BranchCache
Para obter mais informações sobre as tecnologias discutidas neste guia, consulte os
seguintes recursos:
BranchCache no Windows Server 2016
Instalar e configurar servidores de conteúdo
Shell de rede do BranchCache e comandos do Windows PowerShell
Política de Grupo visão geral do Windows Server 2012 R2
Windows implantação do BranchCache do Windows Server 2008 R2

BranchCache
Este tópico, que é direcionado a profissionais de TI (tecnologia da informação), fornece

informações gerais sobre o BranchCache, incluindo os modos, os recursos e as
capacidades do BranchCache, bem como a funcionalidade do BranchCache disponível
em sistemas operacionais diferentes.
７ Observação
Além deste tópico, a seguinte documentação do BranchCache está disponível.
Shell de rede do BranchCache e comandos do Windows PowerShell

Guia de Implantação do BranchCache
Quem terá interesse no BranchCache?
Se você for administrador do sistema, arquiteto de soluções de rede ou armazenamento

ou outro profissional de TI, o BranchCache poderá ser útil nas seguintes ocasiões:
Durante o design ou suporte de uma infraestrutura de TI para uma organização

com dois ou mais locais físicos e uma conexão por WAN (rede de longa distância)
das filiais para a matriz.
Durante o design ou suporte de uma infraestrutura de TI para uma organização

que implantou tecnologias na nuvem e tem uma conexão por WAN usada por
funcionários para acessar dados e aplicativos em locais remotos.
Você deseja otimizar o uso de largura de banda de WAN por meio da redução da
quantidade de tráfego de rede entre as filiais e a matriz.
Você implantou ou planeja implantar, na matriz, servidores de conteúdo que

correspondam ás configurações descritas neste tópico.
Os computadores cliente em suas filiais estão executando Windows 10, Windows

8.1, Windows 8 ou Windows 7 .
Este tópico inclui as seções a seguir:
O que é BranchCache?
Modos do BranchCache
Servidores de conteúdo habilitados por BranchCache
BranchCache na nuvem
Versões das informações de conteúdo
Como o BranchCache manipula atualizações de conteúdo em arquivos
Guia de instalação do BranchCache
Versões de sistemas operacionais para o BranchCache
Segurança do BranchCache
Processos e fluxo de conteúdo
Segurança de cache
O que é BranchCache?
BranchCache é uma tecnologia de otimização de largura de banda wan (rede de ampla
área) incluída em algumas edições dos sistemas operacionais Windows Server 2016 e
Windows 10, bem como em algumas edições do Windows Server 2012 R2, Windows 8.1,
Windows Server 2012, Windows 8, Windows Server 2008 R2 e Windows 7. Para otimizar
a largura de banda de WAN quando os usuários acessam conteúdo em servidores
remotos, o BranchCache busca o conteúdo dos servidores de conteúdo da matriz ou da
nuvem hospedada e o armazena em cache nas filiais, permitindo que os computadores
cliente das filiais acessem o conteúdo localmente e não pela WAN.
Nas filiais, o conteúdo é armazenado em servidores configurados para hospedar o

cache ou, quando nenhum servidor está disponível na filial, em computadores cliente
que estão executando Windows 10, Windows 8.1, Windows 8 ou Windows 7. Depois que
um computador cliente solicitar e receber o conteúdo da matriz e o conteúdo for
armazenado em cache na filial, outros computadores da mesma filial poderão obter o
conteúdo localmente em vez baixar o conteúdo do servidor de conteúdo pelo link WAN.
Quando solicitações subsequentes do mesmo conteúdo são realizadas pelos

computadores clientes, são baixadas do servidor informações sobre o conteúdo em vez
do conteúdo propriamente dito. As informações de conteúdo consistem em hashes
calculados usando partes do conteúdo original. Elas são extremamente pequenas
quando comparadas ao conteúdo nos dados originais. Os computadores clientes usam
as informações de conteúdo para localizar o conteúdo de um cache na filial, esteja ela
localizada em um computador cliente ou servidor. Os computadores clientes e
servidores também usam informações de conteúdo para proteger conteúdo em cache,
de modo que ele não possa ser acessado por usuários não autorizados.
O BranchCache aumenta a produtividade dos usuários finais, melhorando os tempos de

resposta a consultas de conteúdo para clientes e servidores em filiais. Além disso, ele
também pode ajudar a aprimorar o desempenho de rede por meio da redução do
tráfego por links WAN.
Modos do BranchCache
O BranchCache tem dois modos de operação: o modo de cache distribuído e o modo
de cache hospedado.
Quando você implanta o BranchCache no modo de cache distribuído, o cache de

conteúdo na filial é distribuída entre os computadores clientes.
Quando você implanta o BranchCache no modo de cache hospedado, o cache de

conteúdo em uma filial é hospedado em um ou mais servidores, que são chamados de
servidores de cache hospedado.
７ Observação
Você pode implantar o BranchCache usando os dois modos, mas apenas um deles
pode ser usado por filial. Por exemplo, se você tiver duas filiais, uma com um
servidor e outra sem, será possível implantar o BranchCache no modo de cache
hospedado no escritório que possui o servidor e implantar a solução no modo de
cache distribuído no escritório que tem apenas computadores clientes.
Na ilustração a seguir, o BranchCache é implantado nos dois modos.

O modo de cache distribuído é mais adequado para filiais pequenas que não possuem
servidor local para uso como servidor da cache hospedado. O modo de cache
distribuído permite a implantação do BranchCache nas filiais sem hardware adicional.
Se a filial na qual você deseja implantar o BranchCache contiver infraestrutura adicional,

como um ou mais servidores executando outras cargas de trabalho, a implantação do
BranchCache em modo de cache hospedado será vantajosa pelos seguintes motivos:
Maior disponibilidade de cache

O modo de cache hospedado aumenta a eficiência de cache porque o conteúdo estará
disponível mesmo se o cliente que solicitou e armazenou os dados em cache
originalmente estiver offline. Como o servidor de cache hospedado está sempre
disponível, mais conteúdo é armazenado em cache, proporcionando maiores economias
de largura de banda de WAN e aumentando a eficiência do BranchCache.
Cache centralizado para filiais com várias sub-redes

O modo de cache distribuído funciona em uma única sub-rede. Em uma filial com várias
sub-redes configurada para o modo de cache distribuído, um arquivo baixado em uma
sub-rede não poder ser compartilhado com computadores clientes em outras sub-
redes.
Em função disso, os clientes em outras sub-redes, incapazes de descobrirem que o
arquivo já foi baixado, obtêm o arquivo do servidor de conteúdo da matriz, usando a
largura de banda de WAN no processo.
Porém, não é o caso quando você implanta o modo de cache hospedado, pois todos os
clientes em uma filial com várias sub-redes podem acessar um único cache, armazenado
no servidor de cache hospedado, mesmo que os clientes estejam em sub-redes
diferentes. Além disso, o BranchCache em Windows Server 2016, Windows Server 2012
R2 e Windows Server 2012 fornece a capacidade de implantar mais de um servidor de
cache hospedado por filial.
Ｕ Cuidado
Se você usa o BranchCache para cache SMB de arquivos e pastas, não desabilite
Arquivos Offline. Se você desabilitar Arquivos Offline, o cache SMB do BranchCache
não funcionará corretamente.
Servidores de conteúdo habilitados por

BranchCache
Quando você implanta o BranchCache, o conteúdo de origem é armazenado em
servidores de conteúdo habilitados para BranchCache em seu escritório principal ou em
um data center de nuvem. Os seguintes tipos de servidores de conteúdo são suportados
pelo BranchCache:
７ Observação
Somente o conteúdo de origem - ou seja, o conteúdo que os computadores cliente

obtêm inicialmente de um servidor de conteúdo habilitado para BranchCache - é
acelerado pelo BranchCache. O conteúdo que os computadores clientes obtêm
diretamente de outras origens, como servidores Web na Internet ou Windows
Update, não é armazenado em cache por computadores clientes ou servidores de
cache hospedado, nem compartilhado com outros computadores na filial. No
entanto, se você quiser acelerar Windows Update conteúdo, instale um servidor de
aplicativos Windows Server Update Services (WSUS) em seu escritório principal ou
data center de nuvem e configure-o como um servidor de conteúdo branchCache.
Servidores Web
Os servidores Web com suporte incluem computadores que estão executando Windows
Server 2016, Windows Server 2012 R2, Windows Server 2012 ou Windows Server 2008
R2 que têm a função de servidor do IIS (Servidor Web) instalada e que usam HTTP
(Protocolo de Transferência de Hipertexto) ou HTTP Secure (HTTPS).
Além disso, o servidor Web deve ter o recurso BranchCache instalado.
Servidores de arquivos
Os servidores de arquivos com suporte incluem computadores que estão executando
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 ou Windows
Server 2008 R2 que têm a função de servidor dos Serviços de Arquivos e o serviço de
função BranchCache for Network Files instalado.
Esses servidores de arquivos usam o protocolo SMB (Server Message Block) para trocar
informações entre computadores. Depois de concluir a instalação do servidor de
arquivos, você também deve compartilhar pastas e habilitar a geração de hash para
pastas compartilhadas usando a Política de Grupo ou Política de Grupo Local para
habilitar o BranchCache.
Servidores de aplicativos
Os servidores de aplicativos com suporte incluem computadores que estão executando
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 ou Windows
Server 2008 R2 com o BITS (Serviço de Transferência Inteligente em Segundo Plano)
instalado e habilitado.
Além disso, o servidor de aplicativos deve ter o recurso BranchCache instalado. Como
exemplos de servidores de aplicativos, você pode implantar servidores do Microsoft
Windows Server Update Services (WSUS) e do Microsoft Endpoint Configuration
Manager Branch Distribution Point como servidores de conteúdo branchcache.
BranchCache na nuvem
A nuvem tem um grande potencial de redução das despesas operacionais e obtenção
de novos níveis de dimensionamento. Porém, afastar as cargas de trabalho das pessoas
que dependem delas podem aumentar os custos de rede e prejudicar a produtividade.
Os usuários esperam alto desempenho e não se importam com o local em que seus
aplicativos e dados estão hospedados.
O BranchCache pode aprimorar o desempenho de aplicativos em rede e reduzir o
consumo de largura de banda com um cache compartilhado de dados. Ele aumenta a
produtividade em filiais e matrizes, nas quais os funcionários usam servidores
implantados na nuvem.
Como o BranchCache não exige novo hardware nem mudanças na topologia de rede,
ele é uma solução excelente para melhorar as comunicações entre matrizes em nuvens
privadas ou públicas.
７ Observação
Como alguns proxies da Web não podem processar cabeçalhos de codificação de

conteúdo não padrão, é recomendável que você use BranchCache com HTTPS
(Hyper Text Transfer Protocol Secure) e não HTTP.
======= Para obter mais informações sobre tecnologias de nuvem em Windows

Server 2016, consulte SDN (Rede Definida por Software).
Versões das informações de conteúdo

Há duas versões das informações de conteúdo:
Informações de conteúdo compatíveis com computadores que executam Windows

Server 2008 R2 e Windows 7 são chamadas de versão 1 ou V1. Com a
segmentação de arquivos do BranchCache V1, os segmentos de arquivos são
maiores do que na V2 e possuem tamanho fixo. Por causa dos grandes segmentos
fixos, quando um usuário faz uma alteração que modifica ao tamanho do arquivo,
o segmento com a alteração é invalidado, bem como todos os segmentos no fim
do arquivo. A próxima chamada ao arquivo alterado feita por outro usuário na filial
leva à redução da economia de largura de banda de WAN, pois o conteúdo
alterado e todo o conteúdo após a alteração são enviados pelo link WAN.
Informações de conteúdo compatíveis com computadores que executam Windows

Server 2016, Windows 10, Windows Server 2012 R2, Windows 8.1, Windows Server
2012 e Windows 8 são chamadas de versão 2 ou V2. As informações de conteúdo
V2 utilizam segmentos menores e de tamanho variável, mais tolerantes a
alterações em um arquivo. Isso aumenta a probabilidade de reutilização de
segmentos de uma versão anterior do arquivo quando os usuários acessam uma
versão atualizada, fazendo com que eles recuperem somente a parte alterada do
arquivo do servidor de conteúdo e usem menos largura de banda da WAN.
A tabela a seguir fornece informações sobre a versão de informações de conteúdo
usada, dependendo dos sistemas operacionais de cliente, servidor de conteúdo e
servidor de cache utilizados na implantação do BranchCache.
７ Observação
Na tabela abaixo, o acrônimo "SO" significa sistema operacional.
Sistema operacional SO de SO de servidor de cache Versões das

cliente servidor de hospedado informações de
conteúdo conteúdo
Windows Server 2008 R2 Windows Windows Server 2012 ou V1

e Windows 7 Server 2012 posterior; nenhum para o modo
ou posterior de cache distribuído
Windows Server 2012 ou Windows Windows Server 2012 ou V1

posterior; Windows 8 ou Server 2008 posterior; nenhum para o modo
posterior R2 de cache distribuído
Windows Server 2012 ou Windows Windows Server 2008 R2 V1

posterior; Windows 8 ou Server 2012
posterior ou posterior
Windows Server 2012 ou Windows Windows Server 2012 ou V2

posterior; Windows 8 ou Server 2012 posterior; nenhum para o modo
posterior ou posterior de cache distribuído
Quando você tem servidores de conteúdo e servidores de cache hospedados que estão
executando Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012,
eles usam a versão de informações de conteúdo apropriada com base no sistema
operacional do cliente BranchCache que solicita informações.
Quando computadores que executam Windows Server 2012 e Windows 8 ou sistemas

operacionais posteriores solicitam conteúdo, o conteúdo e os servidores de cache
hospedados usam informações de conteúdo V2; quando os computadores que
executam Windows servidor 2008 R2 e Windows 7 solicitam conteúdo, o conteúdo e os
servidores de cache hospedados usam informações de conteúdo V1.
） Importante
Quando você implanta o BranchCache no modo de cache distribuído, os clientes

que utilizam versões de informações de conteúdo diferentes não compartilham
conteúdo uns com os outros. Por exemplo, um computador cliente executando
Windows 7 e um computador cliente executando Windows 10 instalados na mesma
filial não compartilham conteúdo entre si.
Como o BranchCache manipula atualizações de

conteúdo em arquivos
Quando os usuários da filial modificam ou atualizam o conteúdo dos documentos, suas
alterações são gravadas diretamente no servidor de conteúdo no escritório principal
sem o envolvimento do BranchCache. Isso ocorre independentemente se o usuário
baixou o documento do servidor de conteúdo ou o obteve de um cache distribuído ou
hospedado na filial.
Quando o arquivo modificado é solicitado por um cliente diferente em uma filial, os

novos segmentos do arquivo são baixados do servidor da sede e adicionados ao cache
distribuído ou hospedado na filial. Por isso, os usuários das filiais sempre recebem as
versões mais recentes do conteúdo armazenado em cache.
Guia de instalação do BranchCache

Você pode usar Gerenciador do Servidor em Windows Server 2016 para instalar o
recurso BranchCache ou o serviço de função BranchCache for Network Files da função
de servidor dos Serviços de Arquivos. Você pode usar a tabela a seguir para determinar
se deve instalar o serviço de função ou o recurso.
Funcionalidade Local no Instalar este elemento do BranchCache

computador
Servidor de conteúdo Matriz ou Recurso BranchCache

(servidor de aplicativos com datacenter
base em BITS) na nuvem
Servidor de conteúdo Matriz ou Recurso BranchCache

(servidor Web) datacenter
na nuvem
Servidor de conteúdo Matriz ou Serviço de função BranchCache para Arquivos de

(servidor de arquivos que datacenter Rede da função de servidor Serviços de Arquivo
usa o protocolo SMB) na nuvem
Servidor de cache Filial Recurso BranchCache com modo de servidor de

hospedado cache hospedado habilitado
Funcionalidade Local no Instalar este elemento do BranchCache
computador
Computador cliente Filial Nenhuma instalação é necessária. Basta habilitar o

habilitado por BranchCache BranchCache e um modo BranchCache (distribuído
ou hospedado) no cliente.
Para instalar o serviço de função ou o recurso, abra o Gerenciador do Servidor e

selecione os computadores nos quais deseja habilitar a funcionalidade BranchCache. No
Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções e
Recursos. O assistente Adicionar Funções e Recursos será aberto. Conforme executa o
assistente, faça as seguintes seleções:
Na página do assistente Selecione o tipo de instalação, selecione Instalação

Baseada em Função ou Recursos.
Na página do assistente, selecione Funções de Servidor, se você estiver instalando

um servidor de arquivos habilitado para BranchCache, expanda Serviços de
Arquivo e Armazenamento e Serviços de Arquivo e iSCSI e selecione
BranchCache para Arquivos de Rede. Para economizar espaço em disco, você
também pode selecionar o serviço de função Eliminação de Duplicação de Dados
e, em seguida, continuar por meio do assistente para instalação e conclusão. Se
você não quiser instalar um servidor de arquivos habilitado para BranchCache, não
instale a função Arquivo e Armazenamento Services com o serviço de função
BranchCache for Network Files.
Na página assistente Selecione recursos, se você estiver instalando um servidor de

conteúdo que não é um servidor de arquivos ou estiver instalando um servidor de
cache hospedado, selecione BranchCache e, em seguida, continue por meio do
assistente para instalação e conclusão. Se não quiser instalar um servidor de
conteúdo além do servidor de arquivos ou um servidor de cache hospedado, não
instale o recurso BranchCache.
Versões de sistemas operacionais para o

BranchCache
A seguir está uma lista de sistemas operacionais que dão tipos diferentes de suporte à
funcionalidade BranchCache.
Sistemas operacionais para a funcionalidade de

computador cliente BranchCache
Os sistemas operacionais a seguir fornecem suporte ao BranchCache para BITS (Serviço
de Transferência Inteligente em Segundo Plano), HTTP (Hyper Text Transfer Protocol) e
SMB (Server Message Block).
Windows 7 Ultimate
Nos sistemas operacionais a seguir, o BranchCache não dá suporte à funcionalidade

HTTP e SMB, mas dá suporte à funcionalidade de BITS do BranchCache.
Windows 10 Pro, somente suporte a BITS
Windows 8.1 Pro, somente suporte a BITS
７ Observação
BranchCache não está disponível por padrão nos sistemas operacionais Windows
Server 2008 ou Windows Vista. Nesses sistemas operacionais, no entanto, se você
baixar e instalar a atualização Windows Management Framework, a funcionalidade
branchCache estará disponível apenas para o protocolo BITS (Serviço de
Transferência Inteligente em Segundo Plano). Para obter mais informações e baixar
Windows Management Framework, consulte Windows Management Framework
(Windows PowerShell 2.0, WinRM 2.0 e BITS 4.0) em
/powershell/scripts/windows-powershell/install/installing-the-windows-powershell-
2.0-engine.
Sistemas operacionais para a funcionalidade de servidor

de conteúdo BranchCache
Você pode usar as famílias de Windows Server 2016, Windows Server 2012 R2 e
Windows Server 2012 de sistemas operacionais como servidores de conteúdo
branchcache.
Além disso, a família de sistemas operacionais Windows Server 2008 R2 pode ser usada
como servidores de conteúdo BranchCache, com as seguintes exceções:
O BranchCache não tem suporte em instalações do Server Core do Windows

Server 2008 R2 Enterprise com o Hyper-V.
BranchCache não tem suporte em instalações do Server Core do Windows Server

2008 R2 Datacenter com Hyper-V.
Sistemas operacionais para a funcionalidade de servidor

de cache hospedado do BranchCache
Você pode usar o Windows Server 2016, Windows Server 2012 R2 e Windows Server
2012 famílias de sistemas operacionais como servidores de cache hospedados pelo
BranchCache.
Além disso, os seguintes sistemas operacionais Windows Server 2008 R2 podem ser
usados como servidores de cache hospedados pelo BranchCache:
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Enterprise com o Hyper-V
Windows Server 2008 R2 Enterprise Instalação do Server Core
Windows Server 2008 R2 Enterprise Instalação do Server Core com o Hyper-V
Windows Server 2008 R2 for Itanium-Based Systems
Windows Server 2008 R2 Datacenter
Windows Server 2008 R2 Datacenter com Hyper-V
instalação do Windows Server 2008 R2 Datacenter Server Core com o Hyper-V
Segurança do BranchCache
O BranchCache implementa uma abordagem segura por design, que trabalha de forma
ininterrupta juntamente com as arquiteturas de segurança de rede existentes,
dispensando outros equipamentos ou configurações de segurança adicionais
complexas.
O BranchCache não é invasivo e não altera processo de autenticação ou autorização do
Windows. Após a implantação do BranchCache, a autenticação ainda é realizada usando
credenciais de domínio, e o modo no qual a organização com ACLs (listas de controle
de acesso) funciona é inalterado. Além disso, outras configurações continuam a
funcionar do mesmo modo antes da implantação do BranchCache.
O modelo de segurança do BranchCache é baseado na criação de metadados, que

assumem a forma de uma série de hashes. Esses hashes também são chamados de
informações de conteúdo.
Depois que as informações de conteúdo são criadas, elas são usadas em trocas de
mensagens do BranchCache no lugar dos dados reais e são trocadas usando os
protocolos com suporte (HTTP, HTTPS e SMB).
Os dados em cache permanecem criptografados e não podem ser acessados por

clientes sem permissão de acesso a conteúdo da origem original. Os clientes devem ser
autenticados e autorizados pela origem de conteúdo original antes que possam
recuperar metadados de conteúdo. Além disso, eles devem possuir metadados de
conteúdo para acessar o cache no escritório local.
Como o BranchCache gera as informações de conteúdo

Como as informações de conteúdo são criadas a partir de vários elementos, seu valor é
sempre único. Esses elementos são:
O conteúdo real (como páginas da Web ou arquivos compartilhados) do qual os

hashes são derivados.
Parâmetros de configuração, como algoritmo de hash e tamanho do bloco. Para

gerar informações de conteúdo, o servidor divide o conteúdo em segmentos e os
subdivide em blocos. O BranchCache usa hashes criptográficos seguros para
identificar e verificar cada bloco e segmento, com suporte ao algoritmo de hash
SHA256.
Um segredo do servidor. Todos os servidores de conteúdo devem ser configurados

com um segredo do servidor, que é um valor binário de comprimento arbitrário.
７ Observação
O uso de um segredo do servidor garante que os computadores clientes não são

capazes de gerar informações de conteúdo por conta própria. Isso evita que
usuários mal-intencionados usem ataques de força bruta com computadores
clientes habilitados pelo BranchCache para detectar alterações pequenas no
conteúdo entre versões diferentes, em situações em que o cliente tinha acesso a
uma verão anterior, mas não tem acesso à versão atual.
Detalhes das informações de conteúdo

O BranchCache usa o segredo do servidor como uma chave para derivar um hash
específico de conteúdo, que é enviado a clientes autorizados. A aplicação de um
algoritmo de hash ao segredo do servidor combinado e ao hash de dados gera esse
hash.
Ele é chamado de segredo de segmento. O BranchCache usa segredos de segmento

para proteger comunicações. Além disso, o BranchCache cria uma lista de hashes de
blocos, com blocos de dados em hash, e o hash de dados que é gerado pelo hash dessa
lista.
As informações de conteúdo incluem:
A lista de hashes de blocos:
BlockHashi = Hash(dataBlocki) 1<=i<=n
O hash de dados (HoD):
HoD = Hash(BlockHashList)
Segredo de segmento (Kp):
Kp = HMAC(Ks, HoD)
O BranchCache usa o protocolo de Cache de Conteúdo de Ponta e o protocolo de

Estrutura de Recuperação a fim de implementar os processos necessários para garantir a
segurança do armazenamento em cache e recuperação de dados entre caches de
conteúdo.
Além disso, o BranchCache manipula as informações de conteúdo com o mesmo nível

de segurança usado ao manipular e transmitir o próprio conteúdo real.
Processos e fluxo de conteúdo

O fluxo das informações de conteúdo e do conteúdo real é dividido em quatro fases:
1. Processos do BranchCache: solicitar conteúdo
2. Processos do BranchCache: localizar conteúdo

3. Processos do BranchCache: recuperar conteúdo
4. Processos do BranchCache: armazenar conteúdo em cache
As seções a seguir descrevem essas fases.
Processos do BranchCache: solicitar conteúdo

Na primeira fase, o computador cliente na filial solicita conteúdo (como um arquivo ou
página da Web) de um servidor de conteúdo em um local remoto, como uma matriz. O
servidor de conteúdo verifica se o computador cliente está autorizado a receber o
conteúdo solicitado. Se o computador cliente estiver autorizado e tanto o servidor de
conteúdo quanto o cliente forem habilitados pelo BranchCache, o servidor de conteúdo
gerará informações de conteúdo.
Em seguida, o servidor de conteúdo envia as informações de conteúdo ao computador

cliente usando o mesmo protocolo que seria usado para o conteúdo real.
Por exemplo, se o computador cliente tiver solicitado uma página da Web por HTTP, o
servidor de conteúdo enviará as informações de conteúdo usando HTTP. Por causa
disso, as garantias de segurança em nível de transmissão do conteúdo e das
informações de conteúdo são idênticas.
Após o recebimento da porção inicial das informações de conteúdo (hash de dados +

segredo de segmento), o computador cliente realiza a seguintes ações:
Use o segredo de segmento (Kp) como chave de criptografia (Ke).
Gera o ID do segmento (HoHoDk) do HoD e Kp:
HoHoDk = HMAC(Kp, HoD + C), where C is the ASCII string "MS_P2P_CACHING" with
NUL terminator.
A principal ameaça nesta camada é o risco para o segredo de segmento, mas o

BranchCache criptografa os blocos de dados de conteúdo para protegê-lo. O
BranchCache faz isso usando a chave de criptografia derivada do segredo do segmento
de conteúdo no qual os blocos de conteúdo estão localizados.
Essa abordagem garante que uma entidade que não possua o segredo de segmento
não possa descobrir o conteúdo real em um bloco de dados. O segredo de segmento é
tratado com o mesmo nível de segurança que o segmento em texto não criptografado,
pois o conhecimento do segredo de um determinado segmento permite que uma
entidade obtenha o segmento a partir de pares e o descriptografe. O conhecimento do
segredo de servidor não produz texto não criptografados, mas pode ser usado paras
derivar certos tipos de dados do texto codificado e possivelmente expor dados
parcialmente conhecidos a um ataque de adivinhação pro força bruta. Por isso, o
segredo de servidor deve ser confidencial.
Processos do BranchCache: localizar conteúdo

Depois que as informações de conteúdo são recebidas pelo computador cliente, o
cliente usa o ID do segmento para localizar o conteúdo solicitado no cache local da
filial, esteja ele distribuído entre computadores clientes ou localizado em um servidor de
cache hospedado.
Se o computador cliente estiver configurado para o modo de cache hospedado, ele será
configurado com o nome do computador do servidor de cache hospedado e entrará em
contato com o servidor para recuperar o conteúdo.
Porém, se o computador cliente estiver configurado para o modo de cache distribuído,

o conteúdo poderá ser armazenados entre vários caches em diversos computadores da
filial. O computador cliente deve descobrir onde o conteúdo está localizado antes de
recuperá-lo.
Quando estão configurados para o modo de cache distribuído, os computadores

clientes localizam conteúdo usando um protocolo de descoberta baseado no protocolo
WS-Discovery. Os clientes enviam mensagens de sondagem multicast WS-Discovery
para descobrir conteúdo em cache pela rede. Essas mensagens incluem o ID do
segmento, que permite que os clientes verifique se o conteúdo solicitado corresponde
ao armazenado em cache. Os clientes que recebem a mensagem de sondagem inicial
respondem ao cliente da consulta com mensagens de correspondência de sondagem
unicast quando o ID do segmento corresponde ao conteúdo armazenado em cache
local.
Para que o processo WS-Discovery obtenha êxito, o cliente que realiza a descoberta
deve ter as informações de conteúdo corretas (fornecidas pelo servidor de conteúdo)
para o conteúdo solicitado.
A ameaça principal aos dados durante a fase de solicitação de conteúdo é a divulgação

das informações, pois o acesso às informações de conteúdo implica em acesso
autorizado ao conteúdo. Para eliminar esse risco, o processo de descoberta não revela
as informações de conteúdo, somente o ID do segmento, que não revela nada sobre o
segmento em texto não criptografado com o conteúdo.
Além disso, outro computador cliente executado por um usuário mal-intencionado na

mesma sub-rede pode ver o tráfego de descoberta do BranchCache para a origem de
conteúdo original passando pelo roteador.
Se o conteúdo solicitado não for encontrado na filial, o cliente solicitará o conteúdo

diretamente do servidor de conteúdo pelo link WAN.
Depois que o conteúdo é recebido, ele é adicionado ao cache local, seja no computador
cliente ou no servidor de cache hospedado. Nesse caso, as informações de conteúdo
evitam que um cliente ou servidor de cache hospedado adicione ao cache local
qualquer conteúdo que não corresponda aos hashes. O processo de verificação do
conteúdo por meio da correspondência de hashes garante que apenas o conteúdo
válido seja adicionado ao cache e a integridade do cache local seja protegida.
Processos do BranchCache: recuperar conteúdo

Depois que um computador cliente localiza o conteúdo desejado no host de conteúdo
(que é um servidor de cache hospedado ou um computador cliente no modo de cache
distribuído), o computador cliente começa o processo de recuperar o conteúdo.
Primeiro, o computador cliente envia uma solicitação ao host de conteúdo para o

primeiro bloco necessário. A solicitação contém o ID do segmento e o intervalo de
blocos que identificam o conteúdo desejado. Como apenas um bloco é enviado, o
intervalo contém somente um bloco (Atualmente, não há suporte para solicitações para
vários blocos.) O cliente também armazena a solicitação em sua Lista de Solicitações
Pendentes local.
Ao receber uma mensagem de solicitação válida de um cliente, o host de conteúdo

verifica se o bloco especificado na solicitação existe no cache de conteúdo do host de
conteúdo.
Se o host de conteúdo possuir o bloco de conteúdo, ele enviará uma resposta que
contém o ID do segmento, ID do bloco, bloco de dados criptografados e vetor de
inicialização usado para criptografar o bloco.
Se o host de conteúdo não possuir o bloco de conteúdo, ele enviará uma mensagem de
resposta vazia. Isso informará ao computador cliente que o host de conteúdo não tem o
bloco solicitado. Uma mensagem de resposta vazia contém o ID do segmento e ID do
bloco solicitado, juntamente com um bloco de dados com tamanho zero.
Quando o computador cliente recebe a resposta do host de conteúdo, ele verifica se a

mensagem corresponde à mensagem solicitada na lista de solicitações pendentes (o ID
do segmento e o índice do bloco devem corresponder à solicitação pendente).
Se esse processo de verificação não for bem-sucedido e o computador cliente não tiver
uma mensagem de solicitação correspondente na lista de solicitações pendentes, o
computador cliente descartará a mensagem.
Se esse processo de verificação for bem-sucedido e o computador cliente tiver uma

mensagem de solicitação correspondente na lista de solicitações pendentes, o
computador cliente descriptografará o bloco. Em seguida, o cliente validará o bloco
descriptografado em relação ao hash de bloco adequado das informações de conteúdo
que o cliente obteve inicialmente do servidor de conteúdo original.
Se a validação do bloco for bem-sucedida, o bloco descriptografado será armazenado

em cache.
Esse processo é repetido até o cliente ter todos os blocos necessários.
７ Observação
Se os segmentos completos de conteúdo não existirem em um computador, o

protocolo de recuperação recuperará e montará o conteúdo de uma combinação
de fontes: um conjunto de computadores cliente do modo de cache distribuído,
um servidor de cache hospedado e - se os caches da filial não contiverem o
conteúdo completo - o servidor de conteúdo original no escritório principal.
Antes de o BranchCache enviar conteúdo ou informações de conteúdo, os dados são

criptografados. O BranchCache criptografa o bloco na mensagem de resposta. Em
Windows 7, o algoritmo de criptografia padrão que o BranchCache usa é AES-128, a
chave de criptografia é Ke e o tamanho da chave é de 128 bits, conforme ditado pelo
algoritmo de criptografia.
O BranchCache gera um vetor de inicialização adequado ao algoritmo de criptografia e

usa a chave de criptografia para criptografar o bloco. Em seguida, o BranchCache
registra o algoritmo de criptografia e o vetor de inicialização na mensagem.
Os servidores e clientes nunca trocam, compartilham ou enviam a chave de criptografia

uns para os outros. O cliente recebe a chave de criptografia do servidor de conteúdo e
hospeda o conteúdo de origem. Em seguida, usando o algoritmo de criptografia e o
vetor de inicialização recebido do servidor, ele descriptografa o bloco. Não há outra
autorização ou autenticação explícita incorporada ao protocolo de download.
Ameaças de segurança
As principais ameaças à segurança nesta camada incluem:
Adulteração de dados:
Um cliente fornecendo dados para um solicitante adultera os dados. O modelo de

segurança do BranchCache usa hashes para confirmar que o cliente e o servidor
não alteraram os dados.
Divulgação de informações:
O BranchCache envia conteúdo criptografado para um cliente que especifica o ID de

Segmento adequado. Os IDs de segmento são públicos. Por isso, qualquer cliente
pode receber conteúdo criptografado. Porém, se um usuário mal-intencionado
obtiver conteúdo criptografado, ele dever[a saber a chave de criptografia para
descriptografar o conteúdo. O protocolo da camada superior realiza a
autenticação e fornece as informações de conteúdo ao cliente autenticado e
autorizado. A segurança das informações de conteúdo é equivalente à segurança
fornecida ao próprio conteúdo, e o BranchCache nunca expõe as informações de
conteúdo.
Um invasor detecta a transmissão para obter o conteúdo. O BranchCache

criptografa todas as transferências entre clientes usando AES128, onde a chave
secreta é Ke, evitando que os dados sejam detectados na transmissão. As
informações de conteúdo baixadas do servidor de conteúdo são protegidas
exatamente do mesmo modo que os próprios dados. Por isso, a proteção delas
contra divulgação é igual a que seria se o BranchCache não fosse usado.
Negação de serviço:
Um cliente é sobrecarregado com solicitações de dados. Os protocolos do

BranchCache incorporam contadores e temporizadores de gerenciamento de fila
para evitar a sobrecarga dos clientes.
Processos do BranchCache: armazenar

conteúdo em cache
Em computadores clientes no modo de cache distribuído e servidores de cache
hospedado localizados em filiais, os caches de conteúdo são criados ao longo do
tempo, à medida que o conteúdo é recuperado por links WAN.
Quando os computadores clientes são configurados com o modo de cache hospedado,

eles adicionam conteúdo a seu próprio cache local e também oferecem dados ao
servidor de cache hospedado. O Protocolo de Cache Hospedado fornece um
mecanismo para que os clientes informem o servidor de cache hospedado sobre
disponibilidade de conteúdo e segmentos.
Para carregar conteúdo no servidor de cache hospedado, o cliente informa ao servidor

que tem um segmento disponível. Em seguida, o servidor de cache hospedado recupera
todas as informações de conteúdo associadas ao segmento oferecido e baixa os blocos
no segmento de que realmente necessita. Esse processo é repetido até o cliente não ter
mais segmentos a oferecer ao servidor de cache hospedado.
Para atualizar o servidor de cache hospedado usando o Protocolo de Cache Hospedado,

é necessário atender ao seguintes requisitos:
O computador cliente deve ter um conjunto de blocos em um segmento que

possa oferecer ao servidor de cache hospedado. O cliente deve fornecer
informações de conteúdo para o segmento oferecido; elas são compostas do ID
do segmento o hash de dados do segmento, o segredo de segmento e uma lista
de todos os hashes de bloco contidos no segmento.
Para servidores de cache hospedados que estão executando Windows Server 2008
R2, um certificado de servidor de cache hospedado e uma chave privada associada
são necessários, e a autoridade de certificação (AC) que emitiu o certificado deve
ser confiável por computadores cliente na filial. Isso permite que o cliente e o
servidor participem com êxito na autenticação do servidor HTTPS.
） Importante
Os servidores de cache hospedados que estão executando Windows Server

2016, Windows Server 2012 R2 ou Windows Server 2012 não exigem um
certificado de servidor de cache hospedado e uma chave privada associada.
O computador cliente está configurado com o nome de computador do servidor

de cache hospedado e o número da porta TCP por meio da qual esse servidor está
escutando o tráfego do BranchCache. O certificado do servidor de cache
hospedado está associado a essa porta. O nome de computador do servidor de
cache hospedado poderá ser um FQDN (nome de domínio totalmente qualificado)
se o servidor for um computador membro do domínio, ou um nome NetBIOS do
computador se o servidor não for membro do domínio.
O computador cliente escuta ativamente para detectar solicitações de blocos

recebidas. A porta que ele usa para isso é passada como parte das mensagens de
oferta do cliente para o servidor de cache hospedado. Isso permite que o servidor
de cache hospedado use os protocolos do BranchCache para conectar-se ao
computador cliente e recuperar blocos de dados no segmento.
O servidor de cache hospedado começa a escutar para detectar solicitações HTTP

recebidas quando é iniciado.
Se o servidor de cache hospedado estiver configurado para exigir autenticação do

computador cliente, tanto o cliente quanto o servidor deverão dar suporte à
autenticação HTTPS.
População de cache do modo de cache hospedado

O processo de adicionar conteúdo ao cache do servidor de cache hospedado em uma
filial começa quando o cliente envia um INITIAL_OFFER_MESSAGE, que inclui a ID do
Segmento. A ID do Segmento na solicitação INITIAL_OFFER_MESSAGE é usada para
recuperar o Hash de Dados do segmento correspondente, a lista de hashes de bloco e o
Segredo do Segmento do cache hospedado do cache cache. Se o servidor de cache
hospedado já tiver todas as informações de conteúdo de um segmento específico, a
resposta a INITIAL_OFFER_MESSAGE será OK, e nenhuma solicitação de download de
blocos ocorrerá.
Se o servidor de cache hospedado não tiver todos os blocos de dados oferecidos

associados aos hashes de bloco no segmento, a resposta a INITIAL_OFFER_MESSAGE
será INTERESTED. Em seguida, o cliente enviará SEGMENT_INFO_MESSAGE, que
descreve o segmento único oferecido. O servidor de cache hospedado responde com
uma mensagem de OK e inicia o download dos blocos ausentes do computador cliente
que realizou a oferta.
O hash de dados do segmento, a lista de hashes de bloco e o segredo de segmento são

usados para garantir que o conteúdo baixado não tenha sido violado nem alterado. Em
seguida, os blocos baixados são adicionados ao cache de bloco do servidor de cache
hospedado.
Segurança de cache
Esta seção fornece informações sobre como o BranchCache protege dados em cache
em computadores clientes e servidores de cache hospedado.
Segurança do cache do computador cliente

A maior ameaça aos dados armazenados no BranchCache é a violação. Se um invasor
puder violar o conteúdo e as informações de conteúdo armazenadas em cache, ele
poderá usá-los para tentar iniciar um ataque contra os computadores que usam o
BranchCache. Os invasores podem iniciar um ataque inserindo softwares mal-
intencionados no lugar de outros dados. O BranchCache elimina essa ameaça por meio
da validação de todo o conteúdo usando os hashes de bloco encontrados nas
informações de conteúdo. Se um invasor tentar realizar uma violação com esses dados,
eles serão descartados e substituídos por dados válidos da origem original.
Uma ameaça secundária aos dados armazenados no BranchCache é a divulgação de

informações. No modo de cache distribuído, o cliente armazena em cache somente o
conteúdo que solicitou por conta própria. Porém, esses dados são armazenados como
texto não criptografado e podem correr riscos. Para restringir o acesso ao cache
somente ao serviço BranchCache, o cache local é protegido pelas permissões do sistema
de arquivos especificadas em uma ACL.
Embora a ACL seja eficiente para evitar que usuários não autorizados acessem o cache,
é possível que um usuário com privilégios administrativos obtenha acesso ao cache por
meio da alteração manual das permissões especificadas na ACL. O BranchCache não
oferece proteção contra o uso mal-intencionado de uma conta administrativa.
Os dados armazenados no cache de conteúdo não são criptografados. Por isso, se o

vazamento de dados for um preocupação, use tecnologias como BitLocker ou EFS
(Encrypting File System). O cache local usado pelo BranchCache não aumenta o risco de
divulgação de informações trazido por um computador na filial. O cache contém apenas
cópias dos arquivos que permanecem descriptografados em alguma parte do disco.
Criptografar todo o disco é particularmente importante em ambientes em que seja

difícil garantir a segurança física dos clientes. Por exemplo, a criptografia de todo o
disco ajuda a proteger dados confidenciais em computadores móveis que possam ser
removidos do ambiente da filial.
Segurança do cache do servidor de cache hospedado

No modo de cache hospedado, a maior ameaça à segurança do servidor de cache
hospedado é a divulgação de informações. Em um ambiente de cache hospedado, o
BranchCache comporta-se de modo semelhante ao modo de cache distribuído, com a
permissão do sistema de arquivos protegendo os dados em cache. A diferença é que o
servidor de cache hospedado armazena todo o conteúdo solicitado por qualquer
computador habilitado por BranchCache na filial, em vez de fazer isso apenas com os
dados solicitados por um único cliente. As consequências do acesso não autorizado a
esse cache podem ser muito mais sérias, pois há muito mais dados em risco.
Em um ambiente de cache hospedado em que o servidor de cache hospedado está em
execução Windows Server 2008 R2, o uso de tecnologias de criptografia, como BitLocker
ou EFS, é aconselhável se qualquer um dos clientes na filial puder acessar dados
confidenciais no link da WAN. Também é necessário evitar o acesso físico ao cache
hospedado, pois a criptografia de disco funciona somente quando o computador está
desligado no momento em que o invasor obtém acesso físico. Se o computador estiver
ligado ou no modo de suspensão, a criptografia de disco oferecerá pouca proteção.
７ Observação
Servidores de cache hospedados que estão executando Windows Server 2016,

Windows Server 2012 R2 ou Windows Server 2012 criptografar todos os dados no
cache por padrão, portanto, o uso de tecnologias de criptografia adicionais não é
necessário.
Mesmo que um cliente esteja configurado no modo de cache hospedado, ele ainda
armazenará dados em cache localmente. Por isso, convém tomar medidas para proteger
o cache local (além do cache no servidor de cache hospedado).
Shell de rede do BranchCache e
comandos do Windows PowerShell
No Windows Server, você pode configurar e gerenciar o BranchCache usando os

comandos Windows PowerShell ou Netsh (Network Shell) para BranchCache.
Nas futuras versões do Windows, a Microsoft poderá remover a funcionalidade do netsh

para BranchCache. A Microsoft recomenda que você transfiram para Windows
PowerShell se você usar o netsh no momento para configurar e gerenciar o
BranchCache e outras tecnologias de rede.
As referências dos comandos do Windows PowerShell e do netsh estão nos seguintes

locais. Embora ambas as referências de comando tenham sido publicadas para sistemas
operacionais anteriores Windows Server 2016, essas referências são precisas para esse
sistema operacional.
Comandos do netsh para BranchCache no Windows Server 2008 R2
Cmdlets de BranchCache no Windows PowerShell
 Dica
Para exibir uma lista de comandos do Windows PowerShell para BranchCache no

prompt do Windows PowerShell, digite Get-Command -Module BranchCache no
prompt do Windows PowerShell e pressione ENTER.
Guia de Implantação do BranchCache
Você pode usar este guia para saber como implantar o BranchCache no Windows Server
2016.
Além deste tópico, este guia contém as seções a seguir.
Escolhendo um design do BranchCache
Implantar o BranchCache
Visão geral da implantação do BranchCache

ampla área) incluída em algumas edições do Windows Server 2016, Windows Server®
2012 R2, Windows Server® 2012, Windows Server® 2008 R2 e sistemas operacionais
cliente Windows relacionados.
Para otimizar a largura de banda da WAN, o BranchCache copia o conteúdo dos

servidores de conteúdo da matriz e o armazena nas filiais, permitindo que os
computadores cliente das filiais acessem o conteúdo localmente e não pela WAN.
Nas filiais, o conteúdo é armazenado em cache em servidores que executam o recurso

BranchCache do Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
ou Windows Servidor 2008 R2 – ou, se não houver servidores disponíveis na filial, o
conteúdo será armazenado em cache em computadores cliente que executam Windows
10 ®, Windows ® 8.1, Windows 8 ou Windows 7®.
Depois que um computador cliente solicita e recebe conteúdo do datacenter de nuvem

ou escritório principal e o conteúdo é armazenado em cache na filial, outros
computadores na mesma filial podem obter o conteúdo localmente em vez de contatar
o servidor de conteúdo por meio do link wan.
Benefícios da implantação do BranchCache
O BranchCache armazena em cache o conteúdo do arquivo, da Web e do aplicativo em

locais de filiais, permitindo que os computadores cliente acessem dados usando a LAN
(rede de área local) em vez de acessar o conteúdo em conexões WAN lentas.
O BranchCache reduz o tráfego wan e o tempo necessário para que os usuários da filial
abram arquivos na rede. O BranchCache sempre fornece aos usuários os dados mais
recentes e protege a segurança do conteúdo criptografando os caches no servidor de
cache hospedado e nos computadores cliente.
O que é fornecido neste guia

Esta guia de implantação permite implantar o BranchCache nos seguintes modos:
Modo de cache distribuído. Nesse modo, os computadores cliente da filial baixam

o conteúdo dos servidores de conteúdo no escritório principal ou na nuvem e, em
seguida, armazenam em cache o conteúdo de outros computadores na mesma
filial. O modo de cache distribuído não exige um computador servidor na filial.
Modo de cache hospedado. Nesse modo, os computadores cliente de filial baixam

o conteúdo dos servidores de conteúdo no escritório principal ou na nuvem e um
servidor de cache hospedado recupera o conteúdo dos clientes. O servidor de
cache hospedado armazena em cache o conteúdo de outros computadores
cliente.
Este guia também fornece instruções sobre como implantar três tipos de servidores de
conteúdo. Os servidores de conteúdo contêm o conteúdo de origem baixado pelos
computadores cliente da filial e um ou mais servidores de conteúdo são necessários
para implantar o BranchCache em qualquer modo. Os tipos de servidores de conteúdo
são:
Servidores de conteúdo baseados em servidor Web. Esses servidores de

conteúdo enviam conteúdo a computadores cliente BranchCache usando os
protocolos HTTP e HTTPS. Esses servidores de conteúdo devem estar executando
versões Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 ou
Windows Server 2008 R2 que suportam o BranchCache e nas quais o recurso
BranchCache está instalado.
Servidores de aplicativos baseados em BITS. Esses servidores de conteúdo enviam

conteúdo para computadores cliente BranchCache usando o BITS (Serviço de
Transferência Inteligente em Segundo Plano). Esses servidores de conteúdo devem
estar executando versões Windows Server 2016, Windows Server 2012 R2,
Windows Server 2012 ou Windows Server 2008 R2 que suportam o BranchCache e
nas quais o recurso BranchCache está instalado.
Servidores de conteúdo baseados em servidor de arquivos. Esses servidores de

conteúdo devem estar executando as versões Windows Server 2016, Windows
Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2 que suportam o
BranchCache e nas quais a função de servidor dos Serviços de Arquivos está
instalada. Além disso, o serviço de função BranchCache para arquivos da rede da
função de servidor de Serviços de Arquivo deve estar instalado e configurado.
Esses servidores de conteúdo enviam conteúdo a computadores cliente
BranchCache usando o protocolo SMB.
Para obter mais informações, consulte Versões do sistema operacional para

BranchCache.
Requisitos de implantação do BranchCache

A seguir estão os requisitos para implantar o BranchCache usando este guia.
Os servidores de conteúdo da Web e de arquivos devem estar executando um dos

seguintes sistemas operacionais para fornecer a funcionalidade BranchCache:
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 ou
Windows Server 2008 R2 . Windows 8 e clientes posteriores continuam a ver os
benefícios do BranchCache ao acessar servidores de conteúdo que executam o
Windows Server 2008 R2, no entanto, eles não conseguem usar as novas
tecnologias de divisão em partes e hash no Windows Server 2016, Windows Server
2012 R2 e Windows Server 2012.
Os computadores cliente devem estar executando Windows 10, Windows 8.1 ou

Windows 8 para usar o modelo de implantação mais recente e as melhorias de
partes e hash que foram introduzidas com o Windows Server 2012 .
Os servidores de cache hospedados devem estar executando Windows Server

2016, Windows Server 2012 R2 ou Windows Server 2012 para usar as melhorias de
implantação e os recursos de escala descritos neste documento. Um computador
que executa um desses sistemas operacionais configurados como um servidor de
cache hospedado pode continuar a atender a computadores cliente que executam
o Windows 7, mas para fazer isso, ele deve estar equipado com um certificado
adequado para o TLS (Transport Layer Security), conforme descrito no Guia de
Implantação do BranchCache do Windows Server 2008 R2 e do Windows 7
BranchCache.
Um domínio do Active Directory é necessário para aproveitar a descoberta

automática Política de Grupo cache hospedado e hospedado, mas um domínio
não é necessário para usar o BranchCache. Você pode configurar computadores
individuais usando Windows PowerShell. Além disso, não é necessário que os
controladores de domínio sejam executados no Windows Server 2012 ou posterior
para utilizar novas configurações do BranchCache Política de Grupo; você pode
importar os modelos administrativos do BranchCache para controladores de
domínio que executam sistemas operacionais anteriores ou criar os objetos de
política de grupo remotamente em outros computadores que executam o
Windows 10, Windows Server 2016, Windows 8.1, Windows Server 2012 R2,
Windows 8 ou Windows Server 2012.
Os sites do Active Directory são usados para limitar o escopo dos servidores de
cache hospedados que são descobertos automaticamente. Para descobrir
automaticamente um servidor de cache hospedado, os computadores cliente e
servidor devem pertencer ao mesmo site. O BranchCache foi projetado para ter um
impacto mínimo em clientes e servidores e não impõe requisitos de hardware
adicionais além daqueles necessários para executar seus respectivos sistemas
operacionais.
Histórico e documentação do BranchCache
O BranchCache foi introduzido pela primeira vez no Windows 7® e no Windows

Server® 2008 R2 e foi aprimorado em sistemas operacionais Windows Server 2012,
Windows 8 e posteriores.
７ Observação
Se você estiver implantando o BranchCache em sistemas operacionais diferentes

Windows Server 2016, os seguintes recursos de documentação estarão disponíveis.
Para obter informações sobre o BranchCache Windows 8, Windows 8.1,

Windows Server 2012 e Windows Server 2012 R2, consulte Visão geral do
BranchCache.
Para obter informações sobre o BranchCache no Windows 7 e Windows
Server 2008 R2, consulte BranchCache para Windows Server 2008 R2.
Escolher um design para o BranchCache
Você pode usar este tópico para saber mais sobre os modos BranchCache e selecionar
os melhores modos para sua implantação.
Você pode usar este guia para implantar o BranchCache nos seguintes modos e
combinações de modo.
Todas as filiais são configuradas para o modo de cache distribuído.
Todas as filiais são configuradas para o modo de cache hospedado e têm um

servidor de cache hospedado no site.
Algumas filiais são configuradas para o modo de cache distribuído e algumas filiais
têm um servidor de cache hospedado no site e são configuradas para o modo de
cache hospedado.
A ilustração a seguir ilustra uma instalação de modo duplo, com uma filial configurada
para o modo de cache distribuído e uma filial configurada para o modo de cache
hospedado.
Antes de implantar o BranchCache, selecione o modo que você prefere para cada filial
em sua organização.
Implantar o BranchCache
As seções a seguir fornecem informações sobre como implantar o BranchCache em

modos de cache distribuídos e hospedados.
Instalar e configurar servidores de conteúdo
Implantar servidores de cache hospedados (opcional)
Pré-hashing e pré-carregamento de conteúdo em servidores de cache hospedados

(opcional)
Configurar computadores cliente BranchCache
７ Observação
Instalar e configurar servidores de
conteúdo
Ao implantar o BranchCache no modo de cache distribuído ou no modo de cache

hospedado, você deve implantar um ou mais servidores de conteúdo em seu escritório
principal ou na nuvem. Os servidores de conteúdo que são servidores Web ou
servidores de aplicativos usam o recurso BranchCache. Os servidores de conteúdo que
são servidores de arquivos usam o BranchCache para o serviço de função de arquivos
de rede da função de servidor de serviços de arquivo no Windows Server 2016.
Consulte os tópicos a seguir para implantar servidores de conteúdo.
Instalar servidores de conteúdo que usam o recurso BranchCache
Instalar servidores de conteúdo dos serviços de arquivo

Instalar servidores de conteúdo que
usam o recurso BranchCache
Para implantar servidores de conteúdo que são servidores Web HTTPS (Secure
Hypertext Transfer Protocol), servidores Web HTTP (Protocolo de Transferência de
Hipertexto) e servidores de aplicativos baseados em BITS (Serviço de Transferência
Inteligente em Segundo Plano), como Windows Server Update Services (WSUS) e
Microsoft Endpoint Configuration Manager servidores do sistema de sites de
distribuição de branch, você deve instalar o recurso BranchCache, iniciar o serviço
BranchCache e (somente para servidores WSUS) executar etapas de configuração
adicionais.
Instalar o recurso BranchCache
Configurar servidores de Windows Server Update Services (WSUS)

Instalar o recurso BranchCache
Você pode usar este procedimento para instalar o recurso BranchCache e iniciar o
serviço BranchCache em um computador que executa o Windows Server® 2016,
Windows Server 2012 R2 ou Windows Server 2012.

deste procedimento.
Antes de executar este procedimento, é recomendável instalar e configurar seu

aplicativo baseado em BITS ou servidor Web.
７ Observação
Para executar esse procedimento usando Windows PowerShell, execute Windows

PowerShell como administrador, digite os comandos a seguir no prompt Windows
PowerShell e pressione ENTER.
Install-WindowsFeature BranchCache
Restart-Computer
Para instalar e habilitar o recurso BranchCache

e Recursos. O assistente Adicionar Funções e Recursos será aberto. Clique em
Próximo.
2. Em Selecionar tipo de instalação, verifique se a instalação baseada em função ou

recurso está selecionada e clique em Próximo.
3. Em Selecionar servidor de destino, verifique se o servidor correto está selecionado

e clique em Próximo.
4. Em Selecionar funções de servidor, clique em Avançar.
5. Em Selecionar recursos, clique em BranchCache e clique em Próximo.

6. Em Confirmar seleções de instalação, clique em Instalar. Em Andamento da
instalação, a instalação do recurso BranchCache continua. Quando a instalação for
concluída, clique em Fechar.
Depois de instalar o recurso BranchCache, o serviço BranchCache , também chamado de

PeerDistSvc, é habilitado e o tipo inicial é Automático.
Configurar servidores de conteúdo do
WSUS (Windows Server Update
Services)
Depois de instalar o recurso BranchCache e iniciar o serviço BranchCache, é necessário

configurar os servidores do WSUS para armazenar arquivos de atualização no
computador local.
Ao configurar servidores do WSUS para armazenar arquivos de atualização no

computador local, os metadados de atualização e os arquivos de atualização são
baixados e armazenados diretamente no servidor do WSUS. Isso garante que os
computadores cliente BranchCache recebam os arquivos de atualização dos produtos
da Microsoft do servidor do WSUS e não diretamente do site do Microsoft Update.
Para obter mais informações sobre a sincronização do WSUS, consulte Configurando

sincronizações de atualização
Instalar servidores de conteúdo dos
Serviços de Arquivo
Para implantar servidores de conteúdo que executam a função de servidor de Serviços

de Arquivo, instale o BranchCache para o serviço de função de arquivos de rede da
função de servidor de Serviços de Arquivo. Além disso, você deve habilitar o
BranchCache em compartilhamentos de arquivos de acordo com suas necessidades.
Durante a configuração do servidor de conteúdo, você pode permitir a publicação do

BranchCache de conteúdo para todos os compartilhamentos de arquivos ou pode
selecionar um subconjunto de compartilhamentos de arquivos para publicar.
７ Observação
Quando você implanta um servidor de arquivos habilitado para BranchCache ou

servidor Web como um servidor de conteúdo, as informações de conteúdo agora
são calculadas offline, bem antes de um cliente BranchCache solicitar um arquivo.
Devido a essa melhoria, você não precisa configurar a publicação de hash para
servidores de conteúdo, como fez na versão anterior do BranchCache.
Essa geração automática de hash fornece um desempenho mais rápido e mais

economia de largura de banda, pois as informações de conteúdo estão prontas
para o primeiro cliente que solicita o conteúdo e os cálculos já foram executados.
Configurar a função de servidor de Serviços de Arquivo
Habilitar publicação de hash para servidores de arquivos
Habilitar o BranchCache em um compartilhamento de arquivos (opcional)

Configurar a função de servidor de
Serviços de Arquivo
Você pode implantar servidores de conteúdo baseados em servidor de arquivos

BranchCache em computadores que executam o Windows Server 2016 e a função de
servidor de Serviços de Arquivos com o branchCache para o serviço de função de
arquivos de rede instalado.
Para instalar um servidor de conteúdo do BranchCache em um computador que

ainda não tenha os Serviços de Arquivos instalados, consulte Instalar um novo
servidor de arquivos como um servidor de conteúdo.
Para instalar um servidor de conteúdo do BranchCache em um computador que já

está configurado com a função de servidor de Serviços de Arquivos, consulte
Configurar um servidor de arquivos existente como um servidor de conteúdo.
Instalar um novo servidor de arquivos
como um servidor de conteúdo
Você pode usar este procedimento para instalar a função de servidor de serviços de
arquivo e o BranchCache para o serviço de função de arquivos de rede em um
computador que executa o Windows Server 2016.

deste procedimento.
７ Observação
para executar esse procedimento usando Windows PowerShell, execute Windows

PowerShell como administrador, digite os seguintes comandos no prompt de
Windows PowerShell e pressione ENTER.
Install-WindowsFeature FS-BranchCache -IncludeManagementTools
Restart-Computer
Para instalar o serviço de função eliminação de duplicação de dados, digite o

comando a seguir e pressione ENTER.
Install-WindowsFeature FS-Data-Deduplication -IncludeManagementTools
Para instalar os Serviços de Arquivo e o BranchCache para

o serviço de função de arquivos de rede
e Recursos. O Assistente para Adicionar Funções e Recursos é aberto. Em Antes de
Começar, clique em Avançar.

em recurso está selecionada e clique em Avançar.
3. Em selecionar servidor de destino, verifique se o servidor correto está selecionado

e clique em Avançar.
4. em selecionar funções de servidor, em funções, observe que a função arquivo e
serviços de Armazenamento já está instalada; clique na seta à esquerda do nome
da função para expandir a seleção de serviços de função e clique na seta à
esquerda de serviços de arquivo e iSCSI.
5. Marque as caixas de seleção do servidor de arquivos e do BranchCache para

arquivos de rede.
 Dica
É recomendável que você também marque a caixa de seleção para eliminação

de duplicação de dados.
Clique em Próximo.
6. Em selecionar recursos, clique em Avançar.
7. Em confirmar seleções de instalação, examine suas seleções e clique em instalar.

O painel progresso da instalação é exibido durante a instalação. Quando a
instalação for concluída, clique em fechar.
Configurar um servidor de arquivos
existente como um servidor de
conteúdo
Você pode usar este procedimento para instalar o serviço de função BranchCache para
Arquivos de Rede da função de servidor de Serviços de Arquivos em um computador
que executa Windows Server 2016.
） Importante
Se a função de servidor de Serviços de Arquivo ainda não estiver instalada, não

execute este procedimento. Em vez disso, consulte Instalar um novo servidor de
arquivos como um servidor de conteúdo.

deste procedimento.
７ Observação

PowerShell como administrador, digite os comandos a seguir no prompt Windows
Install-WindowsFeature FS-BranchCache -IncludeManagementTools
Para instalar o serviço de função Deduplication de Dados, digite o comando a

Install-WindowsFeature FS-Data-Deduplication -IncludeManagementTools
Para instalar o serviço de função BranchCache para

Arquivos de Rede
Próximo.

recurso está selecionada e clique em Próximo.
3. Em Selecionar servidor de destino, verifique se o servidor correto está selecionado

e clique em Próximo.
4. Em Selecionar funções de servidor, emFunções, observe que a função Serviços de

Arquivo e Armazenamento já está instalada; clique na seta à esquerda do nome da
função para expandir a seleção de serviços de função e clique na seta à esquerda
dos Serviços de Arquivo e iSCSI.
5. Marque a caixa de seleção BranchCache para Arquivos de Rede.
 Dica
Se você ainda não fez isso, é recomendável marcar também a caixa de seleção
Deduplication de Dados.
Clique em Próximo.
6. Em Selecionar recursos, clique em Próximo.
7. Em Confirmar seleções de instalação, revise suas seleções e clique em Instalar. O

painel Progresso da instalação é exibido durante a instalação. Quando a instalação
for concluída, clique em Fechar.
Habilitar publicação de hash para
servidores de arquivos
Você pode habilitar a publicação de hash do BranchCache em um ou em vários

servidores de arquivos.
Para habilitar a publicação de hash em um servidor de arquivos usando o

computador local Política de Grupo, consulte Habilitar publicação de hash para
servidores de arquivos que não são membros do domínio.
Para habilitar a publicação de hash em vários servidores de arquivos usando

Política de Grupo domínio, consulte Habilitar publicação de hash para servidores
de arquivos de membro de domínio.
７ Observação
Se você tiver vários servidores de arquivos e quiser habilitar a publicação de hash

por compartilhamento, em vez de habilitar a publicação de hash para todos os
compartilhamentos, poderá usar as instruções no tópico Habilitar Publicação hash
para servidores de arquivos de membro não de domínio.
servidores de arquivos do membro que
não sejam de domínio
Você pode usar este procedimento para configurar a publicação de hash para o
BranchCache usando o Política de Grupo de computador local em um servidor de
arquivos que está executando o Windows Server 2016 com o serviço de função
BranchCache para Arquivos de Rede da função de servidor dos Serviços de Arquivos
instalado.
Este procedimento se destina ao uso em um servidor de arquivos que não é membro do

domínio. Se você executar este procedimento em um servidor de arquivos membro do
domínio e também configurar o BranchCache usando a Diretiva de Grupo do domínio,
as configurações da Diretiva de Grupo do domínio substituirão as configurações da
Diretiva de Grupo local.

deste procedimento.
７ Observação
Se você tiver um ou mais servidores de arquivos membro do domínio, poderá

adicioná-los a uma UO (unidade organizacional) nos Serviços de Domínio Active
Directory e então usar a Diretiva de Grupo para configurar publicação de hash para
todos os servidores de arquivos de uma vez, em vez de configurar cada servidor de
arquivos individualmente. Para obter mais informações, consulte Habilitar
publicação de hash para servidores de arquivos de membro de domínio.
Para habilitar publicação de hash para um servidor de

arquivos
1. Abra o Windows PowerShell, digite mmc e pressione ENTER. O Console de
Gerenciamento Microsoft (MMC) é aberto.
2. No MMC, no menu Arquivo, clique em Adicionar/Remover Snap-in. A caixa de
diálogo Adicionar ou Remover Snap-ins é aberta.
3. Em Adicionar ou Remover Snap-ins, em Snap-ins disponíveis, clique duas vezes

em Editor de Objeto de Diretiva de Grupo. O Assistente de Diretiva de Grupo é
aberto com o objeto Computador Local selecionado. Clique em Concluir e em OK.
4. No Editor de Política de Grupo Local MMC, expanda o seguinte caminho: Política

do Computador Local, Configuração do Computador, Modelos Administrativos,
Rede, Servidor Lanman. Clique em Servidor Lanman.
5. No painel de detalhes, clique duas vezes em Publicação de Hash para

BranchCache. A caixa de diálogo Publicação de Hash para BranchCache é aberta.
6. Na caixa de diálogo Publicação de Hash para BranchCache, clique em Habilitado.
7. Em Opções, clique em Permitir publicação de hash para todas as pastas

compartilhadas e clique em uma das seguintes opções:
a. Para habilitar a publicação de hash para todas as pastas compartilhadas neste

computador, clique em Permitir publicação de hash para todas as pastas
compartilhadas.
b. Para habilitar a publicação de hash somente para as pastas compartilhadas nas

quais o BranchCache está habilitado, clique em Permitir a publicação de hash
somente em pastas compartilhadas nas quais o BranchCache está habilitado.
c. Para não permitir a publicação de hash para todas as pastas compartilhadas no

computador, mesmo que o BranchCache esteja habilitado nos
compartilhamentos de arquivos, clique em Impedir a publicação de hash em
todas as pastas compartilhadas.
8. Clique em OK.
servidores de arquivos associados ao
domínio
Quando estiver usando Active Directory Domain Services (AD DS), você poderá usar o
Política de Grupo de domínio para habilitar a publicação de hash do BranchCache para
vários servidores de arquivos. Para fazer isso, você deve criar uma UO (unidade
organizacional), adicionar servidores de arquivos à UO, criar uma publicação de hash do
BranchCache Política de Grupo objeto (GPO) e, em seguida, configurar o GPO.
Consulte os tópicos a seguir para habilitar a publicação de hash para vários servidores
de arquivos.
Criar a unidade organizacional de servidores de arquivos BranchCache
Mover servidores de arquivos para a unidade organizacional de servidores de

arquivos BranchCache
Criar o Objeto de Política de Grupo de publicação de hash BranchCache
Configurar o Objeto de Política de Grupo de publicação de hash BranchCache

Criar a unidade organizacional de
servidores de arquivos BranchCache
Você pode usar este procedimento para criar uma UO (unidade organizacional) no AD
DS (Serviços de Domínio Active Directory) para servidores de arquivos BranchCache.

Para criar a unidade organizacional de servidores de

1. Em um computador em que AD DS está instalado, no Gerenciador do Servidor,
clique em Ferramentase clique em Usuários e Computadores do Active Directory.
O console de Usuários e Computadores do Active Directory é aberto.
2. No console de Usuários e Computadores do Active Directory, clique com o botão

direito do mouse no domínio ao qual você deseja adicionar uma UO. Por exemplo,
se o domínio for denominado exemplo.com, clique com o botão direito do mouse
em exemplo.com. Aponte para Novo e clique em Unidade Organizacional. A caixa
de diálogo Novo Objeto – Unidade Organizacional é aberta.
3. Na caixa de diálogo Novo Objeto – Unidade Organizacional , em Nome, digite

um nome para a nova UO. Por exemplo, se desejar denominar a UO de Servidores
de arquivos BranchCache, digite Servidores de arquivos BranchCache e clique em
OK.
Mover servidores de arquivos para a
unidade organizacional de servidores de
Você pode usar este procedimento para adicionar servidores de arquivos BranchCache a
uma UO (unidade organizacional) no AD DS (Serviços de Domínio Active Directory).

７ Observação
Você deve criar uma UO de servidores de arquivos BranchCache no console de

Usuários e Computadores do Active Directory antes de adicionar contas de
computador à UO com este procedimento. Para obter mais informações, consulte
criar a unidade organizacional de servidores de arquivos do BranchCache.
Para mover servidores de arquivos para a unidade

organizacional de servidores de arquivos BranchCache
1. Em um computador em que o AD DS está instalado, em Gerenciador do Servidor,
clique em ferramentase, em seguida, clique em Active Directory usuários e
computadores. O console de Usuários e Computadores do Active Directory é
aberto.
2. No console de Usuários e Computadores do Active Directory, localize a conta de

computador de um servidor de arquivos BranchCache, clique para selecionar a
conta e arraste e solte a conta de computador na UO de servidores de arquivos
BranchCache que você criou. Por exemplo, se você criou anteriormente uma UO
denominada servidores de arquivos do BranchCache, arraste e solte a conta de
computador na UO servidores de arquivos do BranchCache .
3. Repita a etapa anterior para cada servidor de arquivos BranchCache no domínio

que você deseja mover para a UO.
Criar o Objeto de Política de Grupo de
publicação de hash BranchCache
Você pode usar este procedimento para criar a publicação de hash BranchCache Política
de Grupo Objeto (GPO).

７ Observação
Antes de executar este procedimento, crie a unidade organizacional de servidores

de arquivos BranchCache e mova os servidores de arquivos para a UO. Para obter
mais informações, consulte Habilitar publicação de hash para servidores de
arquivos de membro de domínio.
Para criar a publicação de hash BranchCache Política de

Grupo Objeto


em Gerenciamento de Diretiva de Grupo e clique em OK.
4. No MMC do Gerenciamento de Diretiva de Grupo, expanda o caminho para a UO

dos servidores de arquivos BranchCache criada anteriormente. Por exemplo, se sua
floresta for nomeada como example.com, seu domínio será denominado
example1.com e sua UO for denominada Servidores de arquivos BranchCache,
expanda o seguinte caminho: Gerenciamento do Política de Grupo, Floresta:
example.com, Domínios, example1.com, Servidores de arquivos BranchCache.
5. Clique com o botão direito do mouse em Servidores de arquivos BranchCache e
clique em Criar um GPO nesse domínio e vinculá-lo aqui. A caixa de diálogo
Novo GPO é aberta. Em Nome, digite um nome para o novo GPO. Por exemplo, se
desejar denominar o objeto como Publicação de Hash do BranchCache, digite
Publicação de Hash do BranchCache. Clique em OK.
Configurar o Objeto de Política de
Grupo de publicação de hash
BranchCache
Você pode usar este procedimento para configurar a publicação de hash do

BranchCache Política de Grupo objeto (GPO) para que todos os servidores de arquivos
que você adicionou à sua UO tenham a mesma configuração de política de publicação
de hash aplicada a eles.

７ Observação
Antes de executar esse procedimento, você deve criar a unidade organizacional de

servidores de arquivos do BranchCache, mover os servidores de arquivos para a UO
e criar o GPO de publicação de hash do BranchCache. Para obter mais informações,
consulte habilitar a publicação de hash para servidores de arquivos do membro
do domínio.
Para configurar a publicação de hash do BranchCache

Política de Grupo objeto
1. execute Windows PowerShell como administrador, digite mmce pressione ENTER.
O Console de Gerenciamento Microsoft (MMC) é aberto.


em Gerenciamento de Diretiva de Grupo e clique em OK.
4. No MMC Gerenciamento de Diretiva de Grupo, expanda o caminho para o GPO de

publicação de hash do BranchCache criado anteriormente. Por exemplo, se sua
floresta se chama example.com, seu domínio é denominado example1.com e seu
GPO é chamado de publicação de hash do BranchCache, expanda o seguinte
caminho: Gerenciamento de política de grupo, floresta: example.com, domínios,
example1.com, política de grupo objetos, publicação de hash do BranchCache.
5. Clique com o botão direito do mouse no GPO Publicação de Hash do

BranchCache e clique em Editar. O console do Editor de Gerenciamento de Política
de Grupo é aberto.
6. No console do Editor de Gerenciamento de Política de Grupo, expanda o seguinte

caminho: configuração do computador, políticas, modelos administrativos, rede,
servidor do LanMan.
7. No console do Editor de Gerenciamento de Diretiva de Grupo, clique em Servidor

Lanman. No painel de detalhes, clique duas vezes em Publicação de Hash para
BranchCache. A caixa de diálogo Publicação de Hash para BranchCache é aberta.
8. Na caixa de diálogo Publicação de Hash para BranchCache, clique em Habilitado.
9. Em Opções, clique em Permitir publicação de hash para todas as pastas

compartilhadase clique em uma das opções a seguir:
a. Para habilitar a publicação de hash para todas as pastas compartilhadas de

todos os servidores de arquivos que você adicionou à UO, clique em Permitir
publicação de hash para todas as pastas compartilhadas.
b. Para habilitar a publicação de hash somente para as pastas compartilhadas nas

quais o BranchCache está habilitado, clique em Permitir a publicação de hash
somente em pastas compartilhadas nas quais o BranchCache está habilitado.
c. Para não permitir a publicação de hash para todas as pastas compartilhadas no

computador, mesmo que o BranchCache esteja habilitado nos
compartilhamentos de arquivos, clique em Impedir a publicação de hash em
todas as pastas compartilhadas.
10. Clique em OK.
７ Observação
Na maioria dos casos, é necessário salvar o console MMC e atualizar a exibição

para exibir as alterações de configuração feitas.
Habilitar BranchCache em um
compartilhamento de arquivos
(opcional)
Você pode usar este procedimento para habilitar o BranchCache em um

compartilhamento de arquivos.
） Importante
Você não precisará executar este procedimento se definir a configuração de

publicação de hash com o valor Permitir publicação de hash para todas as pastas
compartilhadas.

deste procedimento.
Para habilitar o BranchCache em um compartilhamento

de arquivos


em Pastas Compartilhadas. O Assistente para Pastas Compartilhadas é aberto com
o objeto Computador Local selecionado. Configure a Exibição que você preferir,
clique em Concluir e, em seguida, clique em OK.
4. Clique duas vezes em Pastas Compartilhadas (Local) e clique em

Compartilhamentos.
5. No painel de detalhes, clique com o botão direito do mouse em um

compartilhamento e clique em Propriedades. A caixa de diálogo Propriedades do
compartilhamento é aberta.
6. Na caixa de diálogo Propriedades, na guia Geral, clique em Offline Configurações.
A caixa de Configurações offline é aberta.
7. Verifique se Somente os arquivos e programas que os usuários especificam estão

disponíveis offline está selecionado e clique em Habilitar BranchCache.
8. Clique em OK duas vezes.

Implantar servidores de cache
Você pode usar esse procedimento para instalar e configurar servidores de cache
hospedados do BranchCache localizados em filiais nas quais você deseja implantar o
modo de cache hospedado do BranchCache. Com o BranchCache Windows Server 2016,
você pode implantar vários servidores de cache hospedados em uma filial.
） Importante
Esta etapa é opcional porque o modo de cache distribuído não requer um

computador de servidor de cache hospedado em filiais. Se você não estiver
planejando implantar o modo de cache hospedado em qualquer filial, não precisará
implantar um servidor de cache hospedado e não precisará executar as etapas
neste procedimento.
Você deve ser um membro de Administradores ou equivalente para executar este

procedimento.
Para instalar e configurar um servidor de cache

hospedado
1. No computador que você deseja configurar como um servidor de cache
hospedado, execute o comando a seguir em um prompt Windows PowerShell para
instalar o recurso BranchCache.
Install-WindowsFeature BranchCache -IncludeManagementTools
2. Configure o computador como um servidor de cache hospedado usando um dos

seguintes comandos:
Para configurar um computador não ingressado no domínio como um

servidor de cache hospedado, digite o seguinte comando no prompt
Windows PowerShell e pressione ENTER.
Enable-BCHostedServer
Para configurar um computador ingressado no domínio como um servidor de
cache hospedado e registrar um ponto de conexão de serviço no Active
Directory para descoberta automática de servidor de cache hospedado por
computadores cliente, digite o seguinte comando no prompt do Windows
Enable-BCHostedServer -RegisterSCP
3. Para verificar a configuração correta do servidor de cache hospedado, digite o

seguinte comando no prompt Windows PowerShell e pressione ENTER.
Get-BCStatus
７ Observação
Depois de executar esse comando, na seção

HostedCacheServerConfiguration, o valor de HostedCacheServerIsEnabled é
True. Se você tiver configurado um servidor de cache hospedado ingressado
no domínio para registrar um SCP (ponto de conexão de serviço) no Active
Directory, o valor de HostedCacheScpRegistrationEnabled será True.
Realizar o hash prévio e o pré-
carregamento de conteúdo em
servidores de cache hospedado
(opcionais)
Você pode usar esse procedimento para forçar a criação de informações de conteúdo ,
também chamadas de hashes, em servidores de arquivos e Web habilitados para
BranchCache. Você também pode coletar os dados em servidores Web e arquivos em
pacotes que podem ser transferidos para servidores de cache hospedado remotos. Isso
fornece a capacidade de pré-carregar conteúdo em servidores de cache hospedados
remotos para que os dados estão disponíveis para o primeiro acesso do cliente.

procedimento.
Para pré-hash de conteúdo e pré-carregar o conteúdo em

servidores de cache hospedados
1. Faça logoff no arquivo ou servidor Web que contém os dados que você deseja
pré-carregar e identifique as pastas e arquivos que você deseja carregar em um ou
mais servidores de cache hospedado remotos.
2. Execute Windows PowerShell como administrador. Para cada pasta e arquivo,

execute Publish-BCFileContent Publish-BCWebContent o comando ou o comando ,
dependendo do tipo de servidor de conteúdo, para disparar a geração de hash e
adicionar dados a um pacote de dados.
3. Depois que todos os dados foram adicionados ao pacote de dados, exporte-os

usando o Export-BCCachePackage comando para produzir um arquivo de pacote de
dados.
4. Mova o arquivo do pacote de dados para os servidores de cache hospedado

remotos usando sua escolha de tecnologia de transferência de arquivos. FTP, SMB,
HTTP, DVD e discos rígidos portáteis são todos transporte viáveis.
5. Importe o arquivo do pacote de dados nos servidores de cache hospedado
remotos usando o Import-BCCachePackage comando .
Configurar BranchCache em
computadores cliente
Você pode usar os tópicos a seguir para configurar computadores cliente de membro
de domínio e não membro de domínio como clientes do modo de cache distribuído do
BranchCache ou de host hospedado.
Usar Política de Grupo para configurar computadores cliente membro do domínio
usar Windows PowerShell para configurar computadores cliente que não são
membros do domínio
Configurar regras de firewall para membros que não sejam de domínio para
permitir o tráfego do BranchCache
verificar Configurações do computador cliente

Usar Política de Grupo para configurar
computadores cliente membro do
domínio
nesta seção, você cria um objeto Política de Grupo para todos os computadores em sua
organização, configura os computadores cliente membro do domínio com o modo de
cache distribuído ou o modo de cache hospedado e configura Windows Firewall com
segurança avançada para permitir o tráfego do BranchCache.
Esta seção contém os procedimentos a seguir.
1. Para criar um objeto de Política de Grupo e configurar modos de BranchCache
2. para configurar o Firewall Windows com regras de tráfego de entrada de

segurança avançada
3. para configurar o Firewall Windows com regras de tráfego de saída de segurança

avançada
 Dica
No procedimento a seguir, você é instruído a criar um objeto Política de Grupo na

política de domínio padrão, no entanto, você pode criar o objeto em uma UO
(unidade organizacional) ou em outro contêiner que seja apropriado para sua
implantação.
Você deve ser membro de Admins. do domínio ou equivalente a executar esses

procedimentos.
Para criar um objeto de Política de Grupo e

configurar modos de BranchCache
1. Em um computador no qual a função de servidor Active Directory Domain Services
está instalada, em Gerenciador do Servidor, clique em ferramentase, em seguida,
clique em Gerenciamento de política de grupo. O console de gerenciamento do
Política de Grupo é aberto.
2. No console de gerenciamento do Política de Grupo, expanda o seguinte caminho:

floresta:example.com, domínios, example.com, política de grupo objetos, em que
example.com é o nome do domínio em que as contas de computador cliente do
BranchCache que você deseja configurar estão localizadas.
3. Clique com o botão direito do mouse em Objetos de Diretiva de Grupo e clique

em Novo. A caixa de diálogo Novo GPO é aberta. Em nome, digite um nome para
o novo objeto de política de grupo (GPO). Por exemplo, se desejar denominar o
objeto como Computadores Cliente BranchCache, digite Computadores Cliente
BranchCache. Clique em OK.

Diretiva de Grupo está selecionado e, no painel de detalhes, clique com o botão
direito do mouse no GPO que você acabou de criar. Por exemplo, se você
Editar. O console do Editor de Gerenciamento de Política de Grupo é aberto.
5. No console do Editor de Gerenciamento de Política de Grupo, expanda o seguinte

caminho: configuração do computador, políticasmodelos administrativos:
definições de política (arquivos ADMX) recuperadas do computador local, rede,
BranchCache.
6. Clique em BranchCache e, no painel de detalhes, clique duas vezes em Ativar o

BranchCache. A caixa de diálogo configuração de política é aberta.
7. Na caixa de diálogo Ativar o BranchCache, clique em Habilitado e em OK.
8. Para habilitar o modo de cache distribuído do BranchCache, no painel de detalhes,

clique duas vezes em definir o modo de cache distribuído do BranchCache. A
caixa de diálogo configuração de política é aberta.
9. Na caixa de diálogo Definir o modo Cache Distribuído do BranchCache, clique em

Habilitado e em OK.
10. Se você tiver uma ou mais filiais em que você está implantando o BranchCache no
modo de cache hospedado e tiver implantado servidores de cache hospedados
nesses escritórios, clique duas vezes em habilitar descoberta automática de cache
hospedado pelo ponto de conexão de serviço. A caixa de diálogo configuração
de política é aberta.
11. Na caixa de diálogo habilitar descoberta automática de cache hospedado por
ponto de conexão de serviço , clique em habilitadoe em OK.
７ Observação
Quando você habilita as configurações de política definir o modo de cache

distribuído do BranchCache e habilitar descoberta automática de cache
hospedado por serviço , os computadores cliente operam no modo de cache
distribuído do BranchCache, a menos que encontrem um servidor de cache
hospedado na filial, em que ponto eles operam no modo de cache
hospedado.
12. Use os procedimentos a seguir para definir as configurações de firewall em

computadores cliente usando Política de Grupo.
para configurar o Firewall Windows com regras

de tráfego de entrada de segurança avançada
1. No console de gerenciamento do Política de Grupo, expanda o seguinte caminho:
floresta:example.com, domínios, example.com, política de grupo objetos, em que
example.com é o nome do domínio em que as contas de computador cliente do
BranchCache que você deseja configurar estão localizadas.

Diretiva de Grupo está selecionado e, no painel de detalhes, clique no GPO dos
computadores cliente BranchCache criados anteriormente. Por exemplo, se você
Editar. O console do Editor de Gerenciamento de Política de Grupo é aberto.
3. no console do Editor de Gerenciamento de Política de Grupo, expanda o seguinte

caminho: configuração do computador, políticas, Windows Configurações,
Configurações de segurança, Windows firewall com segurança avançada,
Windows firewall com segurança avançada-LDAP, entrada Regras.
4. Clique com o botão direito do mouse em Regras de Entrada e clique em Nova

Regra. O Assistente para Nova Regra de Entrada é aberto.
5. Em tipo de regra, clique em predefinido, expanda a lista de opções e clique em

BranchCache-Recuperação de conteúdo (usa http). Clique em Próximo.
6. Em Regras Predefinidas, clique em Avançar.
7. Em Ação, verifique se Permitir a conexão está selecionado e clique em Concluir.
） Importante
Selecione Permitir a conexão para que o cliente BranchCache possa receber o

tráfego nesta porta.
8. Para criar uma exceção do firewall do WS-Discovery, clique novamente com o

botão direito do mouse em Regras de Entrada e clique em Nova Regra. O
Assistente para Nova Regra de Entrada é aberto.

BranchCache – descoberta de mesmo nível (usa WSD). Clique em Próximo.
） Importante
Selecione Permitir a conexão para que o cliente BranchCache possa receber o

para configurar o Firewall Windows com regras

de tráfego de saída de segurança avançada
1. No console do Editor de Gerenciamento de Diretiva de Grupo, clique com o botão
direito do mouse em Regras de Saída e clique em Nova Regra. O Assistente para
Nova Regra de Saída é aberto.

BranchCache-Recuperação de conteúdo (usa http). Clique em Próximo.
） Importante
Selecione Permitir a conexão para que o cliente BranchCache possa enviar o
5. Para criar uma exceção do firewall do WS-Discovery, clique novamente com o

botão direito do mouse em Regras de Saída e clique em Nova Regra. O Assistente
para Nova Regra de Saída é aberto.

BranchCache – descoberta de mesmo nível (usa WSD). Clique em Próximo.
） Importante
Selecione Permitir a conexão para que o cliente BranchCache possa enviar o

Usar Windows PowerShell para
configurar computadores cliente que
não são membros do domínio
Você pode usar esse procedimento para configurar manualmente um computador

cliente BranchCache para o modo de cache distribuído ou o modo de cache hospedado.
７ Observação
Se você configurou computadores cliente BranchCache usando a Diretiva de

Grupo, as configurações da Diretiva de Grupo substituirão qualquer configuração
manual de computadores cliente aos quais as diretivas foram aplicadas.

deste procedimento.
Para habilitar o modo de cache distribuído ou hospedado

do BranchCache
1. No computador cliente BranchCache que você deseja configurar, execute Windows
PowerShell como administrador e, em seguida, execute um dos seguintes.
Para configurar o computador cliente para o modo de cache distribuído do

BranchCache, digite o comando a seguir e pressione ENTER.
Enable-BCDistributed
Para configurar o computador cliente para o modo de cache hospedado do

BranchCache, digite o comando a seguir e pressione ENTER.
Enable-BCHostedClient
 Dica
Se você quiser especificar os servidores de cache hospedado disponíveis,

use -ServerNames o parâmetro com uma lista separada por vírgulas dos
servidores de cache hospedados como o valor do parâmetro. Por
exemplo, se você tiver dois servidores de cache hospedados chamados
HCS1 e HCS2, configure o computador cliente para o modo de cache
hospedado com o comando a seguir.
Enable-BCHostedClient -ServerNames HCS1,HCS2

Configurar regras de firewall para
membros não associados a domínio
para permitir tráfego BranchCache
Você pode usar as informações neste tópico para configurar produtos de firewall de
terceiros e configurar um computador cliente manualmente com regras de firewall que
permitam a execução do BranchCache no modo de cache distribuído.
７ Observação
Se você configurou computadores cliente BranchCache usando a Diretiva de

Grupo, as configurações da Diretiva de Grupo substituirão qualquer
configuração manual de computadores cliente aos quais as diretivas foram
aplicadas.
Se você implantou o BranchCache com DirectAccess, pode usar as
configurações deste tópico para configurar regras de IPsec para permitir o
tráfego de BranchCache.
A associação a Administradores ou equivalente é o requisito mínimo para fazer essas

alterações de configuração.
[MS-PCCRD]: Protocolo de descoberta de

Caching e recuperação
Os clientes de cache distribuído devem permitir o tráfego MS-PCCRD de entrada e de
saída executado no protocolo WS-Discovery.
As configurações de firewall devem permitir o tráfego multicast, além do tráfego de

entrada e de saída. Você pode usar as seguintes configurações para definir exceções de
firewall para o modo de cache distribuído.
Multicast IPv4: 239.255.255.250
Multicast IPv6: FF02::C

Tráfego de entrada: porta local: 3702, Porta remota: efêmero
Tráfego de saída: porta local: efêmero, porta remota: 3702
Programa: %systemroot%\system32\svchost.exe (Serviço BranchCache [PeerDistSvc])
[MS-PCCRR]: Par Content Caching e

Recuperação: Protocolo de Recuperação
Os clientes de cache distribuído devem permitir o tráfego MS-PCCRR de entrada e de
saída executado no protocolo HTTP 1.1 conforme documentado na RFC (solicitação de
comentários) 2616.
As configurações de firewall devem permitir o tráfego de entrada e de saída. Você pode

usar as seguintes configurações para definir exceções de firewall para o modo de cache
distribuído.
Tráfego de entrada: porta local: 80, Porta remota: efêmero
Tráfego de saída: porta local: efêmero, porta remota: 80

Verificar o computador cliente
Configurações
Você pode usar esse procedimento para verificar se o computador cliente está
configurado corretamente para o BranchCache.
７ Observação
Este procedimento inclui etapas para atualizar manualmente Política de Grupo e

para reiniciar o serviço BranchCache. Você não precisará executar essas ações se
reinicializar o computador, pois elas ocorrerão automaticamente nessa
circunstância.

procedimento.
Para verificar as configurações do computador cliente do

BranchCache
1. Para atualizar Política de Grupo no computador cliente cuja configuração do
BranchCache você deseja verificar, execute Windows PowerShell como
administrador, digite o comando a seguir e pressione ENTER.
gpupdate /force
2. Para computadores cliente configurados no modo de cache hospedado e

configurados para descobrir automaticamente os servidores de cache hospedados
por ponto de conexão de serviço, execute os comandos a seguir para parar e
reiniciar o serviço BranchCache.
net stop peerdistsvc
net start peerdistsvc
3. Inspecione o modo operacional BranchCache atual executando o comando a

seguir.
Get-BCStatus
4. Em Windows PowerShell, revise a saída do comando Get-BCStatus.
O valor de BranchCacheIsEnabled deve ser True.
Em ClientSettings, o valor de CurrentClientMode deve ser DistributedClient ou

HostedCacheClient, dependendo do modo configurado usando este guia.
Em ClientSettings, se você configurou o modo de cache hospedado e forneceu os

nomes dos servidores de cache hospedados durante a configuração ou se o cliente
tiver localizado automaticamente servidores de cache hospedados usando pontos
de conexão de serviço, HostedCacheServerList deverá ter um valor igual ao nome
ou aos nomes dos servidores de cache hospedados. Por exemplo, se o servidor de
cache hospedado for chamado HCS1 e seu domínio for corp.contoso.com, o valor
de HostedCacheServerList será HCS1.corp.contoso.com.
5. Se qualquer uma das configurações do BranchCache listadas acima não tiver os

valores corretos, use as etapas neste guia para verificar as configurações do
Política de Grupo ou política de computador local, bem como as exceções de
firewall que você configurou e verifique se elas estão corretas. Além disso, reinicie
o computador ou siga as etapas neste procedimento para atualizar Política de
Grupo e reiniciar o serviço BranchCache.
DirectAccess
Você pode usar este tópico para uma breve visão geral do DirectAccess, incluindo os
sistemas operacionais de servidor e cliente que dão suporte ao DirectAccess e para links
para a documentação adicional do DirectAccess para Windows Server.
７ Observação
Além deste tópico, a documentação do DirectAccess a seguir está disponível.
Caminhos de implantação do DirectAccess no Windows Server

Pré-requisitos para implantação do DirectAccess
Configurações do DirectAccess sem suporte
Guias de laboratório de teste do DirectAccess
Problemas conhecidos do DirectAccess
Planejamento de capacidade do DirectAccess
Ingresso no Domínio Offline do DirectAccess
Como solucionar problemas do DirectAccess
Implantar um Único Servidor DirectAccess Usando o Assistente de
Introdução
Implantar um único servidor do DirectAccess com configurações avançadas
Adicionar o DirectAccess a uma implantação de acesso remoto existente
(VPN)
O DirectAccess permite conectividade para usuários remotos para recursos de rede da

organização sem a necessidade de conexões VPN (Rede Virtual Privada) tradicionais.
Com as conexões do DirectAccess, os computadores cliente remotos estão sempre
conectados à sua organização – não há necessidade de usuários remotos iniciarem e
interromperem conexões, como é necessário com conexões VPN. Além disso, os
administradores de TI podem gerenciar computadores cliente DirectAccess sempre que
estiverem em execução e conectados à Internet.
） Importante
Não tente implantar o Acesso Remoto em uma VM (máquina virtual) no Microsoft
Azure. Não há suporte para o uso do Acesso Remoto no Microsoft Azure. Você não
pode usar o Acesso Remoto em uma VM do Azure para implantar VPN,
DirectAccess ou qualquer outro recurso de Acesso Remoto em Windows Server
2016 ou versões anteriores do Windows Server. Para obter mais informações,
consulte Suporte de software do servidor Microsoft para máquinas virtuais do
Microsoft Azure .
O DirectAccess fornece suporte apenas para clientes ingressados no domínio que

incluem suporte do sistema operacional para DirectAccess.
Os sistemas operacionais cliente a seguir dão suporte ao DirectAccess.
Windows 10 Enterprise LTSB (Branch de Manutenção de Longo Prazo) de 2015

O DNS (Sistema de Nomes de Domínio) é um dos conjuntos padrão do setor de

protocolos que compõem o TCP/IP e, juntos, o cliente DNS e o servidor DNS fornecem
serviços de resolução de nomes de mapeamento de endereço nome-IP do computador
para computadores e usuários.
７ Observação
Além deste tópico, o conteúdo DNS a seguir está disponível.
O que há de novo no cliente DNS

O que há de novo no servidor DNS
Guia de cenário de política DNS
Em Windows Server 2016, o DNS é uma função de servidor que você pode instalar
usando comandos Gerenciador do Servidor ou Windows PowerShell. Se você estiver
instalando uma nova floresta e domínio do Active Directory, o DNS será instalado
automaticamente com o Active Directory como o servidor de Catálogo Global para a
floresta e o domínio.
Active Directory Domain Services (AD DS) usa o DNS como seu mecanismo de
localização do controlador de domínio. Quando qualquer uma das principais operações
do Active Directory é executada, como autenticação, atualização ou pesquisa, os
computadores usam DNS para localizar controladores de domínio do Active Directory.
Além disso, os controladores de domínio usam DNS para localizar uns aos outros.
O serviço cliente DNS está incluído em todas as versões de cliente e servidor do sistema
operacional Windows e está em execução por padrão após a instalação do sistema
operacional. Quando você configura uma conexão de rede TCP/IP com o endereço IP de
um servidor DNS, o cliente DNS consulta o servidor DNS para descobrir controladores
de domínio e resolver nomes de computador para endereços IP. Por exemplo, quando
um usuário de rede com uma conta de usuário do Active Directory faz logon em um
domínio do Active Directory, o serviço cliente DNS consulta o servidor DNS para
localizar um controlador de domínio para o domínio do Active Directory. Quando o
servidor DNS responde à consulta e fornece o endereço IP do controlador de domínio
para o cliente, o cliente entra em contato com o controlador de domínio e o processo
de autenticação pode começar.
O servidor DNS Windows Server 2016 e os serviços de cliente DNS usam o protocolo
DNS incluído no conjunto de protocolos TCP/IP. O DNS faz parte da camada de
aplicativo do modelo de referência TCP/IP, conforme mostrado na ilustração a seguir.
O DNS (Sistema de Nomes de Domínio) é um dos conjuntos padrão do setor de

protocolos que compõem o TCP/IP e, juntos, o cliente DNS e o servidor DNS fornecem
serviços de resolução de nomes de mapeamento de endereço nome-IP do computador
para computadores e usuários.
７ Observação
Além deste tópico, o conteúdo DNS a seguir está disponível.

O que há de novo no servidor DNS
Guia de cenário de política DNS
Em Windows Server 2016, o DNS é uma função de servidor que você pode instalar
usando comandos Gerenciador do Servidor ou Windows PowerShell. Se você estiver
instalando uma nova floresta e domínio do Active Directory, o DNS será instalado
automaticamente com o Active Directory como o servidor de Catálogo Global para a
floresta e o domínio.
Active Directory Domain Services (AD DS) usa o DNS como seu mecanismo de
localização do controlador de domínio. Quando qualquer uma das principais operações
do Active Directory é executada, como autenticação, atualização ou pesquisa, os
computadores usam DNS para localizar controladores de domínio do Active Directory.
Além disso, os controladores de domínio usam DNS para localizar uns aos outros.
O serviço cliente DNS está incluído em todas as versões de cliente e servidor do sistema
operacional Windows e está em execução por padrão após a instalação do sistema
operacional. Quando você configura uma conexão de rede TCP/IP com o endereço IP de
um servidor DNS, o cliente DNS consulta o servidor DNS para descobrir controladores
de domínio e resolver nomes de computador para endereços IP. Por exemplo, quando
um usuário de rede com uma conta de usuário do Active Directory faz logon em um
domínio do Active Directory, o serviço cliente DNS consulta o servidor DNS para
localizar um controlador de domínio para o domínio do Active Directory. Quando o
servidor DNS responde à consulta e fornece o endereço IP do controlador de domínio
para o cliente, o cliente entra em contato com o controlador de domínio e o processo
de autenticação pode começar.
O servidor DNS Windows Server 2016 e os serviços de cliente DNS usam o protocolo
DNS incluído no conjunto de protocolos TCP/IP. O DNS faz parte da camada de
aplicativo do modelo de referência TCP/IP, conforme mostrado na ilustração a seguir.
o que há de novo no servidor DNS no
Windows server
Este tópico descreve a funcionalidade de servidor DNS (sistema de nomes de domínio)

que é nova ou alterada no Windows Server 2016.
no Windows Server 2016, o servidor DNS oferece suporte aprimorado nas seguintes
áreas.
Funcionalidade Novo ou Descrição

melhorado
Políticas de Novo Você pode configurar as políticas de DNS para especificar como
DNS um servidor DNS responde a consultas DNS. As respostas DNS
podem ser baseadas no endereço IP do cliente (local), na hora
do dia e em vários outros parâmetros. As políticas de DNS
habilitam o DNS com reconhecimento de local, o gerenciamento
de tráfego, o balanceamento de carga, o DNS de divisão e
outros cenários.
Limitação de Novo Você pode habilitar a limitação da taxa de resposta em seus

taxa de servidores DNS. Ao fazer isso, você evita a possibilidade de
resposta (RRL) sistemas mal-intencionados que usam seus servidores DNS para
iniciar um ataque de negação de serviço em um cliente DNS.
Autenticação Novo Você pode usar os registros TLSA (autenticação de segurança de

baseada em camada de transporte) para fornecer informações aos clientes
DNS de DNS que afirmam a qual AC eles devem esperar um certificado
entidades para seu nome de domínio. Isso impede ataques man-in-the-
nomeadas Middle, em que alguém pode corromper o cache DNS para
(SUNDANÊS) apontar para seu próprio site e fornecer um certificado emitido
por uma autoridade de certificação diferente.
Suporte a Novo você pode adicionar registros que não são explicitamente
registro suportados pelo servidor DNS Windows usando a funcionalidade
desconhecido de registro desconhecida.
Dicas de raiz Novo Você pode usar o suporte de dicas de raiz IPV6 nativo para
IPv6 executar a resolução de nomes da Internet usando os servidores
raiz IPV6.
Funcionalidade Novo ou Descrição
melhorado
suporte a Melhoria novos cmdlets Windows PowerShell estão disponíveis para o

Windows de servidor DNS.
PowerShell
Políticas de DNS
Você pode usar a política DNS para gerenciamento de tráfego baseado em Geo-
Location, respostas de DNS inteligente com base na hora do dia, para gerenciar um
único servidor DNS configurado para implantação de divisão, aplicar filtros em consultas
DNS e muito mais. Os itens a seguir fornecem mais detalhes sobre esses recursos.
Balanceamento de carga do aplicativo. Quando você implantou várias instâncias

de um aplicativo em locais diferentes, você pode usar a política DNS para
balancear a carga de tráfego entre as diferentes instâncias de aplicativo, alocando
dinamicamente a carga de tráfego para o aplicativo.
Gerenciamento de tráfego baseado em Geo-Location. Você pode usar a política

DNS para permitir que servidores DNS primários e secundários respondam a
consultas de cliente DNS com base na localização geográfica do cliente e do
recurso ao qual o cliente está tentando se conectar, fornecendo ao cliente o
endereço IP do recurso mais próximo.
DNS de divisão de cérebro. Com o DNS de divisão-cérebro, os registros DNS são

divididos em escopos de zona diferentes no mesmo servidor DNS, e os clientes
DNS recebem uma resposta com base no fato de os clientes serem clientes
internos ou externos. Você pode configurar o DNS de divisão-cérebro para Active
Directory zonas integradas ou para zonas em servidores DNS autônomos.
Filtragem. Você pode configurar a política DNS para criar filtros de consulta
baseados em critérios fornecidos por você. Os filtros de consulta na política DNS
permitem configurar o servidor DNS para responder de uma maneira
personalizada com base na consulta DNS e no cliente DNS que envia a consulta
DNS.
Análises forenses. Você pode usar a política DNS para redirecionar clientes DNS
mal-intencionados para um endereço IP não existente em vez de direcioná-los
para o computador que estão tentando acessar.
Hora do redirecionamento com base no dia. Você pode usar a política DNS para
distribuir o tráfego de aplicativos em diferentes instâncias distribuídas
geograficamente de um aplicativo usando políticas de DNS com base na hora do
dia.
Você também pode usar políticas de DNS para Active Directory zonas DNS integradas.
Para obter mais informações, consulte o Guia de cenários de política de DNS.
Limitação da taxa de resposta

Você pode definir configurações de RRL para controlar como responder a solicitações
para um cliente DNS quando o servidor recebe várias solicitações direcionadas ao
mesmo cliente. Ao fazer isso, você pode impedir que alguém envie um ataque de
negação de serviço (dos) usando seus servidores DNS. Por exemplo, uma rede de bot
pode enviar solicitações para o servidor DNS usando o endereço IP de um terceiro
computador como o solicitante. Sem o RRL, os servidores DNS podem responder a
todas as solicitações, inundando o terceiro computador. Ao usar o RRL, você pode
definir as seguintes configurações:
Respostas por segundo. Esse é o número máximo de vezes que a mesma resposta
é dada a um cliente dentro de um segundo.
Erros por segundo. Este é o número máximo de vezes que uma resposta de erro é
enviada para o mesmo cliente dentro de um segundo.
Janela. Esse é o número de segundos para o qual as respostas a um cliente serão

suspensas se muitas solicitações forem feitas.
Taxa de perda. É com que frequência o servidor DNS responde a uma consulta
durante as respostas de tempo que são suspensas. Por exemplo, se o servidor
suspender as respostas a um cliente por 10 segundos, e a taxa de vazamento for 5,
o servidor ainda responderá a uma consulta para cada 5 consultas enviadas. Isso
permite que os clientes legítimos obtenham respostas mesmo quando o servidor
DNS estiver aplicando a limitação de taxa de resposta em sua sub-rede ou FQDN.
Taxa de TC. Isso é usado para instruir o cliente a tentar se conectar com TCP
quando as respostas para o cliente são suspensas. Por exemplo, se a taxa de TC for
3 e o servidor suspender as respostas para um determinado cliente, o servidor
emitirá uma solicitação de conexão TCP para cada 3 consultas recebidas. Verifique
se o valor da taxa de TC é menor que a taxa de vazamento, para dar ao cliente a
opção de se conectar via TCP antes de vazar as respostas.
Máximo de respostas. Esse é o número máximo de respostas que o servidor emite

para um cliente enquanto as respostas são suspensas.
DomíniosdaList de permissão. Esta é uma lista de domínios a serem excluídos das
configurações de RRL.
Sub-redes de permissões. Esta é uma lista de sub-redes a serem excluídas das

configurações de RRL.
Permitir interfaces de servidordeList. Esta é uma lista de interfaces do servidor

DNS a ser excluída das configurações de RRL.
Suporte ao SUNDANÊS
Você pode usar o suporte do SUNDANÊS (RFC 6394 e 6698) para especificar para seus
clientes DNS qual AC eles devem esperar que os certificados sejam emitidos para os
nomes de domínios hospedados no seu servidor DNS. Isso impede uma forma de
ataque man-in-the-Middle, em que alguém é capaz de corromper um cache DNS e
apontar um nome DNS para seu próprio endereço IP.
Por exemplo, imagine que você hospede um site seguro que usa SSL em
www.contoso.com usando um certificado de uma autoridade bem conhecida
chamada CA1. Alguém ainda poderá obter um certificado para www.contoso.com de
uma autoridade de certificação diferente, e não tão conhecida, denominada Ca2. Em
seguida, a entidade que hospeda o site da www.contoso.com falsa pode ser capaz de
corromper o cache DNS de um cliente ou servidor para apontar www.contoto.com
para seu site falso. O usuário final recebe um certificado de CA2 e pode simplesmente
refirmá-lo e conectar-se ao site falso. Com o SUNDANÊS, o cliente fará uma solicitação
ao servidor DNS para contoso.com solicitando o registro TLSA e aprenderia que o
certificado para www.contoso.com foi emitido por CA1. Se for apresentado um
certificado de outra CA, a conexão será anulada.
Suporte a registro desconhecido

Um "registro desconhecido" é um RR cujo formato RDATA não é conhecido pelo
servidor DNS. o suporte recém-adicionado para tipos de registro desconhecido (RFC
3597) significa que você pode adicionar os tipos de registro sem suporte no Windows
zonas de servidor DNS no formato binário durante a transmissão. o resolvedor de cache
Windows já tem a capacidade de processar tipos de registros desconhecidos. Windows
servidor DNS não faz nenhum processamento específico de registro para os registros
desconhecidos, mas envia-o de volta em respostas se as consultas forem recebidas para
ele.
Dicas de raiz IPv6
as dicas de raiz IPV6, conforme publicado pela IANA, foram adicionadas ao servidor
DNS Windows. As consultas de nome de Internet agora podem usar servidores raiz IPv6
para executar resoluções de nomes.
Suporte ao Windows PowerShell

os novos cmdlets e parâmetros de Windows PowerShell a seguir são introduzidos em
Add-DnsServerRecursionScope. Esse cmdlet cria um novo escopo de recursão no

servidor DNS. Os escopos de recursão são usados pelas políticas de DNS para
especificar uma lista de encaminhadores a serem usados em uma consulta DNS.
Remove-DnsServerRecursionScope. Esse cmdlet remove escopos de recursão

existentes.
Set-DnsServerRecursionScope. Esse cmdlet altera as configurações de um escopo

de recursão existente.
Get-DnsServerRecursionScope. Esse cmdlet recupera informações sobre escopos

de recursão existentes.
Add-DnsServerClientSubnet. Esse cmdlet cria uma nova sub-rede de cliente DNS.

As sub-redes são usadas por políticas DNS para identificar onde um cliente DNS
está localizado.
Remove-DnsServerClientSubnet. Esse cmdlet remove sub-redes de cliente DNS

existentes.
Set-DnsServerClientSubnet. Esse cmdlet altera as configurações de uma sub-rede

de cliente DNS existente.
Get-DnsServerClientSubnet. Esse cmdlet recupera informações sobre sub-redes

de cliente DNS existentes.
Add-DnsServerQueryResolutionPolicy. Esse cmdlet cria uma nova política de

resolução de consulta DNS. As políticas de resolução de consulta DNS são usadas
para especificar como ou se uma consulta é respondeda, com base em critérios
diferentes.
Remove-DnsServerQueryResolutionPolicy. Esse cmdlet remove as políticas DNS

existentes.
Set-DnsServerQueryResolutionPolicy. Esse cmdlet altera as configurações de uma
política DNS existente.
Get-DnsServerQueryResolutionPolicy. Esse cmdlet recupera informações sobre

políticas DNS existentes.
Enable-DnsServerPolicy. Esse cmdlet habilita políticas DNS existentes.
Disable-DnsServerPolicy. Esse cmdlet desabilita as políticas DNS existentes.
Add-DnsServerZoneTransferPolicy. Esse cmdlet cria uma nova política de

transferência de zona do servidor DNS. As políticas de transferência de zona DNS
especificam se uma transferência de zona deve ser negada ou ignorada com base
em critérios diferentes.
Remove-DnsServerZoneTransferPolicy. Esse cmdlet remove as políticas de

transferência de zona do servidor DNS existentes.
Set-DnsServerZoneTransferPolicy. Esse cmdlet altera as configurações de uma

política de transferência de zona do servidor DNS existente.
Get-DnsServerResponseRateLimiting. Esse cmdlet recupera as configurações de

RRL.
Set-DnsServerResponseRateLimiting. Esse cmdlet altera os settigns RRL.
Add-DnsServerResponseRateLimitingExceptionlist. Esse cmdlet cria uma lista de

exceções RRL no servidor DNS.
Get-DnsServerResponseRateLimitingExceptionlist. Esse cmdlet recupera listas de

excception RRL.
Remove-DnsServerResponseRateLimitingExceptionlist. Esse cmdlet remove uma

lista de exceções RRL existente.
Set-DnsServerResponseRateLimitingExceptionlist. Esse cmdlet altera as listas de

exceção RRL.
Add-DnsServerResourceRecord. Esse cmdlet foi atualizado para dar suporte ao

tipo de registro desconhecido.
Get-DnsServerResourceRecord. Esse cmdlet foi atualizado para dar suporte ao

tipo de registro desconhecido.
Remove-DnsServerResourceRecord. Esse cmdlet foi atualizado para dar suporte

ao tipo de registro desconhecido.
Set-DnsServerResourceRecord. Esse cmdlet foi atualizado para dar suporte ao tipo
de registro desconhecido
Para obter mais informações, consulte os tópicos Windows Server 2016 Windows
PowerShell referência de comando a seguir.
Módulo DnsServer
Módulo DnsClient
Referências adicionais
Novidades no cliente DNS no Windows
Server 2016
Este tópico descreve a funcionalidade do cliente DNS (Sistema de Nomes de Domínio)

que é nova ou alterada no Windows 10 e Windows Server 2016 e versões posteriores
desses sistemas operacionais.
Atualizações para o cliente DNS

Associação de serviço do cliente DNS: Windows 10, o serviço cliente DNS oferece
suporte aprimorado para computadores com mais de um interface de rede. Para
computadores multi-homed, a resolução de DNS é otimizada das seguintes maneiras:
Quando um servidor DNS configurado em uma interface específica é usado para

resolver uma consulta DNS, o serviço cliente DNS será aderido a essa interface
antes de enviar a consulta DNS.
Ao se vincular a uma interface específica, o cliente DNS pode especificar

claramente a interface em que ocorre a resolução de nomes, permitindo que os
aplicativos otimizem as comunicações com o cliente DNS por esse interface de
rede.
Se o servidor DNS usado for designado por uma configuração Política de Grupo
do NRPT (Tabela de Políticas de Resolução de Nomes), o serviço cliente DNS não
se vinculará a uma interface específica.
７ Observação
Alterações no serviço cliente DNS no Windows 10 também estão presentes em

computadores que executam Windows Server 2016 e versões posteriores.
Novidades do servidor DNS no Windows Server 2016
Visão geral do DNS do Anycast
Este tópico fornece informações sobre como o DNS do Anycast funciona.
O que é Anycast?
Anycast é uma tecnologia que fornece vários caminhos de roteamento para um grupo
de pontos de extremidade que recebem cada um o mesmo endereço IP. Cada
dispositivo no grupo anuncia o mesmo endereço em uma rede e os protocolos de
roteamento são usados para escolher qual é o melhor destino.
O Anycast permite dimensionar um serviço sem estado, como DNS ou HTTP, colocando
vários nós atrás do mesmo endereço IP e usando o roteamento ECMP (multi-caminho
de custo igual) para direcionar o tráfego entre esses nós. Anycast é diferente do unicast,
no qual cada ponto de extremidade tem seu próprio endereço IP separado.
Por que usar o Anycast com DNS?

Com o DNS do Anycast, você pode habilitar um servidor DNS ou um grupo de
servidores para responder a consultas DNS com base na localização geográfica de um
cliente DNS. Isso pode aprimorar o tempo de resposta DNS e simplificar as
configurações do cliente DNS. O DNS do Anycast também fornece uma camada extra
de redundância e pode ajudar a proteger contra ataques de negação de serviço de DNS.
Como o DNS do Anycast funciona

O DNS anycast funciona usando protocolos de roteamento, como BGP (Border Gateway
Protocol) para enviar consultas DNS para um servidor DNS preferencial ou grupo de
servidores DNS (por exemplo: um grupo de servidores DNS gerenciados por um
balanceador de carga). Esse design pode otimizar as comunicações DNS obtendo
respostas DNS de um servidor DNS mais próximo de um cliente.
Com o Anycast, os servidores que existem em várias localizações geográficas anunciam

um único endereço IP idêntico ao gateway local (roteador). Quando um cliente DNS
inicia uma consulta para o endereço Anycast, as rotas disponíveis são avaliadas e a
consulta DNS é enviada para o local preferencial. Em geral, esse local é o mais próximo
com base na topologia de rede. Veja o exemplo a seguir.
Figura 1: Exemplo de rede Anycast
Quatro servidores DNS (círculos azuis), localizados em sites diferentes em uma

rede, anunciam cada um o mesmo endereço IP Anycast para seu dispositivo de
roteamento local (não mostrado).
As rotas são compartilhadas entre dispositivos na rede (setas pretas).
Um dispositivo cliente DNS (círculo verde) envia uma consulta DNS para o
endereço IP anycast.
A solicitação DNS do cliente é recebida por um dispositivo de roteamento na rede
(não mostrado).
O dispositivo de roteamento analisa as rotas disponíveis para o endereço IP
anycast e roteia a consulta DNS usando a rota mais curta disponível.
A consulta DNS é enviada para o servidor DNS mais próximo (seta azul).
O DNS anycast é usado normalmente hoje em dia para rotear o tráfego DNS para
muitos serviços DNS globais. Por exemplo, o sistema de servidor DNS raiz depende
muito do DNS do Anycast. O Anycast também funciona com muitos protocolos de
roteamento diferentes e pode ser usado exclusivamente em intranets.
Demonstração do BGP Anycast nativo do
Windows Server
O procedimento a seguir demonstra como o BGP nativo no Windows Server pode ser
usado com o DNS do Anycast.
Requisitos
Um dispositivo físico com a função Hyper-V instalada.
Windows Server 2012 R2, Windows 10 ou posterior.
2 VMs cliente (qualquer sistema operacional).
A instalação de ferramentas BIND para DNS, como dig, é recomendada.
3 VMs de servidor (Windows Server 2016 ou Windows Server 2019).
Se o módulo Windows PowerShell LoopbackAdapter ainda não estiver instalado
em VMs do servidor (DC001, DC002), o acesso à Internet será temporariamente
necessário para instalar este módulo.
Configuração do Hyper-V
Configure seu servidor Hyper-V da seguinte maneira:
2 redes de comutador virtual privadas são configuradas

Uma rede de Internet fictícia 131.253.1.0/24
Uma rede de intranet simulada 10.10.10.0/24
Duas VMs cliente são anexadas à rede 131.253.1.0/24
Duas VMs de servidor são anexadas à rede 10.10.10.0/24
1 o servidor é duplo e anexado às redes 131.253.1.0/24 e 10.10.10.0/24.
Configuração de rede de máquina virtual

Defina as configurações de rede em máquinas virtuais com as seguintes configurações:
1. Client1, client2
Client1: 131.253.1.1
Client2: 131.253.1.2
Máscara de sub-rede: 255.255.255.0
DNS: 51.51.51.51
Gateway: 131.253.1.254
2. Gateway (Windows Server)

NIC1: 131.253.1.254, sub-rede 255.255.255.0
NIC2: 10.10.10.254, sub-rede 255.255.255.0
DNS: 51.51.51.51
Gateway: 131.253.1.100 (pode ser ignorado para a demonstração)
3. DC001 (Windows Server)
NIC1: 10.10.10.1
Sub-rede: 255.255.255.0
DNS: 10.10.10.1
Gateway: 10.10.10.254
4. DC002 (Windows Server)
NIC1: 10.10.10.2
Sub-rede 255.255.255.0
DNS: 10.10.10.2*
Gateway: 10.10.10.254
*Use 10.10.10.1 para DNS inicialmente ao executar a junção de domínio para DC002
para que você possa localizar o domínio do Active Directory no DC001.
Configurar DNS
Use Gerenciador do Servidor e o console de gerenciamento DNS ou Windows
PowerShell para instalar as seguintes funções de servidor e criar uma zona DNS estática
em cada um dos dois servidores.
1. DC001, DC002
Instalar Active Directory Domain Services e promover para o controlador de

domínio (opcional)
Instalar a função DNS (obrigatório)
Criar uma zona estática (não integrada ao AD) chamada zone.tst em DC001 e
DC002
Adicionar o servidor de nome de registro estático único na zona do tipo "TXT"
Dados (texto) para o registro TXT em DC001 = DC001
Dados (texto) para o registro TXT em DC002 = DC002
Configurar adaptadores de loopback

Insira os comandos a seguir em um prompt de Windows PowerShell com privilégios
elevados em DC001 e DC002 para configurar adaptadores de loopback.
７ Observação
O comando Install-Module requer acesso à Internet. Isso pode ser feito atribuindo
temporariamente a VM a uma rede externa no Hyper-V.
PowerShell
$primary_interface = (Get-NetAdapter |?{$_.Status -eq "Up" -and

!$_.Virtual}).Name
$loopback_ipv4 = '51.51.51.51'
$loopback_ipv4_length = '32'
$loopback_name = 'Loopback'
Install-Module -Name LoopbackAdapter -MinimumVersion 1.2.0.0 -Force
Import-Module -Name LoopbackAdapter
New-LoopbackAdapter -Name $loopback_name -Force
$interface_loopback = Get-NetAdapter -Name $loopback_name
$interface_main = Get-NetAdapter -Name $primary_interface
Set-NetIPInterface -InterfaceIndex $interface_loopback.ifIndex -

InterfaceMetric "254" -WeakHostReceive Enabled -WeakHostSend Enabled -DHCP
Disabled
Set-NetIPInterface -InterfaceIndex $interface_main.ifIndex -WeakHostReceive

Enabled -WeakHostSend Enabled
Set-NetIPAddress -InterfaceIndex $interface_loopback.ifIndex -SkipAsSource

$True
Get-NetAdapter $loopback_name | Set-DNSClient –

RegisterThisConnectionsAddress $False
New-NetIPAddress -InterfaceAlias $loopback_name -IPAddress $loopback_ipv4 -

PrefixLength $loopback_ipv4_length -AddressFamily ipv4
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_msclient
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_pacer
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_server
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_lltdio
Disable-NetAdapterBinding -Name $loopback_name -ComponentID ms_rspndr
Configuração de roteamento de máquina virtual

Use os seguintes comandos Windows PowerShell em VMs para configurar o
roteamento.
1. Gateway
PowerShell
Install-WindowsFeature RemoteAccess -IncludeManagementTools
Install-RemoteAccess -VpnType RoutingOnly
Add-BgpRouter -BgpIdentifier “10.10.10.254” -LocalASN 8075
Add-BgpPeer -Name "DC001" -LocalIPAddress 10.10.10.254 -PeerIPAddress

10.10.10.1 -PeerASN 65511 –LocalASN 8075
Add-BgpPeer -Name "DC002" -LocalIPAddress 10.10.10.254 -PeerIPAddress

2. DC001
PowerShell
Add-BgpRouter -BgpIdentifier “10.10.10.1” -LocalASN 65511
Add-BgpPeer -Name "Labgw" -LocalIPAddress 10.10.10.1 -PeerIPAddress

Add-BgpCustomRoute -Network 51.51.51.0/24
3. DC002
PowerShell
Add-BgpRouter -BgpIdentifier "10.10.10.2" -LocalASN 65511
Add-BgpPeer -Name "Labgw" -LocalIPAddress 10.10.10.2 -PeerIPAddress

Add-BgpCustomRoute -Network 51.51.51.0/24
Diagrama de resumo
Figura 2: Configuração do laboratório para demonstração nativa de DNS do BGP
Anycast
Demonstração de DNS do Anycast

1. Verificar o roteamento bgp no servidor de gateway
PS C:\> Get-BgpRouteInformation
DestinationNetwork NextHop LearnedFromPeer State LocalPref MED
------------------ ------- --------------- ----- --------- ---
51.51.51.0/24 10.10.10.1 DC001 Best
51.51.51.0/24 10.10.10.2 DC002 Best
2. Em client1 e client2, verifique se você pode acessar 51.51.51.51
PS C:\> ping 51.51.51.51

Pingando 51.51.51.51 com 32 bytes de dados:
Resposta de 51.51.51.51: bytes=32 time<1ms TTL=126
Estatísticas de ping para 51.51.51.51:
Pacotes: Enviado = 4, Recebido = 4, Perdido = 0 (perda de 0%).
Tempos aproximados de ida e volta em milissegundos:
Mínimo = 0ms, Máximo = 0ms, Média = 0ms
７ Observação
Se o ping falhar, verifique também se não há regras de firewall bloqueando o

ICMP.
3. Em client1 e client2, use nslookup ou dig para consultar o registro TXT. Exemplos
de ambos são mostrados.
PS C:\> dig server.zone.tst TXT +short
PS C:\> nslookup -type=txt server.zone.tst 51.51.51.51
Um cliente exibe "DC001" e o outro cliente exibe "DC002", verificando se o Anycast

está funcionando corretamente. Você também pode consultar no servidor de
gateway.
4. Em seguida, desabilite o adaptador Ethernet no DC001.
PS C:\> (Get-NetAdapter).Name
Loopback
Ethernet 2
PS C:\> Disable-NetAdapter "Ethernet 2"
Confirmar
Tem certeza de que deseja executar essa ação?
Disable-NetAdapter 'Ethernet 2'
[Y] Sim [A] Sim para Todos [N] Não [L] Não a Todos [S] Suspender [?] Ajuda (o
padrão é "Y"):
PS C:\> (Get-NetAdapter).Status
Up
Desabilitado
5. Confirme se os clientes DNS que estavam recebendo respostas anteriormente de
DC001 mudaram para DC002.
Servidor: Sem conhecimento
Endereço: 51.51.51.51
texto server.zone.tst =
"DC001"
Servidor: Sem conhecimento
Endereço: 51.51.51.51
texto server.zone.tst =
"DC002"
6. Confirme se a sessão BGP está inativa no DC001 usando Get-BgpStatistics no

servidor de gateway.
7. Habilite o adaptador Ethernet no DC001 novamente e confirme se a sessão BGP foi

restaurada e os clientes receberão respostas DNS do DC001 novamente.
７ Observação
Se um balanceador de carga não for usado, um cliente individual usará o mesmo

servidor DNS de back-end se estiver disponível. Isso cria um caminho BGP
consistente para o cliente. Para obter mais informações, consulte a seção 4.4.3 de
RFC4786: Caminhos de custo igual .
Perguntas frequentes
P: O DNS do Anycast é uma boa solução para usar em um ambiente DNS local?
R: O DNS anycast funciona perfeitamente com um serviço DNS local. No entanto, o

Anycast não é necessário para que o serviço DNS seja dimensionado.
P: Qual é o impacto da implementação do DNS Anycast em um ambiente com um

grande número (por exemplo, >50) de controladores de domínio?
R: Não há impacto direto na funcionalidade. Se um balanceador de carga for usado,
nenhuma outra configuração em controladores de domínio será necessária.
P: Há suporte para uma configuração de DNS Anycast no atendimento ao cliente da
Microsoft?
R: Se você usar um balanceador de carga que não seja da Microsoft para encaminhar
consultas DNS, a Microsoft oferecerá suporte a problemas relacionados ao serviço
servidor DNS. Consulte o fornecedor do balanceador de carga para obter problemas
relacionados ao encaminhamento de DNS.
P: Qual é a melhor prática para o DNS anycast com um número grande (por exemplo,
>50) de controladores de domínio?
R: A melhor prática é usar um balanceador de carga em cada localização geográfica. Os

balanceadores de carga normalmente são fornecidos por um fornecedor externo.
P: O DNS do Anycast e o DNS do Azure têm funcionalidade semelhante?
R: O DNS do Azure usa Anycast. Para usar o Anycast com o DNS do Azure, configure o
balanceador de carga para encaminhar solicitações para o servidor DNS do Azure.
Visão geral das políticas de DNS
Você pode usar este tópico para saber mais sobre a Política de DNS, que é nova em
Windows Server 2016. Você pode usar a Política de DNS para Geo-Location
gerenciamento de tráfego baseado, respostas DNS inteligentes com base na hora do
dia, para gerenciar um único servidor DNS configurado para implantação de cérebro
dividido, aplicação de filtros em consultas DNS e muito mais. Os itens a seguir fornecem
mais detalhes sobre esses recursos.
Balanceamento de carga do aplicativo. Quando você implantou várias instâncias

de um aplicativo em locais diferentes, pode usar a política DNS para equilibrar a
carga de tráfego entre as diferentes instâncias do aplicativo, alocando
dinamicamente a carga de tráfego para o aplicativo.
gerenciamento de tráfego baseado em Geo-Location. Você pode usar a Política

DNS para permitir que servidores DNS primários e secundários respondam a
consultas de cliente DNS com base na localização geográfica do cliente e no
recurso ao qual o cliente está tentando se conectar, fornecendo ao cliente o
endereço IP do recurso mais próximo.
Dividir O DNS do Cérebro. Com o DNS de cérebro dividido, os registros DNS são
divididos em escopos de zona diferentes no mesmo servidor DNS e os clientes
DNS recebem uma resposta com base em se os clientes são clientes internos ou
externos. Você pode configurar o DNS de cérebro dividido para zonas integradas
do Active Directory ou zonas em servidores DNS autônomos.
Filtragem. Você pode configurar a política DNS para criar filtros de consulta
baseados nos critérios fornecidos. Os filtros de consulta na política DNS permitem
que você configure o servidor DNS para responder de maneira personalizada com
base na consulta DNS e no cliente DNS que envia a consulta DNS.
Análises forenses. Você pode usar a política DNS para redirecionar clientes DNS
mal-intencionados para um endereço IP inexistente em vez de direcioná-los para o
computador que eles estão tentando acessar.
Redirecionamento baseado em hora do dia. Você pode usar a política DNS para
distribuir o tráfego de aplicativos em diferentes instâncias distribuídas
geograficamente de um aplicativo usando políticas DNS baseadas na hora do dia.
Novos conceitos
Para criar políticas para dar suporte aos cenários listados acima, é necessário ser capaz
de identificar grupos de registros em uma zona, grupos de clientes em uma rede, entre
outros elementos. Esses elementos são representados pelos seguintes novos objetos
DNS:
Sub-rede do cliente: um objeto de sub-rede do cliente representa uma sub-rede

IPv4 ou IPv6 da qual as consultas são enviadas para um servidor DNS. Você pode
criar sub-redes para definir políticas a serem aplicadas posteriormente com base
em qual sub-rede as solicitações vêm. Por exemplo, em um cenário de DNS de
cérebro dividido, a solicitação de resolução de um nome como www.microsoft.com
pode ser respondida com um endereço IP interno para clientes de sub-redes
internas e um endereço IP diferente para clientes em sub-redes externas.
Escopo de recursão: escopos de recursão são instâncias exclusivas de um grupo

de configurações que controlam a recursão em um servidor DNS. Um escopo de
recursão contém uma lista de encaminhadores e especifica se a recursão está
habilitada. Um servidor DNS pode ter muitos escopos de recursão. As políticas de
recursão do servidor DNS permitem que você escolha um escopo de recursão para
um conjunto de consultas. Se o servidor DNS não for autoritativo para
determinadas consultas, as políticas de recursão do servidor DNS permitirão que
você controle como resolver essas consultas. Você pode especificar quais
encaminhadores usar e se deve usar a recursão.
Escopos de zona: uma zona DNS pode ter vários escopos de zona, com cada
escopo de zona contendo seu próprio conjunto de registros DNS. O mesmo
registro pode estar presente em vários escopos, com endereços IP diferentes. Além
disso, as transferências de zona são feitas no nível do escopo da zona. Isso
significa que os registros de um escopo de zona em uma zona primária serão
transferidos para o mesmo escopo de zona em uma zona secundária.
Tipos de política
As políticas DNS são divididas por nível e tipo. Você pode usar políticas de resolução de
consulta para definir como as consultas são processadas e as Políticas de Transferência
de Zona para definir como as transferências de zona ocorrem. Você pode aplicar cada
tipo de política no nível do servidor ou na zona.
Políticas de Resolução de Consultas

Você pode usar políticas de resolução de consulta DNS para especificar como as
consultas de resolução de entrada são tratadas por um servidor DNS. Cada Política de
Resolução de Consulta DNS contém os seguintes elementos:
Campo Descrição Valores

possíveis
Nome Nome de política - Até 256

caracteres
- Pode
conter
qualquer
caractere
válido para
um nome de
arquivo
State Estado da política - Habilitar

(padrão)
-
Desabilitado
Level Nível de política - Servidor
- Zona
Ordem de Depois que uma consulta é classificada por nível e se aplica, o - Valor
processamento servidor localiza a primeira política para a qual a consulta numérico
corresponde aos critérios e aplica-a à consulta - Valor

exclusivo por
política que
contém o
mesmo nível
e se aplica
ao valor
Ação Ação a ser executada pelo servidor DNS - Permitir

(padrão para
nível de
zona)
- Negar
(padrão no
nível do
servidor)
- Ignorar
Campo Descrição Valores
possíveis
Critérios Condição de política (AND/OR) e lista de critérios a serem - Operador

atendidos para que a política seja aplicada de condição
(AND/OR)
- Lista de
critérios
(consulte a
tabela de
critérios
abaixo)
Escopo Lista de escopos de zona e valores ponderados por escopo. Os - Lista de

valores ponderados são usados para distribuição de escopos de
balanceamento de carga. Por exemplo, se essa lista incluir zona (por
datacenter1 com um peso de 3 e datacenter2 com um peso de nome) e
5, o servidor responderá com um registro do datacentre1 três pesos
vezes em cada oito solicitações
７ Observação
As políticas de nível de servidor só podem ter os valores Negar ou Ignorar como

uma ação.
O campo critérios de política DNS é composto por dois elementos:
Nome Descrição Valores de exemplo
Sub-rede Nome de uma sub-rede de cliente - EQ, Espanha, França - resolve como true se a
do cliente predefinida. Usado para verificar a sub-rede for identificada como Espanha ou
sub-rede da qual a consulta foi França
enviada. - NE, Canadá, México - resolve como true se a

sub-rede do cliente é qualquer sub-rede
diferente do Canadá e do México
Protocolo Protocolo de transporte usado na - EQ, TCP
de consulta. As entradas possíveis - EQ, UDP

Transporte são UDP e TCP
Protocolo Protocolo de rede usado na - EQ,IPv4
IP consulta. As entradas possíveis - EQ,IPv6

são IPv4 e IPv6
Nome Descrição Valores de exemplo
Endereço Endereço IP para a interface de - EQ,10.0.0.1
IP da rede do servidor DNS de entrada - EQ,192.168.1.1

Interface
do
Servidor
FQDN FQDN de registro na consulta, - EQ, www.contoso.com - resolve como true

com a possibilidade de usar um somente se a consulta estiver tentando
curinga resolver o www.contoso.com FQDN
- EQ,*.contoso.com,*.woodgrove.com –
resolve como true se a consulta for para
qualquer registro que termine em
contoso.comOUwoodgrove.com
Tipo de Tipo de registro que está sendo - EQ, TXT, SRV – resolve como true se a
consulta consultado (A, SRV, TXT) consulta estiver solicitando um registro TXT
OU SRV
- EQ,MX – resolve como true se a consulta está

solicitando um registro MX
Hora do Hora do dia em que a consulta é - EQ,10:00-12:00,22:00-23:00 - resolve como

Dia recebida true se a consulta é recebida entre 10:00 e
meio-dia, OR entre 22:00 e 23:00
Usando a tabela acima como ponto de partida, a tabela a seguir pode ser usada para
definir um critério usado para corresponder a consultas para qualquer tipo de registros,
mas registros SRV no domínio contoso.com provenientes de um cliente na sub-rede
10.0.0.0/24 via TCP entre 20h e 22h por meio da interface 10.0.0.3:
Nome Valor
Sub-rede do cliente EQ,10.0.0.0/24
Protocolo de Transporte EQ,TCP
Endereço IP da interface do servidor EQ,10.0.0.3
FQDN EQ,*.contoso.com
Tipo de consulta NE, SRV
Hora do dia EQ,20:00-22:00
Você pode criar várias políticas de resolução de consulta do mesmo nível, desde que
elas tenham um valor diferente para a ordem de processamento. Quando várias
políticas estão disponíveis, o servidor DNS processa consultas de entrada da seguinte
maneira:
Políticas de recursão
As políticas de recursão são um tipo especial de políticas de nível de servidor. As
políticas de recursão controlam como o servidor DNS executa a recursão para uma
consulta. As políticas de recursão se aplicam somente quando o processamento de
consulta atinge o caminho de recursão. Você pode escolher um valor de DENY ou
IGNORE para recursão para um conjunto de consultas. Como alternativa, você pode
escolher um conjunto de encaminhadores para um conjunto de consultas.
Você pode usar políticas de recursão para implementar uma configuração de DNS split-
brain. Nessa configuração, o servidor DNS executa a recursão de um conjunto de
clientes para uma consulta, enquanto o servidor DNS não executa a recursão para
outros clientes para essa consulta.
As políticas de recursão contêm os mesmos elementos que uma política de resolução

de consulta DNS regular contém, juntamente com os elementos na tabela abaixo:
Nome Descrição
Aplicar na recursão Especifica que essa política só deve ser usada para recursão.
Escopo de Recursão Nome do escopo de recursão.
７ Observação
As políticas de recursão só podem ser criadas no nível do servidor.
Políticas de transferência de zona

As políticas de transferência de zona controlam se uma transferência de zona é
permitida ou não pelo servidor DNS. Você pode criar políticas para transferência de
zona no nível do servidor ou zona. As políticas de nível de servidor se aplicam a cada
consulta de transferência de zona que ocorre no servidor DNS. As políticas de nível de
zona se aplicam somente às consultas em uma zona hospedada no servidor DNS. O uso
mais comum para políticas de nível de zona é implementar listas bloqueadas ou
seguras.
７ Observação
As políticas de transferência de zona só podem usar DENY ou IGNORE como ações.
Você pode usar a política de transferência de zona no nível do servidor abaixo para
negar uma transferência de zona para o domínio contoso.com de uma determinada
sub-rede:
Add-DnsServerZoneTransferPolicy -Name DenyTransferOfContosoToFabrikam -Zone

contoso.com -Action DENY -ClientSubnet "EQ,192.168.1.0/24"
Você pode criar várias políticas de transferência de zona do mesmo nível, desde que
elas tenham um valor diferente para a ordem de processamento. Quando várias
políticas estão disponíveis, o servidor DNS processa consultas de entrada da seguinte
maneira:
Gerenciamento de políticas DNS
Você pode criar e gerenciar políticas de DNS usando o PowerShell. Os exemplos a seguir
passam por diferentes cenários de exemplo que você pode configurar por meio de
Políticas DNS:
Gerenciamento de tráfego
Você pode direcionar o tráfego com base em um FQDN para servidores diferentes,
dependendo da localização do cliente DNS. O exemplo a seguir mostra como criar
políticas de gerenciamento de tráfego para direcionar os clientes de uma determinada
sub-rede para um datacenter norte-americano e de outra sub-rede para um datacenter
europeu.
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
As duas primeiras linhas do script criam objetos de sub-rede do cliente para América do
Norte e Europa. As duas linhas depois disso criam um escopo de zona dentro do
domínio contoso.com, uma para cada região. As duas linhas depois disso criam um
registro em cada zona que associa www.contoso.com a um endereço IP diferente,
uma para a Europa, outra para América do Norte. Por fim, as últimas linhas do script
criam duas Políticas de Resolução de Consulta DNS, uma a ser aplicada à sub-rede
América do Norte, outra à sub-rede da Europa.
Bloquear consultas para um domínio

Você pode usar uma Política de Resolução de Consultas DNS para bloquear consultas
em um domínio. O exemplo a seguir bloqueia todas as consultas para treyresearch.net:
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -

FQDN "EQ,*.treyresearch.com"
Bloquear consultas de uma sub-rede

Você também pode bloquear consultas provenientes de uma sub-rede específica. O
script a seguir cria uma sub-rede para 172.0.33.0/24 e cria uma política para ignorar
todas as consultas provenientes dessa sub-rede:
Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet

172.0.33.0/24
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicyMalicious06" -

Action IGNORE -ClientSubnet "EQ,MaliciousSubnet06"
Permitir a recursão para clientes internos

Você pode controlar a recursão usando uma Política de Resolução de Consulta DNS. O
exemplo a seguir pode ser usado para habilitar a recursão para clientes internos,
desabilitando-a para clientes externos em um cenário de divisão cerebral.
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"
A primeira linha no script altera o escopo de recursão padrão, simplesmente nomeado

como "". (ponto) para desabilitar a recursão. A segunda linha cria um escopo de
recursão chamado InternalClients com recursão habilitada. E a terceira linha cria uma
política para aplicar o escopo de recursão recém-criado a todas as consultas que
chegam por meio de uma interface de servidor que tenha 10.0.0.34 como um endereço
IP.
Criar uma política de transferência de zona no nível do

servidor
Você pode controlar a transferência de zona em uma forma mais granular usando
políticas de Transferência de Zona DNS. O script de exemplo abaixo pode ser usado
para permitir transferências de zona para qualquer servidor em uma determinada sub-
rede:
Add-DnsServerClientSubnet -Name "AllowedSubnet" -IPv4Subnet 172.21.33.0/24
Add-DnsServerZoneTransferPolicy -Name "NorthAmericaPolicy" -Action IGNORE -

ClientSubnet "ne,AllowedSubnet"
A primeira linha no script cria um objeto de sub-rede chamado AllowedSubnet com o

bloco IP 172.21.33.0/24. A segunda linha cria uma política de transferência de zona para
permitir transferências de zona para qualquer servidor DNS na sub-rede criada
anteriormente.
Criar uma política de transferência de zona no nível da

zona
Você também pode criar políticas de transferência de zona no nível da zona. O exemplo
a seguir ignora qualquer solicitação de transferência de zona para contoso.com
proveniente de uma interface do servidor que tenha um endereço IP de 10.0.0.33:
Add-DnsServerZoneTransferPolicy -Name "InternalTransfers" -Action IGNORE -
ServerInterfaceIP "eq,10.0.0.33" -PassThru -ZoneName "contoso.com"
Cenários de política DNS

Para obter informações sobre como usar a política DNS para cenários específicos,
consulte os tópicos a seguir neste guia.
Usar política de DNS para gerenciamento de tráfego baseado em localização

geográfica com servidores primários
geográfica com implantações primárias e secundárias
Usar a política de DNS para respostas de DNS inteligente com base na hora do dia
Respostas DNS com base na hora do dia com um Servidor de Aplicativos na
Nuvem do Azure
Usar a política DNS para Split-Brain implantação de DNS
Usar política DNS para Split-Brain DNS no Active Directory
Usar política DNS para aplicar filtros em consultas DNS
Usar a Política de DNS para balanceamento de carga de aplicativo
Usar a Política de DNS para balanceamento de aplicativo com reconhecimento de
localização geográfica
Usando a política DNS em controladores de

domínio Read-Only
A política DNS é compatível com controladores de domínio Read-Only. Observe que
uma reinicialização do serviço servidor DNS é necessária para que novas políticas DNS
sejam carregadas em Read-Only controladores de domínio. Isso não é necessário em
controladores de domínio graváveis.
Início Rápido: Instalando e
configurando o servidor DNS
Este início rápido mostra como instalar e configurar um servidor DNS no Windows
Server. Você instalará a função servidor DNS para encaminhar consultas DNS para
servidores de nome de dica raiz DNS ou, opcionalmente, para um servidor de nomes
upstream.
Pré-requisitos
Antes de instalar e configurar o servidor DNS, seu computador deve atender aos
seguintes pré-requisitos:
Um computador que executa uma versão de suporte do Windows Server.

Um IP estático.
Uma conta que é membro do grupo Administradores ou equivalente.
Instalando o servidor DNS

A instalação de um servidor DNS (Sistema de Nomes de Domínio) envolve a adição da
função de servidor DNS a um servidor existente do Windows Server.
 Dica
Quando você instala o Active Directory Domain Services (AD DS) com o Assistente
de Instalação do Active Directory Domain Services, o assistente oferece a opção de
instalar e configurar automaticamente um servidor DNS. A zona DNS resultante é
integrada ao namespace de domínio do AD DS. Para saber mais, confira Noções
básicas sobre a integração Active Directory Domain Services.
Para instalar a função de Servidor DNS como um servidor autônomo, execute as

seguintes etapas:
PowerShell
Veja como instalar a função de Servidor DNS usando o comando Install-
WindowsFeature .
1. Execute o PowerShell em seu computador em uma sessão com privilégios

elevados.
2. Para instalar a função DNS, execute o comando a seguir. A instalação não

requer uma reinicialização.
PowerShell
Install-WindowsFeature -Name DNS
Configurando o servidor DNS

Agora que você instalou a função servidor DNS, você pode configurar o servidor.
Configurar interfaces
Por padrão, um servidor DNS escutará solicitações em todas as interfaces de endereço
IP. Você pode configurar o servidor DNS para escutar em uma interface especificada
usando a GUI ou usando o PowerShell.
PowerShell
Veja como configurar a interface usada para escutar solicitações DNS usando o
comando Set-DNSServerSetting .

elevados.
2. Localize o endereço IP existente dos computadores executando o cmdlet Get-

NetIPAddress . Anote o endereço IP que você deseja usar para o servidor DNS.
PowerShell
Get-NetIPAddress | fl IPAddress,InterfaceAlias
3. Armazene a configuração atual do servidor DNS em uma variável temporária,

defina a propriedade ListeningIpAddress e aplique as novas configurações
executando os comandos a seguir. Substitua o espaço reservado
<ip_address> pelo IP que você anotou anteriormente.
PowerShell
$DnsServerSettings = Get-DnsServerSetting -ALL
$DnsServerSettings.ListeningIpAddress = @("<ip_address>")
Set-DNSServerSetting $DnsServerSettings
Configurar dicas raiz

Os servidores de dicas raiz são usados para ajudar a resolver informações de endereço
DNS quando o servidor DNS não consegue resolver a consulta localmente de uma zona
hospedada ou do cache do servidor DNS. Os servidores de nome de dicas raiz são
preenchidos por padrão em novas instalações.
Você pode editar a lista de servidores de nome raiz, se necessário, navegando até a guia
Dicas Raiz da caixa de diálogo propriedades do servidor DNS ou usando o PowerShell.
Não há suporte para a remoção de todos os servidores de dicas raiz. Em vez disso,
configure o servidor DNS para não usar o servidor de nomes de dica raiz selecionando a
opção Desabilitar servidor de recursão na guia Avançado do console do Gerenciador
DNS. Desabilitar a recursão também desabilita todos os encaminhadores configurados.
Como alternativa, desmarque Usar dicas raiz se nenhum encaminhador estiver
disponível na guia Encaminhadores .
PowerShell
Veja como atualizar um servidor de nomes de dica raiz DNS usando o comando
Set-DnsServerRootHint .

elevados.
2. Localize o endereço IP existente dos computadores executando o cmdlet Get-

DnsServerRootHint . Anote o servidor de nomes que você deseja atualizar.
PowerShell
Get-DnsServerRootHint
3. Armazene a configuração atual do servidor DNS em uma variável executando

os comandos a seguir. Substitua o espaço reservado <root_hint_name_server>
pelo servidor de nome da dica raiz que você anotou anteriormente.
PowerShell
$RootHintServer = (Get-DnsServerRootHint | Where-Object

{$_.NameServer.RecordData.NameServer -match "
<root_hint_name_server>"} )
4. Defina a propriedade Ipv4address na variável temporária executando os

comandos a seguir.
Substitua o espaço reservado <ip_address> pelo endereço
IP atualizado.
PowerShell
$RootHintServer.IPAddress[0].RecordData.Ipv4address = "
<ip_address>"
5. Aplique o registro atualizado executando os comandos a seguir.
PowerShell
Set-DnsServerRootHint $RootHintServer
6. Para verificar as dicas raiz atualizadas, execute o comando a seguir. Você

observará que o servidor de nomes tem um ponto à direita (.).
PowerShell
Get-DnsServerRootHint
Configurar encaminhadores
Opcionalmente, você pode configurar um encaminhador para resolver informações de
endereço DNS em vez de encaminhar o tráfego para os servidores raiz DNS. Você pode
adicionar encaminhadores usando a GUI ou usando o cmdlet do Set-
DNSServerForwarder PowerShell.
７ Observação
As dicas de raiz DNS não serão usadas, a menos que os encaminhadores não
respondam.
PowerShell
Veja como instalar a função de servidor DNS usando o comando Install-

WindowsFeature .

elevados.
2. Para configurar encaminhadores DNS, substitua os espaços reservados

<ip_forwarder_1> e <ip_forwarder_2> pelo endereço IP do servidor DNS a ser
usado como seus encaminhadores. Em seguida, execute os comandos a
seguir.
PowerShell
$Forwarders = "<ip_forwarder_1>","<ip_forwarder_2>"
Set-DnsServerForwarder -IPAddress $Forwarders
Removendo a função de servidor DNS

Para remover a função de Servidor DNS, execute as etapas a seguir.
PowerShell
Veja como desinstalar a função do Servidor DNS usando o comando Desinstalar-

WindowsFeature .
1. Em um prompt do PowerShell com privilégios elevados, execute o seguinte

comando:
PowerShell
Uninstall-WindowsFeature -Name DNS
） Importante
Ao remover o serviço de função de servidor DNS de um computador Windows
Server, esteja ciente:
Para um servidor DNS que hospeda zonas integradas ao AD DS, essas zonas
são salvas ou excluídas de acordo com seu tipo de armazenamento. Os dados
de zona não são excluídos, a menos que o servidor DNS que você desinstale
seja o último servidor DNS que hospeda essa zona.
Para um servidor DNS que hospeda zonas DNS padrão, os arquivos de zona
permanecem no diretório %systemroot%\System32\Dns , mas não são
recarregados se o servidor DNS for reinstalado.
Se você criar uma nova zona
com o mesmo nome de uma zona antiga, o arquivo de zona antiga será
substituído pelo novo arquivo de zona.
Próximas etapas
Agora que você instalou e configurou um servidor DNS, aqui estão alguns artigos que
podem ajudá-lo a fazer mais.
Visão geral das políticas DNS

Visão geral do DNS do Anycast
Cliente DNS seguro via HTTPS (DoH)
A partir do Windows Server 2022, o cliente DNS dá suporte a DNS-over-HTTPS (DoH).

Quando o DoH está habilitado, as consultas DNS entre o cliente DNS do Windows
Server e o servidor DNS passam por uma conexão HTTPS segura, em vez de em texto
sem formatação. Ao passar a consulta DNS em uma conexão criptografada, ela é
protegida contra interceptação por terceiros não confiáveis.
Configurar o cliente DNS para dar suporte ao

DoH
Você só pode configurar o cliente Windows Server para usar o DoH se o servidor DNS
primário ou secundário selecionado para a interface de rede estiver na lista de
servidores DoH conhecidos. Você pode configurar o cliente DNS para exigir DoH,
solicitar DoH ou usar apenas consultas DNS de texto simples tradicionais. Para
configurar o cliente DNS para dar suporte ao DoH no servidor Windows com a
Experiência da Área de Trabalho, siga as seguintes etapas:
1. No painel de controle Windows Configurações, selecione Internet de Rede&.
2. Na página Rede & da Internet, selecione Ethernet.
3. Na tela Ethernet, selecione a interface de rede que você deseja configurar para o
DoH.
4. Na tela Rede, role para baixo até as configurações de DNS e selecione o botão
Editar .
5. Na tela Editar configurações de DNS, selecione Manual na lista suspensa de

configurações de IP automáticas ou manuais. Essa configuração permite que você
configure os servidores DNS preferenciais e DNS alternativos. Se os endereços
desses servidores estiverem presentes na lista de servidores DoH conhecidos, a
lista suspensa de criptografia DNS preferencial será habilitada. Você pode
escolher entre as seguintes configurações para definir a criptografia DNS
preferencial:
Somente criptografado (DNS via HTTPS). Quando essa configuração for

escolhida, todo o tráfego de consulta DNS passará por HTTPS. Essa
configuração fornece a melhor proteção para o tráfego de consulta DNS. No
entanto, isso também significa que a resolução DNS não ocorrerá se o
servidor DNS de destino não puder dar suporte a consultas DoH.
Criptografado preferencial, não criptografado permitido. Quando essa

configuração for escolhida, o cliente DNS tentará usar o DoH e, em seguida,
retornará para consultas DNS não criptografadas se isso não for possível.
Essa configuração fornece a melhor compatibilidade para servidores DNS
compatíveis com DoH, mas você não receberá nenhuma notificação se as
consultas DNS forem alternadas de DoH para texto sem formatação.
Somente descriptografado. Todo o tráfego de consulta DNS para o servidor
DNS especificado não foi criptografado. Essa configuração configura o cliente
DNS para usar consultas DNS de texto simples tradicionais.
6. Selecione Salvar para aplicar as configurações de DoH ao cliente DNS.
Se você estiver configurando o endereço do servidor DNS para um cliente usando o

PowerShell usando o Set-DNSClientServerAddress cmdlet, a configuração do DoH
dependerá se a configuração de fallback do servidor estiver na lista de servidores DoH
conhecidos. No momento, você não pode definir configurações de DoH para o cliente
DNS no Windows Server 2022 usando Windows Admin Center ou sconfig.cmd.
Configurando o DoH por meio de Política de Grupo

Windows Configurações de Política de Grupo local e de domínio do Server 2022 incluem
a política de resolução de nomes DoH (Configure DNS over HTTPS). Você pode usá-lo
para configurar o cliente DNS para usar o DoH. Essa política é encontrada no Computer
Configuration\Policies\Administrative Templates\Network\DNS Client nó. Quando
habilitada, essa política pode ser configurada com as seguintes configurações:
Permitir DoH. As consultas serão executadas usando o DoH se os servidores DNS

especificados derem suporte ao protocolo. Se os servidores não derem suporte ao
DoH, consultas não criptografadas serão emitidas.
Proibir DoH. Impedirá o uso do DoH com consultas de cliente DNS.
Exigir DoH. Exigirá que as consultas sejam executadas usando o DoH. Se os

servidores DNS configurados não derem suporte ao DoH, a resolução de nomes
falhará.
Não habilite a opção Exigir DoH para computadores ingressados no domínio, pois
Active Directory Domain Services depende muito do DNS porque o serviço servidor
DNS do servidor Windows não dá suporte a consultas DoH. Se você precisar que o
tráfego de consulta DNS na rede Active Directory Domain Services seja criptografado,
considere implementar regras de segurança de conexão baseadas em IPsec para
proteger esse tráfego. Consulte Como proteger conexões IPsec de ponta a ponta
usando iKEv2 para obter mais informações.
Determinar quais servidores DoH estão na lista

de servidores conhecidos
Windows Server é fornecido com uma lista de servidores que são conhecidos por dar
suporte ao DoH.
Você pode determinar quais servidores DNS estão nessa lista usando o
cmdlet do Get-DNSClientDohServerAddress PowerShell.
A lista padrão de servidores DoH conhecidos é a seguinte:
Proprietário do servidor Endereços IP do servidor DNS
Cloudflare 1.1.1.1
1.0.0.1
2606:4700:4700::1111
2606:4700:4700::1001
Google 8.8.8.8
8.8.4.4
2001:4860:4860::8888
2001:4860:4860::8844
Quad 9 9.9.9.9
149.112.112.112
2620:fe::fe
2620:fe::fe:9
Adicionar um novo servidor DoH à lista de
servidores conhecidos
Você pode adicionar novos servidores DoH à lista de servidores conhecidos usando o
cmdlet do Add-DnsClientDohServerAddress PowerShell. Especifique a URL do modelo
DoH e se você permitirá que o cliente volte para uma consulta não criptografada caso a
consulta segura falhe. A sintaxe desse comando é:
PowerShell
Add-DnsClientDohServerAddress -ServerAddress '<resolver-IP-address>' -

DohTemplate '<resolver-DoH-template>' -AllowFallbackToUdp $False -
AutoUpgrade $True
Usar a Tabela de Política de Resolução de

Nomes com o DoH
Você pode usar a NRPT (Tabela de Política de Resolução de Nomes) para configurar
consultas para um namespace DNS específico para usar um servidor DNS específico. Se
o servidor DNS for conhecido por dar suporte ao DoH, as consultas relacionadas a esse
domínio serão executadas usando o DoH em vez de de uma maneira não criptografada.
Guia de cenários de política de DNS
Este guia destina-se ao uso pelo DNS, pela rede e pelos administradores de sistemas.
A Política dns é um novo recurso para DNS no Windows Server® 2016. Você pode usar
este guia para aprender a usar a política dns para controlar como um servidor DNS
processa consultas de resolução de nomes com base em diferentes parâmetros que
você define nas políticas.
Este guia contém informações de visão geral da política DNS, bem como cenários de
política DNS específicos que fornecem instruções sobre como configurar o
comportamento do servidor DNS para atingir suas metas, incluindo o gerenciamento de
tráfego baseado em localização geográfica para servidores DNS primários e
secundários, alta disponibilidade de aplicativos, DNS de divisão e muito mais.
Visão geral das políticas dns

geográfica com servidores primários
geográfica com implantações primárias e secundárias
Usar a política de DNS para respostas de DNS inteligente com base na hora do dia
Respostas DNS com base na hora do dia com um Servidor de Aplicativos de
Nuvem do Azure
Usar a política DNS para Split-Brain de DNS
Usar a política DNS para Split-Brain DNS no Active Directory
Usar a política DNS para aplicar filtros em consultas DNS
Usar a Política de DNS para balanceamento de carga de aplicativo
Usar a Política de DNS para balanceamento de aplicativo com reconhecimento de
localização geográfica
Usar política de DNS para
gerenciamento de tráfego baseado em
localização geográfica com servidores
primários
Você pode usar este tópico para aprender a configurar a Política DNS para permitir que
os servidores DNS primários respondam a consultas de cliente DNS com base na
localização geográfica do cliente e no recurso ao qual o cliente está tentando se
conectar, fornecendo ao cliente o endereço IP do recurso mais próximo.
） Importante
Este cenário ilustra como implantar a política DNS para o gerenciamento de tráfego
baseado em localização geográfica quando você está usando apenas servidores
DNS primários. Você também pode realizar o gerenciamento de tráfego baseado
em localização geográfica quando tiver servidores DNS primários e secundários. Se
você tiver uma implantação primária-secundária, primeiro conclua as etapas neste
tópico e conclua as etapas fornecidas no tópico Usar política DNS para
gerenciamento de tráfego baseado em Geo-Location com implantações de
Primary-Secondary.
Com novas políticas DNS, você pode criar uma política DNS que permite que o servidor
DNS responda a uma consulta cliente solicitando o endereço IP de um servidor Web. As
instâncias do servidor Web podem estar localizadas em diferentes datacenters em
diferentes locais físicos. O DNS pode avaliar os locais do cliente e do servidor Web e
responder à solicitação do cliente fornecendo ao cliente um endereço IP do servidor
Web para um servidor Web que esteja fisicamente localizado mais perto do cliente.
Você pode usar os seguintes parâmetros de política DNS para controlar as respostas do
servidor DNS para consultas de clientes DNS.
Sub-rede do cliente. Nome de uma sub-rede de cliente predefinida. Usado para

verificar a sub-rede da qual a consulta foi enviada.
Protocolo de Transporte. Protocolo de transporte usado na consulta. As entradas
possíveis são UDP e TCP.
Protocolo de Internet. Protocolo de rede usado na consulta. As entradas possíveis
são IPv4 e IPv6.
Endereço IP da Interface do Servidor. Endereço IP da interface de rede do
servidor DNS que recebeu a solicitação DNS.
FQDN. O FQDN (Nome de Domínio Totalmente Qualificado) do registro na
consulta, com a possibilidade de usar um curinga.
Tipo de consulta. Tipo de registro que está sendo consultado (A, SRV, TXT etc.).
Hora do dia. Hora do dia em que a consulta é recebida.
Você pode combinar os critérios a seguir com um operador lógico (AND/OR) para
formular expressões de política. Quando essas expressões correspondem, espera-se que
as políticas executem uma das ações a seguir.
Ignorar. O servidor DNS remove silenciosamente a consulta.

Negar. O servidor DNS responde a essa consulta com uma resposta de falha.
Permitir. O servidor DNS responde novamente com a resposta gerenciada pelo
tráfego.
Exemplo de gerenciamento de tráfego baseado

em Geo-Location
Veja a seguir um exemplo de como você pode usar a política DNS para obter o
redirecionamento de tráfego com base no local físico do cliente que executa uma
consulta DNS.
Este exemplo usa duas empresas fictícias - Contoso Serviços de Nuvem, que fornece
soluções de hospedagem na Web e domínio; e woodgrove Food Services, que fornece
serviços de entrega de alimentos em várias cidades em todo o mundo, e que tem um
site chamado woodgrove.com.
A Contoso Serviços de Nuvem tem dois datacenters, um nos EUA e outro na Europa. O
datacenter europeu hospeda um portal de pedidos de comida para woodgrove.com.
Para garantir que woodgrove.com clientes obtenham uma experiência responsiva em

seu site, a Woodgrove quer clientes europeus direcionados para o datacenter europeu e
clientes americanos direcionados para o datacenter dos EUA. Os clientes localizados em
outros lugares do mundo podem ser direcionados para qualquer um dos datacenters.
A ilustração a seguir ilustra esse cenário.

Como funciona o processo de resolução de
nomes DNS
Durante o processo de resolução de nomes, o usuário tenta se conectar ao
www.woodgrove.com . Isso resulta em uma solicitação de resolução de nome DNS que
é enviada para o servidor DNS configurado nas propriedades de Conexão de Rede no
computador do usuário. Normalmente, esse é o servidor DNS fornecido pelo ISP local
atuando como um resolvedor de cache e é chamado de LDNS.
Se o nome DNS não estiver presente no cache local do LDNS, o servidor LDNS
encaminha a consulta para o servidor DNS que é autoritativo para woodgrove.com. O
servidor DNS autoritativo responde com o registro solicitado (www.woodgrove.com )
ao servidor LDNS, que, por sua vez, armazena em cache o registro localmente antes de
enviá-lo para o computador do usuário.
Como a Contoso Serviços de Nuvem usa políticas do Servidor DNS, o servidor DNS
autoritativo que hospeda contoso.com está configurado para retornar respostas
gerenciadas de tráfego baseadas em localização geográfica. Isso resulta na direção dos
clientes europeus para o datacenter europeu e na direção dos clientes americanos para
o datacenter dos EUA, conforme descrito na ilustração.
Nesse cenário, o servidor DNS autoritativo geralmente vê a solicitação de resolução de

nomes proveniente do servidor LDNS e, muito raramente, do computador do usuário.
Por isso, o endereço IP de origem na solicitação de resolução de nomes, como visto
pelo servidor DNS autoritativo, é o do servidor LDNS e não o do computador do
usuário. No entanto, usar o endereço IP do servidor LDNS ao configurar respostas de
consulta baseadas em localização geográfica fornece uma estimativa justa da
localização geográfica do usuário, pois o usuário está consultando o servidor DNS de
seu ISP local.
７ Observação
As políticas DNS utilizam o IP do remetente no pacote UDP/TCP que contém a

consulta DNS. Se a consulta atingir o servidor primário por meio de vários saltos de
resolvedor/LDNS, a política considerará apenas o IP do último resolvedor do qual o
servidor DNS recebe a consulta.
Como configurar a política DNS para respostas

de consulta baseadas em Geo-Location
Para configurar a política DNS para respostas de consulta baseadas em localização
geográfica, você deve executar as etapas a seguir.
1. Criar sub-redes do cliente DNS

2. Criar os escopos da zona
3. Adicionar registros aos escopos de zona
4. Criar as políticas
７ Observação
Você deve executar essas etapas no servidor DNS que é autoritativo para a zona
que deseja configurar. A associação em DnsAdmins, ou equivalente, é necessária
para executar os procedimentos a seguir.
As seções a seguir fornecem instruções de configuração detalhadas.
） Importante
As seções a seguir incluem comandos de Windows PowerShell de exemplo que

contêm valores de exemplo para muitos parâmetros. Substitua os valores de
exemplo nesses comandos por valores apropriados para sua implantação antes de
executar esses comandos.
Criar sub-redes do cliente DNS
A primeira etapa é identificar as sub-redes ou o espaço de endereço IP das regiões para
as quais você deseja redirecionar o tráfego. Por exemplo, se você quiser redirecionar o
tráfego para os EUA e a Europa, precisará identificar as sub-redes ou espaços de
endereço IP dessas regiões.
Você pode obter essas informações de mapas Geo-IP. Com base nessas distribuições de
IP geográfico, você deve criar as "Sub-redes do cliente DNS". Uma sub-rede de cliente
DNS é um agrupamento lógico de sub-redes IPv4 ou IPv6 das quais as consultas são
enviadas para um servidor DNS.
Você pode usar os comandos de Windows PowerShell a seguir para criar sub-redes de
cliente DNS.
PowerShell
Add-DnsServerClientSubnet -Name "USSubnet" -IPv4Subnet "192.0.0.0/24"
Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "141.1.0.0/24"
Para obter mais informações, consulte Add-DnsServerClientSubnet.
Criar escopos de zona

Depois que as sub-redes do cliente forem configuradas, você deverá particionar a zona
cujo tráfego você deseja redirecionar para dois escopos de zona diferentes, um escopo
para cada uma das sub-redes do cliente DNS configuradas.
Por exemplo, se você quiser redirecionar o tráfego para o nome DNS

www.woodgrove.com , deverá criar dois escopos de zona diferentes na zona
woodgrove.com, um para os EUA e outro para a Europa.
Um escopo de zona é uma instância exclusiva da zona. Uma zona DNS pode ter vários
escopos de zona, com cada escopo de zona contendo seu próprio conjunto de registros
DNS. O mesmo registro pode estar presente em vários escopos, com endereços IP
diferentes ou os mesmos endereços IP.
７ Observação
Por padrão, existe um escopo de zona nas zonas DNS. Esse escopo de zona tem o
mesmo nome que a zona e as operações DNS herdadas funcionam nesse escopo.
Você pode usar os comandos Windows PowerShell a seguir para criar escopos de zona.
PowerShell
Add-DnsServerZoneScope -ZoneName "woodgrove.com" -Name "USZoneScope"
Add-DnsServerZoneScope -ZoneName "woodgrove.com" -Name "EuropeZoneScope"
Para obter mais informações, consulte Add-DnsServerZoneScope.
Adicionar registros aos escopos de zona

Agora você deve adicionar os registros que representam o host do servidor Web nos
dois escopos de zona.
Por exemplo, USZoneScope e EuropeZoneScope. No USZoneScope, você pode

adicionar o registro www.woodgrove.com com o endereço IP 192.0.0.1, que está
localizado em um datacenter dos EUA; e no EuropeZoneScope você pode adicionar o
mesmo registro (www.woodgrove.com ) com o endereço IP 141.1.0.1 no datacenter
europeu.
Você pode usar os comandos Windows PowerShell a seguir para adicionar registros aos
escopos da zona.
PowerShell
Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -

IPv4Address "192.0.0.1" -ZoneScope "USZoneScope"

IPv4Address "141.1.0.1" -ZoneScope "EuropeZoneScope"
Neste exemplo, você também deve usar os comandos Windows PowerShell a seguir
para adicionar registros ao escopo da zona padrão para garantir que o resto do mundo
ainda possa acessar o servidor Web woodgrove.com de qualquer um dos dois
datacenters.
PowerShell

IPv4Address "192.0.0.1"
O parâmetro ZoneScope não é incluído quando você adiciona um registro no escopo

padrão. Isso é o mesmo que adicionar registros a uma zona DNS padrão.
Para obter mais informações, consulte Add-DnsServerResourceRecord.

Criar as políticas
Depois de criar as sub-redes, as partições (escopos de zona) e adicionar registros, você
deve criar políticas que conectem as sub-redes e partições para que, quando uma
consulta vem de uma origem em uma das sub-redes do cliente DNS, a resposta da
consulta seja retornada do escopo correto da zona. Nenhuma política é necessária para
mapear o escopo da zona padrão.
Você pode usar os comandos de Windows PowerShell a seguir para criar uma política
DNS que vincule as sub-redes do cliente DNS e os escopos da zona.
PowerShell
Add-DnsServerQueryResolutionPolicy -Name "USPolicy" -Action ALLOW -

ClientSubnet "eq,USSubnet" -ZoneScope "USZoneScope,1" -ZoneName
"woodgrove.com"

ClientSubnet "eq,EuropeSubnet" -ZoneScope "EuropeZoneScope,1" -ZoneName
"woodgrove.com"
Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.
Agora, o servidor DNS está configurado com as políticas de DNS necessárias para
redirecionar o tráfego com base na localização geográfica.
Quando o servidor DNS recebe consultas de resolução de nomes, o servidor DNS avalia
os campos na solicitação DNS em relação às políticas DNS configuradas. Se o endereço
IP de origem na solicitação de resolução de nomes corresponder a qualquer uma das
políticas, o escopo da zona associada será usado para responder à consulta e o usuário
será direcionado para o recurso geograficamente mais próximo a elas.
Você pode criar milhares de políticas DNS de acordo com seus requisitos de
gerenciamento de tráfego e todas as novas políticas são aplicadas dinamicamente - sem
reiniciar o servidor DNS - em consultas de entrada.
Usar política de DNS para
localização geográfica com
implantações primárias e secundárias
Você pode usar este tópico para aprender a criar uma política DNS para gerenciamento
de tráfego baseado em localização geográfica quando sua implantação de DNS inclui
servidores DNS primários e secundários.
O cenário anterior, Usar política DNS para gerenciamento de tráfego baseado em Geo-
Location com servidores primários, forneceu instruções para configurar a política DNS
para gerenciamento de tráfego baseado em localização geográfica em um servidor DNS
primário. Na infraestrutura da Internet, no entanto, os servidores DNS são amplamente
implantados em um modelo primário-secundário, onde a cópia gravável de uma zona é
armazenada em servidores primários selecionados e seguros, e cópias somente leitura
da zona são mantidas em vários servidores secundários.
Os servidores secundários usam os protocolos de transferência de zona AXFR

(Transferência Autoritativa) e Transferência de Zona Incremental (IXFR) para solicitar e
receber atualizações de zona que incluem novas alterações nas zonas nos servidores
DNS primários.
７ Observação
Para obter mais informações sobre a AXFR, consulte a Solicitação IETF (Internet
Engineering Task Force) para Comentários 5936 . Para obter mais informações
sobre o IXFR, consulte a Solicitação IETF (Internet Engineering Task Force) para
Comentários 1995 .
Exemplo de gerenciamento de tráfego baseado

em Primary-Secondary Geo-Location
Veja a seguir um exemplo de como você pode usar a política DNS em uma implantação
primária-secundária para obter o redirecionamento de tráfego com base no local físico
do cliente que executa uma consulta DNS.
Este exemplo usa duas empresas fictícias - Contoso Serviços de Nuvem, que fornece
soluções de hospedagem na Web e domínio; e woodgrove Food Services, que fornece
serviços de entrega de alimentos em várias cidades em todo o mundo, e que tem um
site chamado woodgrove.com.
Para garantir que woodgrove.com clientes obtenham uma experiência responsiva em

seu site, a Woodgrove quer clientes europeus direcionados para o datacenter europeu e
clientes americanos direcionados para o datacenter dos EUA. Os clientes localizados em
outros lugares do mundo podem ser direcionados para qualquer um dos datacenters.
A Contoso Serviços de Nuvem tem dois datacenters, um nos EUA e outro na Europa,
sobre os quais a Contoso hospeda seu portal de pedidos de comida para
woodgrove.com.
A implantação do DNS da Contoso inclui dois servidores secundários:

SecondaryServer1, com o endereço IP 10.0.0.2; e SecondaryServer2, com o endereço IP
10.0.0.3. Esses servidores secundários estão atuando como servidores de nome nas duas
regiões diferentes, com SecondaryServer1 localizado na Europa e SecondaryServer2
localizados nos EUA.
Há uma cópia de zona gravável primária no PrimaryServer (endereço IP 10.0.0.1), em

que as alterações de zona são feitas. Com transferências de zona regulares para os
servidores secundários, os servidores secundários estão sempre atualizados com
quaisquer novas alterações na zona no PrimaryServer.

Como funciona o sistema de Primary-
Secondary DNS
Quando você implanta o gerenciamento de tráfego baseado em localização geográfica
em uma implantação de DNS primário-secundário, é importante entender como as
transferências normais de zona primária-secundária ocorrem antes de saber mais sobre
transferências de nível de escopo de zona. As seções a seguir fornecem informações
sobre transferências de nível de zona e de escopo de zona.
Transferências de zona em uma implantação primária-secundária do DNS

Transferências de nível de escopo de zona em uma implantação primária-
secundária do DNS
Transferências de zona em uma implantação primária-

secundária do DNS
Você pode criar uma implantação primária-secundária DNS e sincronizar zonas com as
etapas a seguir.
1. Quando você instala o DNS, a zona primária é criada no servidor DNS primário.
2. No servidor secundário, crie as zonas e especifique os servidores primários.
3. Nos servidores primários, você pode adicionar os servidores secundários como
secundários confiáveis na zona primária.
4. As zonas secundárias fazem uma solicitação de transferência de zona completa
(AXFR) e recebem a cópia da zona.
5. Quando necessário, os servidores primários enviam notificações para os servidores
secundários sobre atualizações de zona.
6. Os servidores secundários fazem uma solicitação de transferência de zona
incremental (IXFR). Por isso, os servidores secundários permanecem sincronizados
com o servidor primário.
Transferências de nível de escopo de zona em uma

implantação primária-secundária do DNS
O cenário de gerenciamento de tráfego requer etapas adicionais para particionar as
zonas em diferentes escopos de zona. Por isso, etapas adicionais são necessárias para
transferir os dados dentro dos escopos de zona para os servidores secundários e
transferir políticas e sub-redes de cliente DNS para os servidores secundários.
Depois de configurar sua infraestrutura DNS com servidores primários e secundários, as

transferências de nível de escopo de zona são executadas automaticamente pelo DNS,
usando os processos a seguir.
Para garantir a transferência de nível de escopo de zona, os servidores DNS usam o

EDNS0 (Mecanismos de Extensão para DNS0). Todas as solicitações de transferência de
zona (AXFR ou IXFR) das zonas com escopos se originam com um EDNS0 OPT RR, cuja
ID de opção é definida como "65433" por padrão. Para obter mais informações sobre o
EDNSO, consulte a Solicitação IETF para Comentários 6891 .
O valor do OPT RR é o nome do escopo da zona para o qual a solicitação está sendo
enviada. Quando um servidor DNS primário recebe esse pacote de um servidor
secundário confiável, ele interpreta a solicitação como chegando para esse escopo de
zona.
Se o servidor primário tiver esse escopo de zona, ele responderá com os dados de
transferência (XFR) desse escopo. A resposta contém um OPT RR com a mesma ID de
opção "65433" e valor definido como o mesmo escopo de zona. Os servidores
secundários recebem essa resposta, recuperam as informações de escopo da resposta e
atualizam esse escopo específico da zona.
Após esse processo, o servidor primário mantém uma lista de secundários confiáveis
que enviaram uma solicitação de escopo de zona para notificações.
Para qualquer atualização adicional em um escopo de zona, uma notificação IXFR é

enviada para os servidores secundários, com o mesmo OPT RR. O escopo da zona que
recebe essa notificação faz com que a solicitação IXFR contenha esse OPT RR e o
mesmo processo descrito acima a seguir.
Como configurar a política DNS para

Primary-Secondary Geo-Location
Antes de começar, verifique se você concluiu todas as etapas no tópico Usar a Política
DNS para Geo-Location Gerenciamento de Tráfego Baseado com Servidores Primários e
se o servidor DNS primário está configurado com zonas, escopos de zona, sub-redes de
cliente DNS e política DNS.
７ Observação
As instruções neste tópico para copiar sub-redes de cliente DNS, escopos de zona
e políticas DNS de servidores primários DNS para servidores secundários DNS são
para sua configuração e validação DNS iniciais. No futuro, talvez você queira alterar
as sub-redes do cliente DNS, os escopos de zona e as configurações de políticas no
servidor primário. Nessa circunstância, você pode criar scripts de automação para
manter os servidores secundários sincronizados com o servidor primário.
Para configurar a política DNS para respostas de consulta baseadas em localização

geográfica primária secundária, execute as etapas a seguir.
Criar zonas secundárias

Configurar o Configurações de Transferência de Zona na Zona Primária
Copiar as sub-redes do cliente DNS
Criar os escopos de zona no servidor secundário
Configurar a política DNS
） Importante

A associação em DnsAdmins, ou equivalente, é necessária para executar os
procedimentos a seguir.
Criar zonas secundárias

Você pode criar a cópia secundária da zona que deseja replicar para SecondaryServer1 e
SecondaryServer2 (supondo que os cmdlets estejam sendo executados remotamente de
um único cliente de gerenciamento).
Por exemplo, você pode criar a cópia secundária de www.woodgrove.com em

SecondaryServer1 e SecondarySesrver2.
Você pode usar os comandos Windows PowerShell a seguir para criar as zonas
secundárias.
PowerShell
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
Para obter mais informações, consulte Add-DnsServerSecondaryZone.
Configurar o Configurações de Transferência de Zona na

Zona Primária
Você deve definir as configurações de zona primária para que:
1. As transferências de zona do servidor primário para os servidores secundários

especificados são permitidas.
2. As notificações de atualização de zona são enviadas pelo servidor primário para os
servidores secundários.
Você pode usar os comandos Windows PowerShell a seguir para definir as

configurações de transferência de zona na zona primária.
７ Observação
No comando de exemplo a seguir, o parâmetro -Notify especifica que o servidor

primário enviará notificações sobre atualizações para a lista de secundárias
selecionada.
PowerShell
Set-DnsServerPrimaryZone -Name "woodgrove.com" -Notify Notify -

SecondaryServers "10.0.0.2,10.0.0.3" -SecureSecondaries
TransferToSecureServers -ComputerName PrimaryServer
Para obter mais informações, consulte Set-DnsServerPrimaryZone.
Copiar as sub-redes do cliente DNS

Você deve copiar as sub-redes do cliente DNS do servidor primário para os servidores
secundários.
Você pode usar os comandos Windows PowerShell a seguir para copiar as sub-redes
para os servidores secundários.
PowerShell
Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-

DnsServerClientSubnet -ComputerName SecondaryServer1
Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-

DnsServerClientSubnet -ComputerName SecondaryServer2
Criar os escopos de zona no servidor secundário

Você deve criar os escopos de zona nos servidores secundários. No DNS, os escopos de
zona também começam a solicitar XFRs do servidor primário. Com qualquer alteração
nos escopos de zona no servidor primário, uma notificação que contém as informações
de escopo da zona é enviada aos servidores secundários. Os servidores secundários
podem atualizar seus escopos de zona com alterações incrementais.
Você pode usar os comandos Windows PowerShell a seguir para criar os escopos de
zona nos servidores secundários.
PowerShell
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
７ Observação
Nesses comandos de exemplo, o parâmetro -ErrorAction Ignore está incluído, pois

existe um escopo de zona padrão em cada zona. O escopo da zona padrão não
pode ser criado ou excluído. O pipelining resultará em uma tentativa de criar esse
escopo e falhará. Como alternativa, você pode criar os escopos de zona não padrão
em duas zonas secundárias.
Configurar a política DNS

Você pode usar os comandos Windows PowerShell a seguir para criar uma política DNS
que vincule as sub-redes do cliente DNS e os escopos de zona.
PowerShell
$policy = Get-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -

ComputerName PrimaryServer
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -

ComputerName SecondaryServer1
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -

ComputerName SecondaryServer2
Agora, os servidores DNS secundários são configurados com as políticas DNS

necessárias para redirecionar o tráfego com base na localização geográfica.
IP de origem na solicitação de resolução de nome corresponder a qualquer uma das
políticas, o escopo de zona associado será usado para responder à consulta e o usuário
será direcionado para o recurso geograficamente mais próximo a eles.
Usar a política de DNS para respostas de
DNS inteligente com base na hora do
dia
Você pode usar este tópico para aprender a distribuir o tráfego de aplicativos entre
diferentes instâncias distribuídas geograficamente de um aplicativo usando políticas
DNS baseadas na hora do dia.
Esse cenário é útil em situações em que você deseja direcionar o tráfego em um fuso
horário para servidores de aplicativos alternativos, como servidores Web, que estão
localizados em outro fuso horário. Isso permite que você balancee o tráfego em
instâncias de aplicativo durante períodos de horário de pico quando os servidores
primários estão sobrecarregados com o tráfego.
Exemplo de respostas DNS inteligentes com base na hora

do dia
Veja a seguir um exemplo de como você pode usar a política DNS para equilibrar o
tráfego do aplicativo com base na hora do dia.
Este exemplo usa uma empresa fictícia, a Contoso Gift Services, que fornece soluções de
presenteação online em todo o mundo por meio de seu site, contosogiftservices.com.
O site contosogiftservices.com é hospedado em dois datacenters, um em Seattle

(América do Norte) e outro em Dublin (Europa). Os servidores DNS são configurados
para enviar respostas com reconhecimento de localização geográfica usando a política
DNS. Com um aumento recente nos negócios, contosogiftservices.com tem um número
maior de visitantes todos os dias, e alguns dos clientes relataram problemas de
disponibilidade do serviço.
A Contoso Gift Services executa uma análise de site e descobre que todas as noites
entre 18h e 21h locais, há um aumento no tráfego para os servidores Web. Os
servidores Web não podem ser dimensionados para lidar com o aumento do tráfego
nesses horários de pico, resultando em negação de serviço aos clientes. A mesma
sobrecarga de tráfego de horário de pico ocorre nos datacenters europeus e
americanos. Em outras horas do dia, os servidores lidam com volumes de tráfego bem
abaixo de sua capacidade máxima.
Para garantir que contosogiftservices.com clientes obtenham uma experiência

responsiva do site, a Contoso Gift Services deseja redirecionar algum tráfego de Dublin
para os servidores de aplicativos de Seattle entre 18h e 21h em Dublin; e eles querem
redirecionar um pouco de tráfego de Seattle para os servidores de aplicativos de Dublin
entre 18h e 21h em Seattle.
Como as respostas DNS inteligentes com base na hora do

dia funcionam
Quando o servidor DNS é configurado com a política DNS de hora do dia, entre 18h e
21h em cada local geográfico, o servidor DNS faz o seguinte.
Responde às quatro primeiras consultas recebidas com o endereço IP do servidor

Web no datacenter local.
Responde à quinta consulta recebida com o endereço IP do servidor Web no
datacenter remoto.
Esse comportamento baseado em política descarrega 20% da carga de tráfego do
servidor Web local para o servidor Web remoto, aliviando a pressão sobre o servidor de
aplicativos local e melhorando o desempenho do site para os clientes.
Durante o horário de pico, os servidores DNS executam o gerenciamento de tráfego

baseado em localizações geográficas normais. Além disso, os clientes DNS que enviam
consultas de locais diferentes de América do Norte ou Europa, a carga do servidor DNS
equilibra o tráfego entre os datacenters de Seattle e Dublin.
Quando várias políticas DNS são configuradas no DNS, elas são um conjunto ordenado
de regras e são processadas pelo DNS da prioridade mais alta para a menor prioridade.
O DNS usa a primeira política que corresponde às circunstâncias, incluindo a hora do
dia. Por esse motivo, políticas mais específicas devem ter maior prioridade. Se você criar
políticas de hora do dia e lhes der alta prioridade na lista de políticas, o DNS processará
e usará essas políticas primeiro se corresponderem aos parâmetros da consulta de
cliente DNS e aos critérios definidos na política. Se eles não corresponderem, o DNS
moverá para baixo a lista de políticas para processar as políticas padrão até encontrar
uma correspondência.
Para obter mais informações sobre tipos de política e critérios, consulte Visão geral das
políticas de DNS.
Como configurar a política DNS para respostas DNS

inteligentes com base na hora do dia
Para configurar a política DNS para respostas de consulta baseadas em balanceamento
de carga de aplicativo de hora do dia, você deve executar as etapas a seguir.

Criar as políticas DNS
７ Observação

） Importante


A primeira etapa é identificar as sub-redes ou o espaço de endereço IP das regiões para
as quais você deseja redirecionar o tráfego. Por exemplo, se você quiser redirecionar o
tráfego para os EUA e a Europa, precisará identificar as sub-redes ou espaços de
endereço IP dessas regiões.
Você pode obter essas informações de mapas Geo-IP. Com base nessas distribuições de
IP geográfico, você deve criar as "Sub-redes do cliente DNS". Uma sub-rede de cliente
DNS é um agrupamento lógico de sub-redes IPv4 ou IPv6 das quais as consultas são
enviadas para um servidor DNS.
Você pode usar os comandos de Windows PowerShell a seguir para criar sub-redes de
cliente DNS.
PowerShell
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"

Depois que as sub-redes do cliente forem configuradas, você deverá particionar a zona
cujo tráfego você deseja redirecionar para dois escopos de zona diferentes, um escopo
para cada uma das sub-redes do cliente DNS configuradas.
Por exemplo, se você quiser redirecionar o tráfego para o nome DNS

www.contosogiftservices.com , deverá criar dois escopos de zona diferentes na zona
contosogiftservices.com, um para os EUA e outro para a Europa.
７ Observação
PowerShell
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name

"SeattleZoneScope"

"DublinZoneScope"
Agora você deve adicionar os registros que representam o host do servidor Web nos
dois escopos de zona.
Por exemplo, no SeattleZoneScope, o registro www.contosogiftservices.com é

adicionado com o endereço IP 192.0.0.1, que está localizado em um datacenter de
Seattle. Da mesma forma, em DublinZoneScope, o registro
www.contosogiftservices.com é adicionado com o endereço IP 141.1.0.3 no datacenter
de Dublin
escopos da zona.
PowerShell
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name

"www" -IPv4Address "192.0.0.1" -ZoneScope "SeattleZoneScope"

"www" -IPv4Address "141.1.0.3" -ZoneScope "DublinZoneScope"
O parâmetro ZoneScope não é incluído quando você adiciona um registro no escopo

padrão. Isso é o mesmo que adicionar registros a uma zona DNS padrão.

Depois de configurar essas políticas DNS, o comportamento do servidor DNS é o

seguinte:
1. Os clientes DNS europeus recebem o endereço IP do servidor Web no datacenter

de Dublin em sua resposta de consulta DNS.
2. Os clientes DNS americanos recebem o endereço IP do servidor Web no
datacenter de Seattle em sua resposta de consulta DNS.
3. Entre 18h e 21h em Dublin, 20% das consultas de clientes europeus recebem o
endereço IP do servidor Web no datacenter de Seattle em sua resposta de
consulta DNS.
4. Entre 18h e 21h em Seattle, 20% das consultas dos clientes americanos recebem o
endereço IP do servidor Web no datacenter de Dublin em sua resposta de consulta
DNS.
5. Metade das consultas do resto do mundo recebe o endereço IP do datacenter de
Seattle e a outra metade recebe o endereço IP do datacenter de Dublin.
Você pode usar os comandos de Windows PowerShell a seguir para criar uma política
DNS que vincule as sub-redes do cliente DNS e os escopos da zona.
７ Observação
Neste exemplo, o servidor DNS está no fuso horário GMT, portanto, os períodos de
hora de pico devem ser expressos no horário GMT equivalente.
PowerShell
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
Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -

ClientSubnet "eq,AmericaSubnet" -ZoneScope "SeattleZoneScope,1" -ZoneName

ClientSubnet "eq,EuropeSubnet" -ZoneScope "DublinZoneScope,1" -ZoneName
Add-DnsServerQueryResolutionPolicy -Name "RestOfWorldPolicy" -Action ALLOW -

ZoneScope "DublinZoneScope,1;SeattleZoneScope,1" -ZoneName
redirecionar o tráfego com base na localização geográfica e na hora do dia.
IP de origem na solicitação de resolução de nomes corresponder a qualquer uma das
políticas, o escopo da zona associada será usado para responder à consulta e o usuário
será direcionado para o recurso geograficamente mais próximo a elas.
Respostas de DNS com base na hora do
dia com o Servidor de aplicativos da
nuvem do Azure
Você pode usar este tópico para aprender a distribuir o tráfego de aplicativos entre
diferentes instâncias distribuídas geograficamente de um aplicativo usando políticas
DNS baseadas na hora do dia.
Esse cenário é útil em situações em que você deseja direcionar o tráfego em um fuso
horário para servidores de aplicativos alternativos, como servidores Web hospedados no
Microsoft Azure, que estão localizados em outro fuso horário. Isso permite que você
balancee o tráfego em instâncias de aplicativo durante períodos de horário de pico
quando os servidores primários estão sobrecarregados com o tráfego.
７ Observação
Para saber como usar a política DNS para respostas DNS inteligentes sem usar o
Azure, consulte Usar a política DNS para respostas DNS inteligentes com base na
hora do dia.
Exemplo de respostas DNS inteligentes com

base na hora do dia com o Servidor de
Aplicativos na Nuvem do Azure
Veja a seguir um exemplo de como você pode usar a política DNS para equilibrar o
tráfego do aplicativo com base na hora do dia.
Este exemplo usa uma empresa fictícia, a Contoso Gift Services, que fornece soluções de
presenteação online em todo o mundo por meio de seu site, contosogiftservices.com.
O site contosogiftservices.com é hospedado apenas em um único datacenter local em

Seattle (com IP público 192.68.30.2).
O servidor DNS também está localizado no datacenter local.

Com um aumento recente nos negócios, contosogiftservices.com tem um número maior
de visitantes todos os dias, e alguns dos clientes relataram problemas de
disponibilidade do serviço.
Os Serviços de Presentes da Contoso realizam uma análise de site e descobrem que

todas as noites entre 18h e 21h locais, há um aumento no tráfego para o servidor Web
de Seattle. O servidor Web não pode ser dimensionado para lidar com o aumento do
tráfego nesses horários de pico, resultando em negação de serviço aos clientes.
Para garantir que contosogiftservices.com clientes obtenham uma experiência

responsiva do site, os Serviços de Presentes da Contoso decidem que durante essas
horas ele alugará uma VM (máquina virtual) no Microsoft Azure para hospedar uma
cópia de seu servidor Web.
A Contoso Gift Services obtém um endereço IP público do Azure para a VM

(192.68.31.44) e desenvolve a automação para implantar o Servidor Web todos os dias
no Azure entre 17h e 22h, permitindo um período de contingência de uma hora.
７ Observação
Para obter mais informações sobre VMs do Azure, consulte Máquinas Virtuais
documentação
Os servidores DNS são configurados com escopos de zona e políticas DNS para que,
entre 17h e 21h todos os dias, 30% das consultas sejam enviadas para a instância do
servidor Web em execução no Azure.

Como funcionam as respostas DNS inteligentes
com base na hora do dia com o servidor Azure
App
Este artigo demonstra como configurar o servidor DNS para responder a consultas DNS
com dois endereços IP diferentes do servidor de aplicativos – um servidor Web está em
Seattle e o outro está em um datacenter do Azure.
Após a configuração de uma nova política DNS baseada nos horários de pico das 18h às
21h em Seattle, o servidor DNS envia setenta por cento das respostas DNS para clientes
que contêm o endereço IP do servidor Web de Seattle e 30% das respostas DNS aos
clientes que contêm o endereço IP do servidor Web do Azure, Direcionando assim o
tráfego do cliente para o novo servidor Web do Azure e impedindo que o servidor Web
de Seattle fique sobrecarregado.
Em todas as outras horas do dia, o processamento de consulta normal ocorre e as

respostas são enviadas do escopo de zona padrão que contém um registro para o
servidor Web no datacenter local.
O TTL de 10 minutos no registro do Azure garante que o registro tenha expirado do

cache LDNS antes que a VM seja removida do Azure. Um dos benefícios desse
dimensionamento é que você pode manter seus dados DNS locais e continuar
expandindo para o Azure conforme a demanda exige.
Como configurar a política DNS para respostas

DNS inteligentes com base na hora do dia com
o servidor Azure App
Para configurar a política DNS para respostas de consulta baseadas em balanceamento
de carga de aplicativo de hora do dia, você deve executar as etapas a seguir.

７ Observação
） Importante


７ Observação
Você pode usar o comando de exemplo a seguir para criar um escopo de zona para
hospedar os registros do Azure.

"AzureZoneScope"
Para obter mais informações, consulte Add-DnsServerZoneScope

A próxima etapa é adicionar os registros que representam o host do servidor Web nos
escopos da zona.
No AzureZoneScope, o registro www.contosogiftservices.com é adicionado com o

endereço IP 192.68.31.44, que está localizado na nuvem pública do Azure.
Da mesma forma, no escopo de zona padrão (contosogiftservices.com), um registro

(www.contosogiftservices.com) é adicionado com o endereço IP 192.68.30.2 do servidor
Web em execução no datacenter local de Seattle.
No segundo cmdlet abaixo, o parâmetro –ZoneScope não está incluído. Por isso, os
registros são adicionados no ZoneScope padrão.
Além disso, a TTL do registro para VMs do Azure é mantida em 600s (10 minutos) para
que o LDNS não o armazene em cache por mais tempo - o que interferiria no
balanceamento de carga. Além disso, as VMs do Azure estão disponíveis por 1 hora
extra como uma contingência para garantir que até mesmo clientes com registros
armazenados em cache sejam capazes de resolver.

"www" -IPv4Address "192.68.31.44" -ZoneScope "AzureZoneScope" –TimeToLive
600

"www" -IPv4Address "192.68.30.2"

Depois que os escopos de zona forem criados, você poderá criar políticas DNS que
distribuam as consultas de entrada entre esses escopos para que o seguinte ocorra.
1. Das 18h às 21h diariamente, 30% dos clientes recebem o endereço IP do servidor
Web no datacenter do Azure na resposta DNS, enquanto 70% dos clientes
recebem o endereço IP do servidor Web local de Seattle.
2. Em todos os outros momentos, todos os clientes recebem o endereço IP do
servidor Web local de Seattle.
A hora do dia deve ser expressa na hora local do servidor DNS.
Você pode usar o comando de exemplo a seguir para criar a política DNS.
Add-DnsServerQueryResolutionPolicy -Name "Contoso6To9Policy" -Action ALLOW -

ZoneScope "contosogiftservices.com,7;AzureZoneScope,3" –TimeOfDay “EQ,18:00-
21:00” -ZoneName "contosogiftservices.com" –ProcessingOrder 1
redirecionar o tráfego para o servidor Web do Azure com base na hora do dia.
Observe a expressão:
-ZoneScope "contosogiftservices.com,7;AzureZoneScope,3" –TimeOfDay “EQ,18:00-

21:00”
Essa expressão configura o servidor DNS com um ZoneScope e uma combinação de

peso que instrui o servidor DNS a enviar o endereço IP do servidor Web de Seattle
setenta por cento do tempo, ao enviar o endereço IP do servidor Web do Azure 30% do
tempo.
Usar a política de DNS para DNS com
partição de rede no Active Directory
Você pode usar este tópico para aproveitar os recursos de gerenciamento de tráfego de
políticas DNS para implantações de cérebro dividido com zonas DNS integradas do
Active Directory em Windows Server 2016.
Em Windows Server 2016, o suporte a políticas DNS é estendido para zonas DNS
integradas do Active Directory. A integração do Active Directory fornece recursos de alta
disponibilidade de vários mestres para o servidor DNS.
Anteriormente, esse cenário exigia que os administradores DNS mantivessem dois

servidores DNS diferentes, cada um fornecendo serviços para cada conjunto de
usuários, internos e externos. Se apenas alguns registros dentro da zona foram divididos
ou ambas as instâncias da zona (interna e externa) foram delegadas para o mesmo
domínio pai, isso se tornou um enigma de gerenciamento.
７ Observação
As implantações de DNS são divididas quando há duas versões de uma única

zona, uma versão para usuários internos na intranet da organização e uma
versão para usuários externos – que normalmente são usuários na Internet.
O tópico Use DNS Policy for Split-Brain DNS Deployment explica como você
pode usar políticas DNS e escopos de zona para implantar um sistema DNS
de cérebro dividido em um único servidor DNS Windows Server 2016.
Exemplo Split-Brain DNS no Active Directory

Este exemplo usa uma empresa fictícia, a Contoso, que mantém um site de carreira em
www.career.contoso.com .
O site tem duas versões, uma para os usuários internos em que as postagens de
trabalho internas estão disponíveis. Este site interno está disponível no endereço IP local
10.0.0.39.
A segunda versão é a versão pública do mesmo site, que está disponível no endereço IP
público 65.55.39.10.
Na ausência de política DNS, o administrador é obrigado a hospedar essas duas zonas

em servidores DNS do servidor Windows separados e gerenciá-las separadamente.
Usando políticas DNS, essas zonas agora podem ser hospedadas no mesmo servidor
DNS.
Se o servidor DNS para contoso.com estiver integrado ao Active Directory e estiver

escutando em duas interfaces de rede, o Administrador de DNS da Contoso poderá
seguir as etapas neste tópico para obter uma implantação de cérebro dividido.
O Administrador DNS configura as interfaces do servidor DNS com os seguintes

endereços IP.
O adaptador de rede voltado para a Internet é configurado com um endereço IP

público de 208.84.0.53 para consultas externas.
O adaptador de rede voltado para Intranet é configurado com um endereço IP
privado de 10.0.0.56 para consultas internas.
Como funciona a política de DNS para Split-

Brain DNS no Active Directory
Quando o servidor DNS é configurado com as políticas de DNS necessárias, cada
solicitação de resolução de nome é avaliada em relação às políticas no servidor DNS.
A Interface do servidor é usada neste exemplo como os critérios para diferenciar entre
os clientes internos e externos.
Se a interface do servidor na qual a consulta é recebida corresponder a qualquer uma

das políticas, o escopo da zona associada será usado para responder à consulta.
Portanto, em nosso exemplo, as consultas DNS para www.career.contoso.com

recebidas no IP privado (10.0.0.56) recebem uma resposta DNS que contém um
endereço IP interno; e as consultas DNS recebidas na interface de rede pública recebem
uma resposta DNS que contém o endereço IP público no escopo da zona padrão (isso é
o mesmo que a resolução de consulta normal).
Há suporte para atualizações dns dinâmicas (DDNS) e a limpeza só tem suporte no

escopo da zona padrão. Como os clientes internos são atendidos pelo escopo de zona
padrão, os Administradores DNS da Contoso podem continuar usando os mecanismos
existentes (DNS dinâmico ou estático) para atualizar os registros em contoso.com. Para
escopos de zona não padrão (como o escopo externo neste exemplo), o suporte a
DDNS ou de limpeza não está disponível.
Alta disponibilidade de políticas

As políticas DNS não são integradas ao Active Directory. Por isso, as políticas DNS não
são replicadas para os outros servidores DNS que hospedam a mesma zona integrada
do Active Directory.
As políticas DNS são armazenadas no servidor DNS local. Você pode exportar facilmente
políticas DNS de um servidor para outro usando o exemplo a seguir Windows
PowerShell comandos.
PowerShell
$policies = Get-DnsServerQueryResolutionPolicy -ZoneName "contoso.com" -

ComputerName Server01
$policies | Add-DnsServerQueryResolutionPolicy -ZoneName "contoso.com" -

ComputerName Server02
Para obter mais informações, consulte os tópicos de referência Windows PowerShell a

seguir.
Get-DnsServerQueryResolutionPolicy
Add-DnsServerQueryResolutionPolicy
Como configurar a política DNS para Split-
Brain DNS no Active Directory
Para configurar a Implantação de Split-Brain DNS usando a Política DNS, você deve usar
as seções a seguir, que fornecem instruções de configuração detalhadas.
Adicionar a zona integrada do Active Directory

Você pode usar o comando de exemplo a seguir para adicionar a zona de contoso.com
integrada do Active Directory ao servidor DNS.
PowerShell
Add-DnsServerPrimaryZone -Name "contoso.com" -ReplicationScope "Domain" -

PassThru
Para obter mais informações, consulte Add-DnsServerPrimaryZone.
Criar os escopos da zona

Você pode usar esta seção para particionar a zona contoso.com para criar um escopo de
zona externa.
Como você está adicionando esse novo escopo de zona em uma zona integrada do
Active Directory, o escopo da zona e os registros dentro dele serão replicados por meio
do Active Directory para outros servidores de réplica no domínio.
Por padrão, existe um escopo de zona em cada zona DNS. Esse escopo de zona tem o
mesmo nome que a zona e as operações DNS herdadas funcionam nesse escopo. Esse
escopo de zona padrão hospedará a versão interna do www.career.contoso.com .
Você pode usar o comando de exemplo a seguir para criar o escopo da zona no servidor
DNS.
PowerShell
Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "external"

dois escopos de zona: externo e padrão (para clientes internos).
No escopo da zona interna padrão, o registro www.career.contoso.com é adicionado

com o endereço IP 10.0.0.39, que é um endereço IP privado; e no escopo da zona
externa, o mesmo registro (www.career.contoso.com) é adicionado com o endereço IP
público 65.55.39.10.
Os registros (no escopo da zona interna padrão e no escopo da zona externa) serão
replicados automaticamente no domínio com seus respectivos escopos de zona.
Você pode usar o comando de exemplo a seguir para adicionar registros aos escopos de
zona no servidor DNS.
PowerShell
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -

IPv4Address "65.55.39.10" -ZoneScope "external"

IPv4Address "10.0.0.39”
７ Observação
O parâmetro –ZoneScope não é incluído quando o registro é adicionado ao

escopo da zona padrão. Essa ação é a mesma que adicionar registros a uma zona
normal.

Depois de identificar as interfaces do servidor para a rede externa e a rede interna e
criar os escopos de zona, você deve criar políticas DNS que conectem os escopos de
zona interna e externa.
７ Observação
Este exemplo usa a interface do servidor (o parâmetro -ServerInterface no
comando de exemplo abaixo) como os critérios para diferenciar entre os clientes
internos e externos. Outro método para diferenciar entre clientes externos e
internos é usando sub-redes de cliente como critério. Se você puder identificar as
sub-redes às quais os clientes internos pertencem, você poderá configurar a
política DNS para diferenciar com base na sub-rede do cliente. Para obter
informações sobre como configurar o gerenciamento de tráfego usando critérios
de sub-rede do cliente, consulte Usar a Política DNS para Geo-Location
Gerenciamento de Tráfego Baseado com Servidores Primários.
Depois de configurar políticas, quando uma consulta DNS é recebida na interface

pública, a resposta é retornada do escopo externo da zona.
７ Observação
Nenhuma política é necessária para mapear o escopo da zona interna padrão.
PowerShell
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action

ALLOW -ServerInterface "eq,208.84.0.53" -ZoneScope "external,1" -ZoneName
contoso.com
７ Observação
208.84.0.53 é o endereço IP na interface de rede pública.
Agora, o servidor DNS está configurado com as políticas de DNS necessárias para um
servidor de nome de cérebro dividido com uma zona DNS integrada do Active
Directory.
Usar a política de DNS para a
implantação de DNS com partição de
rede
Você pode usar este tópico para aprender a configurar a política DNS no Windows
Server® 2016 para implantações de DNS de cérebro dividido, em que há duas versões
de uma única zona : uma para os usuários internos na intranet da sua organização e
outra para os usuários externos, que normalmente são usuários na Internet.
７ Observação
Para obter informações sobre como usar a Política DNS para implantação de DNS
de cérebro dividido com zonas DNS integradas do Active Directory, consulte Usar a
política DNS para Split-Brain DNS no Active Directory.
Anteriormente, esse cenário exigia que os administradores DNS mantivessem dois

servidores DNS diferentes, cada um fornecendo serviços para cada conjunto de
usuários, internos e externos. Se apenas alguns registros dentro da zona foram divididos
ou ambas as instâncias da zona (interna e externa) foram delegadas para o mesmo
domínio pai, isso se tornou um enigma de gerenciamento.
Outro cenário de configuração para implantação de cérebro dividido é o Controle de

Recursão Seletiva para resolução de nomes DNS. Em algumas circunstâncias, espera-se
que os servidores DNS Enterprise executem resolução recursiva pela Internet para os
usuários internos, enquanto eles também devem atuar como servidores de nomes
autoritativos para usuários externos e bloquear a recursão para eles.
Exemplo de implantação de Split-Brain DNS

Exemplo de controle de recursão seletiva DNS
Exemplo de implantação de Split-Brain DNS

Veja a seguir um exemplo de como você pode usar a política DNS para realizar o
cenário descrito anteriormente de DNS de cérebro dividido.
Esta seção contém os seguintes tópicos.
Como funciona a implantação de Split-Brain DNS

Como configurar a implantação de Split-Brain DNS
Este exemplo usa uma empresa fictícia, a Contoso, que mantém um site de carreira em
O site tem duas versões, uma para os usuários internos em que as postagens de
trabalho internas estão disponíveis. Este site interno está disponível no endereço IP local
10.0.0.39.
A segunda versão é a versão pública do mesmo site, que está disponível no endereço IP
público 65.55.39.10.
Na ausência de política DNS, o administrador é obrigado a hospedar essas duas zonas

em servidores DNS do servidor Windows separados e gerenciá-las separadamente.
Usando políticas DNS, essas zonas agora podem ser hospedadas no mesmo servidor
DNS.

Como funciona a implantação de Split-Brain
DNS
Quando o servidor DNS é configurado com as políticas de DNS necessárias, cada
solicitação de resolução de nome é avaliada em relação às políticas no servidor DNS.
A Interface do servidor é usada neste exemplo como os critérios para diferenciar entre
os clientes internos e externos.
Se a interface do servidor na qual a consulta é recebida corresponder a qualquer uma

das políticas, o escopo da zona associada será usado para responder à consulta.
Portanto, em nosso exemplo, as consultas DNS para www.career.contoso.com

recebidas no IP privado (10.0.0.56) recebem uma resposta DNS que contém um
endereço IP interno; e as consultas DNS recebidas na interface de rede pública recebem
uma resposta DNS que contém o endereço IP público no escopo da zona padrão (isso é
o mesmo que a resolução de consulta normal).
Como configurar a implantação de Split-Brain

DNS
Para configurar a Implantação de Split-Brain DNS usando a Política DNS, você deve usar
as etapas a seguir.

） Importante


７ Observação
Esse escopo de zona padrão hospedará a versão externa do
Você pode usar o comando de exemplo a seguir para particionar o escopo da zona
contoso.com para criar um escopo de zona interno. O escopo da zona interna será
usado para manter a versão interna do www.career.contoso.com .
Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal"

dois escopos de zona – interno e padrão (para clientes externos).
No escopo da zona interna, o registro www.career.contoso.com é adicionado com o

endereço IP 10.0.0.39, que é um IP privado; e no escopo de zona padrão o mesmo
registro, www.career.contoso.com, é adicionado com o endereço IP 65.55.39.10.
Nenhum parâmetro –ZoneScope é fornecido nos comandos de exemplo a seguir

quando o registro está sendo adicionado ao escopo da zona padrão. Isso é semelhante
à adição de registros a uma zona de baunilha.
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -
Name "www.career" -IPv4Address "10.0.0.39” -ZoneScope "internal"

Depois de identificar as interfaces do servidor para a rede externa e a rede interna e
criar os escopos de zona, você deve criar políticas DNS que conectem os escopos de
zona interna e externa.
７ Observação
Este exemplo usa a interface do servidor como os critérios para diferenciar entre os
clientes internos e externos. Outro método para diferenciar entre clientes externos
e internos é usando sub-redes de cliente como critério. Se você puder identificar as
sub-redes às quais os clientes internos pertencem, você poderá configurar a
política DNS para diferenciar com base na sub-rede do cliente. Para obter
informações sobre como configurar o gerenciamento de tráfego usando critérios
de sub-rede do cliente, consulte Usar a Política DNS para Geo-Location
Gerenciamento de Tráfego Baseado com Servidores Primários.
Quando o servidor DNS recebe uma consulta na interface privada, a resposta da

consulta DNS é retornada do escopo da zona interna.
７ Observação
Nenhuma política é necessária para mapear o escopo da zona padrão.
No comando de exemplo a seguir, 10.0.0.56 é o endereço IP na interface de rede

privada, conforme mostrado na ilustração anterior.
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -

ServerInterface "eq,10.0.0.56" -ZoneScope "internal,1" -ZoneName contoso.com
Exemplo de controle de recursão seletiva DNS

Veja a seguir um exemplo de como você pode usar a política DNS para realizar o
cenário descrito anteriormente do controle de recursão seletivo DNS.
Como funciona o controle de recursão seletiva do DNS

Como configurar o controle de recursão seletiva DNS
Este exemplo usa a mesma empresa fictícia que no exemplo anterior, Contoso, que
mantém um site de carreira em www.career.contoso.com .
No exemplo de implantação de cérebro dividido DNS, o mesmo servidor DNS responde

aos clientes externos e internos e fornece respostas diferentes.
Algumas implantações de DNS podem exigir que o mesmo servidor DNS execute a
resolução de nomes recursivos para clientes internos, além de atuar como o servidor de
nome autoritativo para clientes externos. Essa circunstância é chamada de controle de
recursão seletiva DNS.
Nas versões anteriores do Windows Server, habilitar a recursão significava que ele
estava habilitado em todo o servidor DNS para todas as zonas. Como o servidor DNS
também está escutando consultas externas, a recursão está habilitada para clientes
internos e externos, tornando o servidor DNS um resolvedor aberto.
Um servidor DNS configurado como um resolvedor aberto pode ser vulnerável ao

esgotamento de recursos e pode ser abusado por clientes mal-intencionados para criar
ataques de reflexão.
Por isso, os administradores de DNS da Contoso não querem que o servidor DNS para
contoso.com execute a resolução de nomes recursivos para clientes externos. Há apenas
a necessidade de controle de recursão para clientes internos, enquanto o controle de
recursão pode ser bloqueado para clientes externos.
Como funciona o controle de recursão seletiva do DNS

Se uma consulta para a qual o servidor DNS da Contoso não é autoritativo for recebida,
por https://www.microsoft.com exemplo, a solicitação de resolução de nome será
avaliada em relação às políticas no servidor DNS.
Como essas consultas não se enquadram em nenhuma zona, as políticas de nível de

zona (conforme definido no exemplo de cérebro dividido) não são avaliadas.
O servidor DNS avalia as políticas de recursão e as consultas recebidas na interface

privada correspondem ao SplitBrainRecursionPolicy. Essa política aponta para um
escopo de recursão em que a recursão está habilitada.
Em seguida, o servidor DNS executa a recursão para https://www.microsoft.com obter

a resposta da Internet e armazena em cache a resposta localmente.
Se a consulta for recebida na interface externa, nenhuma política DNS corresponderá e

a configuração de recursão padrão - que, nesse caso, está desabilitada - será aplicada.
Isso impede que o servidor atue como um resolvedor aberto para clientes externos,
enquanto ele está atuando como um resolvedor de cache para clientes internos.
Como configurar o controle de recursão seletiva DNS

Para configurar o controle de recursão seletivo DNS usando a Política DNS, você deve
usar as etapas a seguir.
Criar escopos de recursão DNS

Criar políticas de recursão DNS
Criar escopos de recursão DNS

Os escopos de recursão são instâncias exclusivas de um grupo de configurações que
controlam a recursão em um servidor DNS. Um escopo de recursão contém uma lista de
encaminhadores e especifica se a recursão está habilitada. Um servidor DNS pode ter
muitos escopos de recursão.
A configuração de recursão herdada e a lista de encaminhadores são chamados de

escopo de recursão padrão. Não é possível adicionar ou remover o escopo de recursão
padrão, identificado pelo ponto de nome (".").
Neste exemplo, a configuração de recursão padrão é desabilitada, enquanto um novo

escopo de recursão para clientes internos é criado quando a recursão está habilitada.
PowerShell
Set-DnsServerRecursionScope -Name . -EnableRecursion $False
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
Para obter mais informações, consulte Add-DnsServerRecursionScope
Criar políticas de recursão DNS

Você pode criar políticas de recursão de servidor DNS para escolher um escopo de
recursão para um conjunto de consultas que correspondem a critérios específicos.
Se o servidor DNS não for autoritativo para algumas consultas, as políticas de recursão
do servidor DNS permitirão que você controle como resolver as consultas.
Neste exemplo, o escopo de recursão interna com a recursão habilitada está associado à
interface de rede privada.
Você pode usar o comando de exemplo a seguir para configurar políticas de recursão
DNS.
PowerShell
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy" -Action

ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP
"EQ,10.0.0.39"
Agora, o servidor DNS está configurado com as políticas de DNS necessárias para um
servidor de nome de cérebro dividido ou um servidor DNS com controle de recursão
seletivo habilitado para clientes internos.
Para obter mais informações, consulte o Guia de Cenário de Política DNS.

Usar a Política de DNS para a aplicação
de filtros em consultas DNS
Você pode usar este tópico para saber como configurar a política DNS no Windows
Server® 2016 para criar filtros de consulta com base nos critérios que você fornecer.
Os filtros de consulta na política DNS permitem que você configure o servidor DNS para
responder de maneira personalizada com base na consulta DNS e no cliente DNS que
envia a consulta DNS.
Por exemplo, você pode configurar a política DNS com a Lista de Blocos do filtro de
consulta que bloqueia consultas DNS de domínios mal-intencionados conhecidos, o que
impede que o DNS responde a consultas desses domínios. Como nenhuma resposta é
enviada do servidor DNS, a consulta DNS do membro do domínio mal-intencionado
chega ao tempo.
Outro exemplo é criar um filtro de consulta Lista de Permitir que permita que apenas
um conjunto específico de clientes resolva determinados nomes.
Critérios de filtro de consulta

Você pode criar filtros de consulta com qualquer combinação lógica (AND/OR/NOT) dos
critérios a seguir.
Nome Descrição
Sub-rede do cliente Nome de uma sub-rede de cliente predefinida. Usado para verificar a
sub-rede da qual a consulta foi enviada.
Protocolo de Protocolo de transporte usado na consulta. Os valores possíveis são

Transporte UDP e TCP.
Protocolo IP Protocolo de rede usado na consulta. Os valores possíveis são IPv4 e

IPv6.
Endereço IP da Endereço IP do interface de rede do servidor DNS que recebeu a

interface do servidor solicitação DNS.
FQDN Nome de domínio totalmente qualificado do registro na consulta, com a

possibilidade de usar um curinga.
Nome Descrição
Tipo de consulta Tipo de registro que está sendo consultado (A, SRV, TXT etc.).
Hora do dia Hora do dia em que a consulta é recebida.
Os exemplos a seguir mostram como criar filtros para a política DNS que bloqueiam ou
permitem consultas de resolução de nomes DNS.
７ Observação
Os comandos de exemplo neste tópico usam o comando Windows PowerShell

Add-DnsServerQueryResolutionPolicy. Para obter mais informações, consulte
Add-DnsServerQueryResolutionPolicy.
Bloquear consultas de um domínio

Em algumas circunstâncias, talvez você queira bloquear a resolução de nomes DNS para
domínios que você identificou como mal-intencionados ou para domínios que não
estão em conformidade com as diretrizes de uso da sua organização. Você pode realizar
consultas de bloqueio para domínios usando a política dns.
A política configurada neste exemplo não é criada em nenhuma zona específica– em vez
disso, você cria uma Política de Nível de Servidor que é aplicada a todas as zonas
configuradas no servidor DNS. As Políticas de Nível de Servidor são as primeiras a serem
avaliadas e, portanto, primeiro a serem corresponder quando uma consulta é recebida
pelo servidor DNS.
O comando de exemplo a seguir configura uma Política de Nível de Servidor para

bloquear todas as consultas com o sufixo de domínio contosomalicious.com.
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicy" -Action IGNORE -FQDN
"EQ,*.contosomalicious.com" -PassThru
７ Observação
Quando você configura o parâmetro Action com o valor IGNORE, o servidor DNS é
configurado para soltar consultas sem resposta. Isso faz com que o cliente DNS no
domínio mal-intencionado es time-out.
Bloquear consultas de uma sub-rede
Com este exemplo, você poderá bloquear consultas de uma sub-rede se for
considerado infectado por algum malware e estiver tentando entrar em contato com
sites mal-intencionados usando seu servidor DNS.
' Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet 172.0.33.0/24 -

PassThru
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyMalicious06" -Action

IGNORE -ClientSubnet "EQ,MaliciousSubnet06" -PassThru '
O exemplo a seguir demonstra como você pode usar os critérios de sub-rede em

combinação com os critérios de FQDN para bloquear consultas para determinados
domínios mal-intencionados de sub-redes infectados.
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyMalicious06" -Action
IGNORE -ClientSubnet "EQ,MaliciousSubnet06" –FQDN “EQ,*.contosomalicious.com” -
PassThru
Bloquear um tipo de consulta

Talvez seja necessário bloquear a resolução de nomes para determinados tipos de
consultas em seus servidores. Por exemplo, você pode bloquear a consulta 'ANY', que
pode ser usada de forma mal-intencionada para criar ataques de amplificação.
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicyQType" -Action IGNORE -
QType "EQ,ANY" -PassThru
Permitir consultas somente de um domínio

Você não só pode usar a política DNS para bloquear consultas, mas também usá-las
para aprovar automaticamente consultas de domínios ou sub-redes específicos. Quando
você configura Listas de Permissão, o servidor DNS processa apenas consultas de
domínios permitidos, enquanto bloqueia todas as outras consultas de outros domínios.
O comando de exemplo a seguir permite que somente computadores e dispositivos nos

domínios contoso.com e filho consultem o servidor DNS.
Add-DnsServerQueryResolutionPolicy -Name "AllowListPolicyDomain" -Action IGNORE -

FQDN "NE,*.contoso.com" -PassThru
Permitir consultas somente de uma sub-rede
Você também pode criar Listas de Permitir para sub-redes IP, para que todas as
consultas que não se originam dessas sub-redes sejam ignoradas.
Add-DnsServerClientSubnet -Name "AllowedSubnet06" -IPv4Subnet 172.0.33.0/24 -

PassThru
Add-DnsServerQueryResolutionPolicy -Name "AllowListPolicySubnet” -Action
IGNORE -ClientSubnet "NE, AllowedSubnet06" -PassThru
Permitir apenas determinados QTypes

Você pode aplicar Listas de Permitir a QTYPEs.
Por exemplo, se você tiver clientes externos consultando a interface do servidor DNS
164.8.1.1, somente determinados QTYPEs poderão ser consultados, enquanto outros
QTYPEs, como registros SRV ou TXT, que são usados por servidores internos para
resolução de nomes ou para fins de monitoramento.
Add-DnsServerQueryResolutionPolicy -Name "AllowListQType" -Action IGNORE -QType
"NE,A,AAAA,MX,NS,SOA" –ServerInterface “EQ,164.8.1.1” -PassThru
gerenciamento de tráfego e todas as novas políticas são aplicadas dinamicamente –
sem reiniciar o servidor DNS – em consultas de entrada.
Usar a Política de DNS para
balanceamento de carga de aplicativo
Você pode usar este tópico para saber como configurar a política DNS para executar o
balanceamento de carga do aplicativo.
As versões anteriores do Windows DNS do servidor só forneceram balanceamento de

carga usando respostas round robin; mas com o DNS em Windows Server 2016, você
pode configurar a política DNS para o balanceamento de carga do aplicativo.
Quando você tiver implantado várias instâncias de um aplicativo, poderá usar a política
DNS para equilibrar a carga de tráfego entre as diferentes instâncias do aplicativo,
alocando dinamicamente a carga de tráfego para o aplicativo.
Exemplo de balanceamento de carga do

aplicativo
Veja a seguir um exemplo de como você pode usar a política DNS para balanceamento
de carga do aplicativo.
Este exemplo usa uma empresa fictícia - Contoso Gift Services - que fornece serviços de
presente online e que tem um site chamado contosogiftservices.com.
O site contosogiftservices.com é hospedado em vários datacenters que têm endereços

IP diferentes.
Em América do Norte, que é o principal mercado para os Serviços de Presentes da

Contoso, o site é hospedado em três datacenters: Chicago, IL, Dallas, TX e Seattle, WA.
O servidor Web de Seattle tem a melhor configuração de hardware e pode lidar com o
dobro de carga que os outros dois sites. Os Serviços de Presentes da Contoso querem o
tráfego de aplicativo direcionado da maneira a seguir.
Como o servidor Web de Seattle inclui mais recursos, metade dos clientes do
aplicativo são direcionados para este servidor
Um quarto dos clientes do aplicativo são direcionados para o datacenter Dallas, TX
Um quarto dos clientes do aplicativo são direcionados para Chicago, IL, datacenter
Como funciona o balanceamento de carga do aplicativo

Depois de configurar o servidor DNS com a política DNS para balanceamento de carga
do aplicativo usando este cenário de exemplo, o servidor DNS responde 50% do tempo
com o endereço do servidor Web de Seattle, 25% do tempo com o endereço do
servidor Web Dallas e 25% do tempo com o endereço do servidor Web de Chicago.
Assim, para cada quatro consultas que o servidor DNS recebe, ele responde com duas
respostas para Seattle e uma para Dallas e Chicago.
Um possível problema com o balanceamento de carga com a política DNS é o cache de

registros DNS pelo cliente DNS e o resolvedor/LDNS, que podem interferir no
balanceamento de carga porque o cliente ou resolvedor não envia uma consulta para o
servidor DNS.
Você pode atenuar o efeito desse comportamento usando um valor TTL (time-to-live)
baixo para os registros DNS que devem ser balanceados por carga.
Como configurar o balanceamento de carga do aplicativo

As seções a seguir mostram como configurar a política DNS para o balanceamento de
carga do aplicativo.
Primeiro, você deve criar os escopos da contosogiftservices.com de zona para os
datacenters em que eles estão hospedados.
７ Observação
PowerShell

"SeattleZoneScope"

"DallasZoneScope"

"ChicagoZoneScope"

Agora você deve adicionar os registros que representam o host do servidor Web aos
escopos de zona.
No SeattleZoneScope, você pode adicionar o registro www.contosogiftservices.com

com o endereço IP 192.0.0.1, que está localizado no datacenter de Seattle.
No ChicagoZoneScope, você pode adicionar o mesmo registro

(www.contosogiftservices.com) com o endereço IP 182.0.0.1 no datacenter de Chicago.
Da mesma forma em DallasZoneScope, você pode adicionar um registro

(www.contosogiftservices.com) com o endereço IP 162.0.0.1 no datacenter de Chicago.
escopos de zona.
PowerShell

"www" -IPv4Address "192.0.0.1" -ZoneScope "SeattleZoneScope"

"www" -IPv4Address "182.0.0.1" -ZoneScope "ChicagoZoneScope"

"www" -IPv4Address "162.0.0.1" -ZoneScope "DallasZoneScope"

Depois de criar as partições (escopos de zona) e adicionar registros, você deve criar
políticas DNS que distribuam as consultas de entrada nesses escopos para que 50% das
consultas para contosogiftservices.com sejam respondidas com o endereço IP do
servidor Web no datacenter de Seattle e o restante seja distribuído igualmente entre os
datacenters de Chicago e Dallas.
Você pode usar os comandos Windows PowerShell a seguir para criar uma política DNS
que balancee o tráfego do aplicativo entre esses três datacenters.
７ Observação
No comando de exemplo abaixo, a expressão –ZoneScope "SeattleZoneScope,2;

ChicagoZoneScope,1; DallasZoneScope,1" configura o servidor DNS com uma
matriz que inclui a combinação <ZoneScope> de parâmetros , <weight> .
PowerShell
Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -

ZoneScope "SeattleZoneScope,2;ChicagoZoneScope,1;DallasZoneScope,1" -
ZoneName "contosogiftservices.com"
Agora você criou com êxito uma política DNS que fornece balanceamento de carga do
aplicativo entre servidores Web em três datacenters diferentes.
Usar a Política de DNS para
balanceamento de aplicativo com
reconhecimento de localização
geográfica
Você pode usar este tópico para saber como configurar a política DNS para balancear a
carga de um aplicativo com reconhecimento de localização geográfica.
O tópico anterior neste guia, Usar política DNS para balanceamento de carga de
aplicativos, usa um exemplo de uma empresa fictícia – Contoso Gift Services – que
fornece serviços de presentes online e que tem um site chamado
contosogiftservices.com. O Contoso Gift Services balanceia a carga de seu aplicativo
Web online entre servidores em datacenters da América do Norte localizados em
Seattle, WA, Chicago, IL e Dallas, TX.
７ Observação
É recomendável que você se familiarize com o tópico Usar Política DNS para
Balanceamento de Carga de Aplicativo antes de executar as instruções neste
cenário.
Este tópico usa a mesma infraestrutura fictícia de rede e empresa como base para uma
nova implantação de exemplo que inclui reconhecimento de localização geográfica.
Neste exemplo, os Serviços de Presentes da Contoso estão expandindo com êxito sua
presença em todo o mundo.
Semelhante ao América do Norte, a empresa agora tem servidores Web hospedados em

datacenters europeus.
Os administradores dns dos Serviços de Presentes da Contoso querem configurar o

balanceamento de carga do aplicativo para datacenters europeus de maneira
semelhante à implementação da política DNS no Estados Unidos, com o tráfego de
aplicativo distribuído entre servidores Web localizados em Dublin, Irlanda, Amsterdã,
Amsterdã, Amsterdã e em outro lugar.
Os administradores de DNS também querem que todas as consultas de outros locais do
mundo distribuídas igualmente entre todos os seus datacenters.
Nas próximas seções, você pode aprender a atingir metas semelhantes às dos
Administradores dns da Contoso em sua própria rede.
Como configurar o balanceamento de carga do

aplicativo com Geo-Location reconhecimento
As seções a seguir mostram como configurar a política DNS para balanceamento de
carga do aplicativo com reconhecimento de localização geográfica.
） Importante
As seções a seguir incluem Windows PowerShell comandos que contêm valores de

exemplo para muitos parâmetros. Substitua os valores de exemplo nesses
comandos por valores apropriados para sua implantação antes de executar esses
comandos.
Criar as sub-redes do cliente DNS

Primeiro, você deve identificar as sub-redes ou o espaço de endereço IP das regiões
América do Norte e Europa.
Você pode obter essas informações de mapas geo-IP. Com base nessas distribuições
geo-IP, você deve criar as sub-redes do cliente DNS.
Uma sub-rede de cliente DNS é um grupo lógico de sub-redes IPv4 ou IPv6 das quais as
consultas são enviadas a um servidor DNS.
Você pode usar os comandos Windows PowerShell a seguir para criar sub-redes de
cliente DNS.
PowerShell
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

Criar os escopos de zona
Depois que as sub-redes do cliente estão em vigor, você deve particionar a zona
contosogiftservices.com escopos de zona diferentes, cada uma para um datacenter.
７ Observação
mesmo nome que a zona e as operações dns herddas funcionam nesse escopo.
O cenário anterior no balanceamento de carga do aplicativo demonstra como

configurar três escopos de zona para datacenters América do Norte.
Com os comandos abaixo, você pode criar mais dois escopos de zona, um para os
datacenters Dublin e Amsterdã.
Você pode adicionar esses escopos de zona sem nenhuma alteração aos três escopos
América do Norte zona existentes na mesma zona. Além disso, depois de criar esses
escopos de zona, você não precisa reiniciar o servidor DNS.
PowerShell

"DublinZoneScope"

"AmsterdamZoneScope"

Agora você deve adicionar os registros que representam o host do servidor Web aos
escopos de zona.
Os registros dos datacenters da América foram adicionados no cenário anterior. Você

pode usar os comandos Windows PowerShell a seguir para adicionar registros aos
escopos de zona para datacenters europeus.
PowerShell

"www" -IPv4Address "151.1.0.1" -ZoneScope "DublinZoneScope”

"www" -IPv4Address "141.1.0.1" -ZoneScope "AmsterdamZoneScope"

Depois de criar as partições (escopos de zona) e adicionar registros, você deve criar
políticas DNS que distribuam as consultas de entrada entre esses escopos.
Neste exemplo, a distribuição de consultas entre servidores de aplicativos em

datacenters diferentes atende aos critérios a seguir.
1. Quando a consulta DNS é recebida de uma fonte em uma sub-rede de cliente

norte-americana, 50% das respostas DNS apontam para o Seattle data center, 25%
das respostas apontam para o datacenter de Chicago e os 25% restantes das
respostas apontam para o datacenter de Dallas.
2. Quando a consulta DNS é recebida de uma fonte em uma sub-rede de cliente
europeia, 50% das respostas DNS apontam para o datacenter de Dublin e 50% das
respostas DNS apontam para o datacenter de Amsterdã.
3. Quando a consulta vem de qualquer outro lugar do mundo, as respostas DNS são
distribuídas entre todos os cinco datacenters.
Você pode usar os comandos Windows PowerShell a seguir para implementar essas
políticas DNS.
PowerShell
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
Agora você criou com êxito uma política DNS que fornece balanceamento de carga de
aplicativo entre servidores Web localizados em cinco datacenters diferentes em vários
continentes.
gerenciamento de tráfego e todas as novas políticas são aplicadas dinamicamente –
sem reiniciar o servidor DNS – em consultas de entrada.
Solução de problemas do DNS (Sistema
de Nomes de Domínio)
Experimente nosso Agente Virtual – ele pode ajudá-lo a identificar e corrigir
rapidamente problemas comuns de DNS.
Problemas de resolução de nome de domínio podem ser divididos em problemas do

lado do cliente e do lado do servidor. Em geral, você deve começar com a solução de
problemas do lado do cliente, a menos que determine durante a fase de escopo que o
problema está ocorrendo definitivamente no lado do servidor.
Solução de problemas de clientes DNS
Solução de problemas em servidores DNS
Coleta de dados
Recomendamos que você colete dados simultaneamente nos lados do cliente e do
servidor quando o problema ocorrer. No entanto, dependendo do problema real, você
pode iniciar sua coleção em um único conjunto de dados no cliente DNS ou no servidor
DNS.
Para coletar um Diagnóstico de Rede do Windows de um cliente afetado e seu servidor

DNS configurado, siga estas etapas:
1. Iniciar capturas de rede no cliente e no servidor:
cmd
netsh trace start capture=yes tracefile=c:\%computername%_nettrace.etl
2. Limpe o cache DNS no cliente DNS executando o seguinte comando:
cmd
ipconfig /flushdns
3. Reproduza o problema.
4. Parar e salvar rastreamentos:

cmd
netsh trace stop
5. Salve os arquivos Nettrace.cab de cada computador. Essas informações serão úteis

quando você entrar em contato com Suporte da Microsoft.
Solução de problemas de clientes DNS
Este artigo discute como solucionar problemas de clientes DNS.
Verificar configuração de IP
1. Abra uma janela de prompt de comando como administrador no computador
cliente.
2. Execute o comando a seguir:
cmd
ipconfig /all
3. Verifique se o cliente tem um endereço IP, uma máscara de sub-rede e um

gateway padrão válidos para a rede à qual ele está conectado e sendo usado.
4. Verifique os servidores DNS listados na saída e verifique se os endereços IP

listados estão corretos.
5. Verifique o sufixo DNS específico da conexão na saída e verifique se ele está

correto.
Se o cliente não tiver uma configuração de TCP/IP válida, use um dos seguintes
métodos:
Para clientes configurados dinamicamente, use o ipconfig /renew comando para

forçar manualmente o cliente a renovar sua configuração de endereço IP com o
servidor DHCP.
Para clientes configurados estaticamente, modifique as propriedades de TCP/IP do

cliente para usar definições de configuração válidas ou conclua sua configuração
de DNS para a rede.
Verificar conexão de rede
Teste de ping
Verifique se o cliente pode contatar um servidor DNS preferencial (ou alternativo) ao
executar ping no servidor DNS preferencial por seu endereço IP.
Por exemplo, se o cliente usar um servidor DNS preferencial de 10.0.0.1, execute este
comando em um prompt de comando:
cmd
ping 10.0.0.1
Se nenhum servidor DNS configurado responder a um ping direto de seu endereço IP,
isso indica que a origem do problema é mais provável que a conectividade de rede
entre o cliente e os servidores DNS. Se esse for o caso, siga as etapas básicas de solução
de problemas de rede TCP/IP para corrigir o problema. Tenha em mente que o tráfego
ICMP deve ser permitido por meio do firewall para que o comando ping funcione.
Testes de consulta DNS

Se o cliente DNS puder executar ping no computador do servidor DNS, tente usar os
comandos a seguir nslookup para testar se o servidor pode responder a clientes DNS.
Como o nslookup não usa o cache DNS do cliente, a resolução de nomes usará o
servidor DNS configurado do cliente.
Testar um cliente
cmd
nslookup <client>
Por exemplo, se o computador cliente for chamado de CLIENT1, execute este comando:
cmd
nslookup client1
Se uma resposta bem-sucedida não for retornada, tente executar o seguinte comando:
cmd
nslookup <fqdn of client>
Por exemplo, se o FQDN for CLIENT1.Corp.contoso.com, execute este comando:

cmd
nslookup client1.corp.contoso.com.
７ Observação
Você deve incluir o ponto à direita ao executar esse teste.
se Windows encontrar com êxito o FQDN, mas não encontrar o nome curto, verifique a
configuração do sufixo dns na guia DNS do Configurações TCP/IP avançado da NIC.
Para obter mais informações, consulte Configuring DNS Resolution.
Testar o servidor DNS
cmd
nslookup <DNS Server>
Por exemplo, se o servidor DNS for denominado DC1, execute este comando:
cmd
nslookup dc1
Se os testes anteriores tiverem sido bem-sucedidos, esse teste também deverá ser bem-
sucedido. Se esse teste não for bem-sucedido, verifique a conectividade com o servidor
DNS.
Testar o registro com falha
cmd
nslookup <failed internal record>
Por exemplo, se o registro com falha for App1.Corp.contoso.com, execute este

comando:
cmd
nslookup app1.corp.contoso.com
Testar um endereço de Internet público
cmd
nslookup <external name>
Por exemplo:
cmd
nslookup bing.com
Se todos os quatro testes tiverem sido bem-sucedidos, execute ipconfig /displaydns e

verifique a saída do nome que falhou. Se você vir "o nome não existe" sob o nome com
falha, uma resposta negativa foi retornada de um servidor DNS e armazenada em cache
no cliente.
Para resolver o problema, limpe o cache executando ipconfig /flushdns .
Próxima etapa
Se a resolução de nomes ainda estiver falhando, vá para a seção Solucionando
problemas de servidores DNS .
Solução de problemas de servidores
DNS
rapidamente problemas comuns de DNS.
Este artigo discute como solucionar problemas em servidores DNS.
Verificar a configuração de IP
1. Execute ipconfig /all em um prompt de comando e verifique o endereço IP, a
máscara de sub-rede e o gateway padrão.
2. Verifique se o servidor DNS é autoritativo para o nome que está sendo pesquisado.
Nesse caso, consulte Verificando se há problemas com dados autoritativos.
3. Execute o comando a seguir:
cmd
nslookup <name> <IP address of the DNS server>
Por exemplo:
cmd
nslookup app1 10.0.0.1
Se você receber uma falha ou uma resposta de tempo limite, consulte Verificando
problemas de recursão.
4. Libere o cache do resolvedor. Para fazer isso, execute o seguinte comando em uma
janela administrativa do Prompt de Comando:
cmd
dnscmd /clearcache
Ou, em uma janela administrativa do PowerShell, execute o seguinte cmdlet:

PowerShell
Clear-DnsServerCache
5. Repita a etapa 3.
Verificar problemas do servidor DNS
Log de eventos
Verifique os seguintes logs para ver se há erros registrados:
Aplicativo
Sistema
Servidor DNS
Testar usando a consulta nslookup

Execute o comando a seguir e verifique se o servidor DNS pode ser acessado nos
computadores cliente.
cmd
nslookup <client name> <server IP address>
Se o resolvedor retornar o endereço IP do cliente, o servidor não terá nenhum

problema.
Se o resolvedor retornar uma resposta "Falha do servidor" ou "Consulta recusada",

a zona provavelmente está pausada ou o servidor possivelmente está
sobrecarregado. Para saber se ele está em pausa verifique a guia Geral das
propriedades da zona no console DNS.
Se o resolvedor retornar uma resposta "Solicitação ao servidor atingiu o tempo limite"

ou "Nenhuma resposta do servidor", o serviço DNS provavelmente não está em
execução. Tente reiniciar o serviço do Servidor DNS inserindo o seguinte em um prompt
de comando no servidor:
cmd
net start DNS
Se o problema ocorrer quando o serviço estiver em execução, o servidor poderá não

estar escutando o endereço IP que você usou na consulta nslookup. Na guia Interfaces
da página de propriedades do servidor no console DNS, os administradores podem
restringir um servidor DNS para escutar apenas os endereços selecionados. Se o
servidor DNS tiver sido configurado para limitar o serviço a uma lista específica de seus
endereços IP configurados, é possível que o endereço IP usado para contatar o servidor
DNS não esteja na lista. Você pode experimentar um endereço IP diferente na lista ou
adicionar o endereço IP à lista.
Em casos raros, o servidor DNS pode ter uma configuração avançada de segurança ou
firewall. Se o servidor estiver localizado em outra rede que só pode ser acessada por
meio de um host intermediário (como um roteador de filtragem de pacotes ou um
servidor proxy), o servidor DNS poderá usar uma porta não padrão para escutar e
receber solicitações de cliente. Por padrão, o nslookup envia consultas para servidores
DNS na porta UDP 53. Portanto, se o servidor DNS usar qualquer outra porta, as
consultas nslookup falharão. Se você acha que esse pode ser o problema, verifique se
um filtro intermediário é usado intencionalmente para bloquear o tráfego em portas
DNS conhecidas. Se não for, tente modificar os filtros de pacote ou as regras de porta
no firewall para permitir o tráfego na porta UDP/TCP 53.
Verificando problemas com dados autoritativos

Verifique se o servidor que retorna a resposta incorreta é um servidor primário para a
zona (o servidor primário padrão para a zona ou um servidor que usa a integração do
Active Directory para carregar a zona) ou um servidor que hospeda uma cópia
secundária da zona.
Se o servidor for um servidor primário

O problema pode ser causado por erro do usuário quando os usuários inserem dados
na zona. Ou pode ser causado por um problema que afeta a replicação do Active
Directory ou a atualização dinâmica.
Se o servidor estiver hospedando uma cópia secundária

da zona
1. Examine a zona no servidor primário (o servidor do qual esse servidor efetua pull
da zona transfere).
７ Observação
Você pode determinar qual servidor é o servidor primário examinando as

propriedades da zona secundária no console DNS.
Se o nome não estiver correto no servidor primário, vá para a etapa 4.
2. Se o nome estiver correto no servidor primário, verifique se o número de série no

servidor primário é menor ou igual ao número de série no servidor secundário. Se
for, modifique o servidor primário ou o servidor secundário para que o número de
série no servidor primário seja maior que o número de série no servidor
secundário.
3. No servidor secundário, force uma transferência de zona de dentro do console

DNS ou executando o seguinte comando:
cmd
dnscmd /zonerefresh <zone name>
Por exemplo, se a zona for corp.contoso.com, insira: dnscmd /zonerefresh

corp.contoso.com .
4. Examine o servidor secundário novamente para ver se a zona foi transferida

corretamente. Caso contrário, você provavelmente tem um problema de
transferência de zona. Para obter mais informações, consulte Problemas de
transferência de zona.
5. Se a zona foi transferida corretamente, verifique se os dados agora estão corretos.

Caso contrário, os dados estão incorretos na zona primária. O problema pode ser
causado por erro do usuário quando os usuários inserem dados na zona. Ou pode
ser causado por um problema que afeta a replicação do Active Directory ou a
atualização dinâmica.
Verificando se há problemas de recursão

Para que a recursão funcione com êxito, todos os servidores DNS usados no caminho de
uma consulta recursiva devem ser capazes de responder e encaminhar dados corretos.
Se não puderem, uma consulta recursiva poderá falhar por qualquer um dos seguintes
motivos:
A consulta atinge o tempo limite antes de ser concluída.

Um servidor usado durante a consulta não responde.
Um servidor usado durante a consulta fornece dados incorretos.
Inicie a solução de problemas no servidor que foi usado em sua consulta original.
Verifique se esse servidor encaminha consultas para outro servidor examinando a guia
Encaminhadores nas propriedades do servidor no console DNS. Se a caixa de seleção
Habilitar encaminhadores estiver marcada e um ou mais servidores estiverem listados,
esse servidor encaminhará as consultas.
Se esse servidor encaminhar consultas para outro servidor, verifique se há problemas

que afetam o servidor para o qual esse servidor encaminha consultas. Para verificar se
há problemas, confira Verificar problemas do servidor DNS. Quando essa seção instrui
você a executar uma tarefa no cliente, execute-a no servidor.
Se o servidor estiver íntegro e puder encaminhar consultas, repita esta etapa e examine
o servidor para o qual esse servidor encaminha consultas.
Se esse servidor não encaminhar consultas para outro servidor, teste se esse servidor
pode consultar um servidor raiz. Para fazer isso, execute o seguinte comando:
cmd
nslookup
server <IP address of server being examined>
set q=NS
Se o resolvedor retornar o endereço IP de um servidor raiz, você provavelmente

terá uma delegação interrompida entre o servidor raiz e o nome ou endereço IP
que você está tentando resolver. Siga o procedimento Testar uma delegação
interrompida para determinar onde você tem uma delegação interrompida.
Se o resolvedor retornar uma resposta "Solicitação ao servidor atingiu o tempo

limite", verifique se as dicas raiz apontam para servidores raiz em funcionamento.
Para fazer isso, use o procedimento Para exibir as dicas raiz atuais . Se as dicas raiz
apontarem para servidores raiz em funcionamento, você poderá ter um problema
de rede ou o servidor poderá usar uma configuração de firewall avançada que
impede que o resolvedor consulte o servidor, conforme descrito na seção Verificar
problemas do servidor DNS . Também é possível que o padrão de tempo limite
recursivo seja muito curto.
Testar uma delegação quebrada

Inicie os testes no procedimento a seguir consultando um servidor raiz válido. O teste
leva você por meio de um processo de consulta de todos os servidores DNS da raiz até
o servidor que você está testando para uma delegação interrompida.
1. No prompt de comando no servidor que você está testando, insira o seguinte:
cmd
nslookup
server <server IP address>
set norecursion
set querytype= <resource record type>
<FQDN>
７ Observação
O tipo de registro de recurso é o tipo de registro de recurso que você estava

consultando em sua consulta original, e FQDN é o FQDN para o qual você
estava consultando (encerrado por um período).
2. Se a resposta incluir uma lista de registros de recursos "NS" e "A" para servidores
delegados, repita a etapa 1 para cada servidor e use o endereço IP dos registros de
recurso "A" como o endereço IP do servidor.
Se a resposta não contiver um registro de recurso "NS", você terá uma

delegação interrompida.
Se a resposta contiver registros de recurso "NS", mas nenhum registro de

recurso "A", insira recursão de conjunto e consulte individualmente registros
de recursos "A" de servidores listados nos registros "NS". Se você não
encontrar pelo menos um endereço IP válido de um registro de recurso "A"
para cada registro de recurso NS em uma zona, você terá uma delegação
interrompida.
3. Se você determinar que tem uma delegação quebrada, corrija-a adicionando ou

atualizando um registro de recurso "A" na zona pai usando um endereço IP válido
para um servidor DNS correto para a zona delegada.
Para exibir as dicas de raiz atuais

1. Inicie o console DNS.
2. Adicione ou conecte-se ao servidor DNS que falhou em uma consulta recursiva.

3. Clique com o botão direito do mouse no servidor e selecione Propriedades.
4. Clique em Dicas raiz.
Verifique se há conectividade básica com os servidores raiz.
Se as dicas raiz parecerem estar configuradas corretamente, verifique se o servidor

DNS usado em uma resolução de nomes com falha pode executar ping nos
servidores raiz por endereço IP.
Se os servidores raiz não responderem ao ping por endereço IP, os endereços IP

dos servidores raiz poderão ter sido alterados. No entanto, é incomum ver uma
reconfiguração de servidores raiz.
Problemas de transferência de zona

Execute as seguintes verificações:
Verifique Visualizador de Eventos para o servidor DNS primário e secundário.
Verifique o servidor primário para ver se ele está se recusando a enviar a

transferência para segurança.
Verifique a guia Transferências de Zona das propriedades da zona no console

DNS. Se o servidor restringir as transferências de zona para uma lista de servidores,
como aqueles listados na guia Servidores de Nomes das propriedades da zona,
verifique se o servidor secundário está nessa lista. Verifique se o servidor está
configurado para enviar transferências de zona.
Verifique se há problemas no servidor primário seguindo as etapas na seção

Verificar problemas do servidor DNS . Quando for solicitado que você execute uma
tarefa no cliente, execute a tarefa no servidor secundário.
Verifique se o servidor secundário está executando outra implementação de

servidor DNS, como BIND. Se for, o problema pode ter uma das seguintes causas:
O servidor primário do Windows pode estar configurado para enviar

transferências de zona rápidas, mas o servidor secundário de terceiros pode não
dar suporte a transferências de zona rápida. Se esse for o caso, desabilite as
transferências de zona rápida no servidor primário de dentro do console DNS
marcando a caixa de seleção Habilitar Associar secundários na guia Avançado
das propriedades do servidor.
Se uma zona de pesquisa no servidor Windows contiver um tipo de registro
(por exemplo, um registro SRV) ao qual o servidor secundário não dá suporte, o
servidor secundário poderá ter problemas para efetuar pull da zona.
Verifique se o servidor primário está executando outra implementação de servidor DNS,

como BIND. Nesse caso, é possível que a zona no servidor primário inclua registros de
recursos incompatíveis que o Windows não reconhece.
Se o servidor mestre ou secundário estiver executando outra implementação de servidor

DNS, verifique os dois servidores para garantir que eles ofereçam suporte aos mesmos
recursos. Você pode verificar o servidor Windows no console DNS na guia Avançado da
página de propriedades do servidor. Além da caixa Habilitar Associar secundários, esta
página inclui a lista suspensa Verificação de nomes . Isso permite que você selecione a
imposição de conformidade estrita de RFC para caracteres em nomes DNS.
Protocolo DHCP
Você pode usar este tópico para uma breve visão geral do DHCP Windows Server 2016.
７ Observação
Além deste tópico, a documentação do DHCP a seguir está disponível.
Novidades no DHCP
Implantar o DHCP usando Windows PowerShell
O protocolo DHCP é um protocolo de cliente/servidor que fornece automaticamente

um host ip (protocolo IP) com seu endereço IP e outras informações de configuração
relacionadas, como a máscara de sub-rede e o gateway padrão. As RFCs 2131 e 2132
definem o DHCP como um padrão de IETF (Força-Tarefa de Engenharia da Internet) com
base no protocolo BOOTP, um protocolo com o qual o DHCP compartilha muitos
detalhes de implementação. O DHCP permite que os hosts obtenham informações de
configuração TCP/IP necessárias de um servidor DHCP.
Windows Server 2016 inclui o Servidor DHCP, que é uma função de servidor de rede
opcional que você pode implantar em sua rede para concessão de endereços IP e outras
informações para clientes DHCP. Todos Windows sistemas operacionais cliente
baseados em Windows incluem o cliente DHCP como parte do TCP/IP e o cliente DHCP
está habilitado por padrão.
Por que usar o DHCP?

Cada dispositivo em uma rede baseada em TCP/IP deve ter um endereço IP unicast
exclusivo para acessar a rede e seus recursos. Sem o DHCP, os endereços IP para novos
computadores ou computadores que são movidos de uma sub-rede para outra devem
ser configurados manualmente; Os endereços IP para computadores removidos da rede
devem ser recuperados manualmente.
Com o DHCP, todo esse processo é automatizado e gerenciado centralmente. O

servidor DHCP mantém um pool de endereços IP e arrenda um endereço para qualquer
cliente habilitado para DHCP quando ele é iniciado na rede. Como os endereços IP são
dinâmicos (concessões) em vez de estáticos (atribuídos permanentemente), os
endereços que não estão mais em uso são retornados automaticamente ao pool para
realocação.
O administrador de rede estabelece servidores DHCP que mantêm informações de

configuração TCP/IP e fornecem a configuração de endereço para clientes habilitados
para DHCP na forma de uma oferta de concessão. O servidor DHCP armazena as
informações de configuração em um banco de dados que inclui:
Parâmetros de configuração TCP/IP válidos para todos os clientes na rede.
Endereços IP válidos, mantidos em um pool para atribuição a clientes, bem como

endereços excluídos.
IP Reservado endereços associados a clientes DHCP específicos. Isso permite a

atribuição consistente de um único endereço IP para um único cliente DHCP.
A duração da concessão ou o período de tempo para o qual o endereço IP pode

ser usado antes que uma renovação de concessão seja necessária.
Um cliente habilitado para DHCP, após aceitar uma oferta de concessão, recebe:
Um endereço IP válido para a sub-rede à qual ela está se conectando.
Opções DHCP solicitadas, que são parâmetros adicionais que um servidor DHCP
está configurado para atribuir aos clientes. Alguns exemplos de opções de DHCP
são Roteador (gateway padrão), Servidores DNS e Nome de Domínio DNS.
Benefícios do DHCP
O DHCP oferece os seguintes benefícios.
Configuração de endereço IP confiável. O DHCP minimiza os erros de

configuração causados pela configuração manual de endereço IP, como erros
tipográficos ou conflitos de endereço causados pela atribuição de um endereço IP
a mais de um computador ao mesmo tempo.
Administração de rede reduzida. O DHCP inclui os seguintes recursos para reduzir

a administração de rede:
Configuração TCP/IP centralizada e automatizada.
A capacidade de definir configurações de TCP/IP de um local central.

A capacidade de atribuir um intervalo completo de valores de configuração
TCP/IP adicionais por meio de opções DHCP.
O tratamento eficiente de alterações de endereço IP para clientes que devem

ser atualizados com frequência, como aqueles para dispositivos portáteis que se
movem para locais diferentes em uma rede sem fio.
O encaminhamento de mensagens DHCP iniciais usando um agente de

retransmissão DHCP, que elimina a necessidade de um servidor DHCP em cada
sub-rede.
Novidades no DHCP
Este tópico descreve a funcionalidade DHCP (protocolo de configuração dinâmica de

hosts) que é nova ou alterada no Windows Server 2016.
O DHCP é um padrão IETF (Internet Engineering Task Force) projetado para reduzir a
carga administrativa e a complexidade da configuração de hosts em uma rede baseada
em TCP/IP, por exemplo, uma intranet privada. Usando o serviço de servidor DHCP, o
processo de configuração de TCP/IP em clientes DHCP é automático.
As seções a seguir fornecem informações sobre novos recursos e alterações na

funcionalidade do DHCP.
novos recursos do lado do cliente DHCP no

Windows 10 podem atualizar 2020
o cliente DHCP no Windows 10 foi atualizado na atualização de 10 de maio de 2020
(também conhecida como Windows 10, versão 2004). quando você estiver executando
um cliente Windows e conectar-se à internet por meio de um telefone Android
conectado, a conexão deverá ser marcada como "limitada". Anteriormente, as conexões
foram marcadas como ilimitadas. Observe que nem todos os telefones com
compartilhamento de Internet do Android serão detectados como limitados, e algumas
outras redes também poderão aparecer como limitadas.
além disso, o nome tradicional do fornecedor do cliente foi atualizado para alguns
dispositivos baseados em Windows. Esse valor costumava ser simplesmente MSFT 5,0.
Alguns dispositivos agora aparecerão como MSFT 5,0 XBOX.
novos recursos do lado do cliente DHCP no

Windows 10 atualização de abril de 2018
o cliente DHCP no Windows 10 foi atualizado na atualização Windows abril de 2018
(também conhecida como Windows 10, versão 1803) para ler e aplicar a opção 119, a
opção de pesquisa de domínio, do servidor DHCP ao qual seu sistema se conecta. A
opção de pesquisa de domínio fornece sufixos DNS para pesquisas de DNS de nomes
curtos. A opção de DHCP 119 é especificada em RFC 3397 .
Opções de seleção de sub-rede DHCP
O DHCP agora dá suporte à opção 82 (subopção 5). Você pode usar essa opção para
permitir que clientes proxy DHCP e agentes de retransmissão solicitem um endereço IP
para uma sub-rede específica.
Se você estiver usando um agente de retransmissão DHCP configurado com a opção de

DHCP 82, a subopção 5, o agente de retransmissão poderá solicitar uma concessão de
endereço IP para clientes DHCP de um intervalo de endereços IP específico.
Para obter mais informações, consulte Opções de seleção de sub-rede do DHCP.
Novos eventos de log para falhas de registro

de DNS pelo servidor DHCP
O DHCP agora inclui eventos de registro em log para circunstâncias em que os registros
de registro DNS do servidor DHCP falham no servidor DNS.
Para obter mais informações, consulte eventos de log do DHCP para registros de
registro DNS.
Não há suporte para NAP do DHCP no

Windows Server 2016
a nap (proteção de acesso à rede) é preterida no Windows Server 2012 R2 e, em
Windows Server 2016 a função de servidor DHCP não oferece mais suporte a NAP. para
obter mais informações, consulte recursos removidos ou preteridos no Windows Server
2012 R2.
o suporte a NAP foi introduzido na função de servidor DHCP com o Windows Server
2008 e tem suporte em Windows sistemas operacionais de cliente e servidor antes de
Windows 10 e Windows Server 2016. a tabela a seguir resume o suporte para NAP no
Windows Server.
Sistema operacional Suporte a NAP
Windows Server 2008 Com suporte
Windows Server 2008 R2 Com suporte
Windows Server 2012 Com suporte

Sistema operacional Suporte a NAP
Windows Server 2012 R2 Com suporte
Windows Server 2016 Sem suporte
Em uma implantação de NAP, um servidor DHCP que executa um sistema operacional

que dá suporte a NAP pode funcionar como um ponto de imposição de NAP para o
método de imposição de DHCP NAP. Para obter mais informações sobre o DHCP em
NAP, consulte lista de verificação: Implementando um design de imposição de DHCP.
no Windows Server 2016, os servidores dhcp não impõem políticas NAP e os escopos
dhcp não podem ser habilitados para NAP. Os computadores cliente DHCP que também
são clientes NAP enviam uma SoH (declaração de integridade) com a solicitação DHCP.
se o servidor DHCP estiver em execução Windows Server 2016, essas solicitações serão
processadas como se nenhuma SoH estiver presente. O servidor DHCP concede uma
concessão DHCP normal ao cliente.
se servidores que estão executando Windows Server 2016 são proxies RADIUS que
encaminham solicitações de autenticação para um servidor de diretivas de rede (NPS)
que dá suporte a nap, esses clientes NAP são avaliados pelo NPS como sem capacidade
de nap e o processamento de NAP falha.
Protocolo DHCP
Opções de seleção de sub-rede DHCP
Você pode usar este tópico para obter informações sobre as novas opções de seleção
de sub-rede do DHCP.
O DHCP agora dá suporte à opção 82 (subopção 5). Você pode usar essas opções para
permitir que clientes proxy DHCP e agentes de retransmissão solicitem um endereço IP
para uma sub-rede específica e de um intervalo de endereços IP e escopo específicos.
Para obter mais detalhes, confira a opção 82 sub Option 5: RFC 3527 link Selection
suboption para a opção de informações do agente de retransmissão para o DHCPv4 .
Se você estiver usando um agente de retransmissão DHCP configurado com a opção de

DHCP 82, a subopção 5, o agente de retransmissão poderá solicitar uma concessão de
endereço IP para clientes DHCP de um intervalo de endereços IP específico.
Opção 82 sub opção 5: opção de seleção de

link
A subopção seleção de link do agente de retransmissão permite que um agente de
retransmissão DHCP especifique uma sub-rede IP da qual o servidor DHCP deve atribuir
endereços IP e opções.
Normalmente, os agentes de retransmissão DHCP dependem do campo GIADDR

(endereço IP do gateway) para se comunicar com os servidores DHCP. No entanto, o
GIADDR é limitado por suas duas funções operacionais:
1. Para informar ao servidor DHCP sobre a sub-rede na qual o cliente DHCP que está
solicitando a concessão de endereço IP reside.
2. Para informar o servidor DHCP do endereço IP a ser usado para se comunicar com
o agente de retransmissão.
Em alguns casos, o endereço IP que o agente de retransmissão usa para se comunicar

com o servidor DHCP pode ser diferente do intervalo de endereços IP do qual o
endereço IP do cliente DHCP precisa ser alocado.
A opção de seleção de link da opção 82 é útil nessa situação, permitindo que o agente
de retransmissão declare explicitamente a sub-rede da qual deseja o endereço IP
alocado na forma de DHCP v4 Option 82 sub Option 5.
７ Observação
Todos os endereços IP do agente de retransmissão (GIADDR) devem fazer parte de

um intervalo de endereços IP de escopo DHCP ativo. qualquer GIADDR fora dos
intervalos de endereços IP do escopo DHCP é considerado uma retransmissão não
autorizada e Windows servidor dhcp não reconhecerá as solicitações de cliente
dhcp desses agentes de retransmissão.
Um escopo especial pode ser criado para "autorizar" agentes de retransmissão. Crie
um escopo com o GIADDR (ou vários se os GIADDR forem endereços IP
sequenciais), exclua os endereços GIADDR da distribuição e, em seguida, ative o
escopo. Isso autorizará os agentes de retransmissão ao impedir que os endereços
GIADDR sejam atribuídos.
Cenário do caso de uso

Nesse cenário, uma rede da organização inclui um servidor DHCP e um ponto de acesso
sem fio (AP) para os usuários convidados. Os endereços IP do cliente de convidados são
atribuídos do servidor DHCP da organização-no entanto, devido a restrições de política
de firewall, o servidor DHCP não pode acessar a rede sem fio convidada ou clientes sem
fio com mensagens broadcase.
Para resolver essa restrição, o AP é configurado com a subopção de seleção de link 5

para especificar a sub-rede da qual ele deseja o endereço IP alocado para clientes
convidados, enquanto no GIADDR também especifica o endereço IP da interface interna
que leva à rede corporativa.
Eventos de registro em log de DHCP
para registros DNS
Os logs de eventos do servidor DHCP agora fornecem informações detalhadas sobre

falhas de registro dns.
７ Observação
Em muitos casos, o motivo para falhas de registro de registro DNS por servidores
DHCP é que uma Zona Reverse-Lookup DNS está configurada incorretamente ou
não está configurada.
Os novos eventos DHCP a seguir ajudam você a identificar facilmente quando os

registros DNS estão falhando devido a uma zona de dns Reverse-Lookup dns
configurada inefigurada.
ID Evento Valor
20317 DHCPv4.ForwardRecordDNSFailure Falha no registro de encaminhamento para o

endereço IPv4 %1 e FQDN %2 com o erro %3.
Isso provavelmente é porque a zona de busca de
encaminhamento para esse registro não existe no
servidor DNS.
20318 DHCPv4.ForwardRecordDNSTimeout Falha no registro de encaminhamento para o

20319 DHCPv4.PTRRecordDNSFailure Falha no registro de registro PTR para o endereço

IPv4 %1 e FQDN %2 com o erro %3. Isso
provavelmente é porque a zona de busca inversa
para esse registro não existe no servidor DNS.
20320 DHCPv4.PTRRecordDNSTimeout Falha no registro de registro PTR para o endereço

IPv4 %1 e FQDN %2 com o erro %3.
20321 DHCPv6.ForwardRecordDNSFailure Falha no registro de encaminhamento para o

Isso provavelmente é porque a zona de busca de
encaminhamento para esse registro não existe no
servidor DNS.
ID Evento Valor
20322 DHCPv6.ForwardRecordDNSTimeout Falha no registro de encaminhamento para o

20323 DHCPv6.PTRRecordDNSFailure Falha no registro de registro PTR para o endereço

IPv6 %1 e FQDN %2 com o erro %3. Isso
provavelmente é porque a zona de busca inversa
para esse registro não existe no servidor DNS.
20324 DHCPv6.PTRRecordDNSTimeout Falha no registro de registro PTR para o endereço

IPv6 %1 e FQDN %2 com o erro %3.
20325 DHCPv4.ForwardRecordDNSError Falha no registro de registro PTR para o endereço

IPv4 %1 e FQDN %2 com o erro %3 (%4).
20326 DHCPv6.ForwardRecordDNSError Falha no registro de encaminhamento para o

endereço IPv6 %1 e FQDN %2 com o erro %3
(%4)
20327 DHCPv6.PTRRecordDNSError Falha no registro de registro PTR para o endereço

IPv6 %1 e FQDN %2 com o erro %3 (%4).
Implantar o DHCP usando o Windows
PowerShell
Este guia fornece instruções sobre como usar Windows PowerShell para implantar um
servidor DHCP (Protocolo de Protocolo de Internet) versão 4 que atribui
automaticamente endereços IP e opções DHCP a clientes DHCP IPv4 conectados a uma
ou mais sub-redes em sua rede.
７ Observação
Para baixar este documento no formato word da Galeria do TechNet, consulte

Implantar DHCP usando Windows PowerShell em Windows Server 2016 .
Usar servidores DHCP para atribuir endereços IP salva em sobrecarga administrativa

porque você não precisa definir manualmente as configurações de TCP/IP v4 para cada
adaptador de rede em cada computador em sua rede. Com o DHCP, a configuração de
TCP/IP v4 é executada automaticamente quando um computador ou outro cliente DHCP
está conectado à sua rede.
Você pode implantar seu servidor DHCP em um grupo de trabalho como um servidor
autônomo ou como parte de um domínio do Active Directory.
Visão geral da implantação do DHCP

Visão geral da tecnologia
Planejar implantação de DHCP
Usando este guia em um laboratório de teste
Implantar DHCP
Verificar a funcionalidade do servidor
Comandos Windows PowerShell para DHCP
Lista de comandos de Windows PowerShell neste guia
Visão geral da implantação do DHCP

A ilustração a seguir ilustra o cenário que você pode implantar usando este guia. O
cenário inclui um servidor DHCP em um domínio do Active Directory. O servidor está
configurado para fornecer endereços IP para clientes DHCP em duas sub-redes
diferentes. As sub-redes são separadas por um roteador que tem o Encaminhamento
DHCP habilitado.
Visões gerais de tecnologia

As seções a seguir fornecem breves visões gerais de DHCP e TCP/IP.
Visão geral do DHCP

O DHCP é um padrão de IP para simplificar o gerenciamento da configuração de IP do
host. O padrão DHCP proporciona o uso de servidores DHCP como uma forma de
gerenciar a alocação dinâmica de endereços IP e outros detalhes de configuração
relacionados para clientes habilitados para DHCP em sua rede.
O DHCP permite que você use um servidor DHCP para atribuir dinamicamente um
endereço IP a um computador ou outro dispositivo, como uma impressora, em sua rede
local, em vez de configurar manualmente todos os dispositivos com um endereço IP
estático.
Todos os computadores em uma rede TCP/IP devem ter um endereço IP exclusivo,

porque o endereço IP e a máscara de sub-rede relacionada identificam o computador
host e a sub-rede à qual o computador está conectado. Usando o DHCP, você pode
garantir que todos os computadores configurados como clientes DHCP recebam um
endereço IP que seja apropriado para seu local de rede e sua sub-rede e, usando as
opções de DHCP (como o gateway padrão e os servidores DNS), você pode fornecer
automaticamente aos clientes DHCP as informações que eles precisam para funcionar
corretamente na rede.
Para redes baseadas em TCP/IP, o DHCP reduz a complexidade e a quantidade de

trabalho administrativo envolvido na configuração de computadores.
Visão geral de TCP/IP

Por padrão, todas as versões dos sistemas operacionais Windows Server e Windows
Client têm configurações de TCP/IP para conexões de rede ip versão 4 configuradas
para obter automaticamente um endereço IP e outras informações, chamadas opções
DHCP, de um servidor DHCP. Por isso, você não precisa definir as configurações de
TCP/IP manualmente, a menos que o computador seja um computador de servidor ou
outro dispositivo que exija um endereço IP estático configurado manualmente.
Por exemplo, é recomendável que você configure manualmente o endereço IP do

servidor DHCP e os endereços IP de servidores DNS e controladores de domínio que
estão executando Active Directory Domain Services (AD DS).
TCP/IP no Windows Server 2016 é o seguinte:
Software de rede baseado em protocolos de rede padrão do setor.
Um protocolo de rede de empresa roteável que suporta a conexão de seu

computador baseado em Windows com os ambientes LAN (rede de área local) e
WAN (rede de longa distância).
As principais tecnologias e utilitários para conectar seu computador baseado em

Windows com os sistemas diferentes com a finalidade de compartilhar
informações.
Uma base para obter acesso a serviços globais de Internet, como servidores FTP
(Protocolo de Transferência de Arquivos e Web).
Uma estrutura robusta, escalável, multiplataforma, de cliente/servidor.
O TCP/IP oferece utilitários TCP/IP básicos que permitem que computadores baseados
no Windows se conectem e compartilhem informações com outros sistemas Microsoft e
não Microsoft, incluindo:
Windows Server 2016
Windows 10
Windows 8.1
Windows Server 2012
Windows 8
Windows 7
Windows Server 2008
Windows Vista
Hosts da Internet
Sistemas Apple Macintosh
Mainframes IBM
sistemas UNIX e Linux
Sistemas VMS abertos
Impressoras prontas para rede
Tablets e telefones celulares com ethernet com fio ou tecnologia 802.11 sem fio
habilitada
Planejar implantação de DHCP

A seguir estão as principais etapas de planejamento antes de instalar a função de
servidor DHCP.
Planejando os servidores DHCP e o encaminhamento

DHCP
Como as mensagens DHCP são mensagens de difusão, elas não são encaminhadas
entre as sub-redes por roteadores. Se você tiver várias sub-redes e desejar fornecer o
serviço DHCP em cada sub-rede, deverá fazer o seguinte:
Instalar um servidor DHCP em cada sub-rede

Configurar roteadores para encaminhar as mensagens de difusão DHCP entre sub-
redes e configurar vários escopos no servidor DHCP, um escopo por sub-rede.
Na maioria dos casos, a configuração de roteadores para encaminhar mensagens de

difusão DHCP é mais econômica que a implantação de um servidor DHCP em cada
segmento físico da rede.
Planejando intervalos de endereços IP

Cada sub-rede deve ter seu próprio intervalo de endereços IP exclusivo. Esses intervalos
são representados em um servidor DHCP com escopos.
Um escopo é um agrupamento administrativo de endereços IP para computadores em

uma sub-rede que usa o serviço DHCP. O administrador primeiro cria um escopo para
cada sub-rede física e, em seguida, usa o escopo para definir os parâmetros usados
pelos clientes.
Um escopo tem as seguintes propriedades:
Um intervalo de endereços IP do qual incluir ou excluir endereços usados para

ofertas de concessão de serviço DHCP.
Uma máscara de sub-rede, que determina o prefixo de sub-rede para um

determinado endereço IP.
Um nome de escopo atribuído quando é criado.
Valores de duração da concessão, que são atribuídos aos clientes DHCP que
recebem endereços IP alocados dinamicamente.
Qualquer opção de escopo DHCP configurada para atribuição a clientes DHCP,

como endereço ID do servidor DNS ou endereço IP do gateway do
roteador/padrão.
As reservas são opcionalmente usadas para garantir que um cliente DHCP sempre
receba o mesmo endereço IP.
Antes de implantar os servidores, liste suas sub-redes e o intervalo de endereços IP que

você deseja usar para cada sub-rede.
Planejando máscaras de sub-rede

As IDs de rede e IDs de host são diferenciadas usando uma máscara de sub-rede. Cada
máscara de sub-rede é um número de 32 bits que usa grupos de bits consecutivos de
todos (1) para identificar a ID da rede e todos os zeros (0) para identificar as partes de
ID do host de um endereço IP.
Por exemplo, a máscara de sub-rede normalmente usada com o endereço IP

131.107.16.200 é o seguinte número binário de 32 bits:
11111111 11111111 00000000 00000000
Esse número de máscara de sub-rede são 16 bits de um seguidos de 16 bits de zero,

indicando que as seções de ID da rede e as seções de ID do host desse endereço IP têm
16 bits de comprimento. Normalmente, essa máscara de sub-rede é exibida em notação
decimal com ponto como 255.255.0.0.
A tabela a seguir exibe as máscaras de sub-rede para as classes de endereço de Internet.
Classe de endereço Bits para máscara de sub-rede Máscara de sub-rede
Classe A 11111111 00000000 00000000 00000000 255.0.0.0
Classe B 11111111 11111111 00000000 00000000 255.255.0.0
Classe C 11111111 11111111 11111111 00000000 255.255.255.0
Quando você cria um escopo no DHCP e insere o intervalo de endereços IP do escopo,

o DHCP fornece esses valores de máscara de sub-rede padrão. Normalmente, os valores
de máscara de sub-rede padrão são aceitáveis para a maioria das redes sem requisitos
especiais e onde cada segmento de rede IP corresponde a uma única rede física.
Em alguns casos, você pode usar máscaras de sub-rede personalizadas para

implementar a criação de sub-redes IP. Com a criação de sub-redes IP, você pode
subdividir a parte padrão de ID de host de um endereço IP para especificar sub-redes,
que são subdivisões de ID de rede baseada na classe original.
Personalizando o comprimento da máscara de sub-rede, você pode reduzir o número

de bits que são usados para o ID de host real.
Para evitar a solução e o roteamento de problemas, verifique se todos os computadores

TCP/IP em um segmento de rede usam a mesma máscara de sub-rede e se cada
computador ou dispositivo tem um endereço IP exclusivo.
Planejando intervalos de exclusão

Quando você cria um escopo em um servidor DHCP, pode especificar um intervalo de
endereços IP que inclui todos os endereços IP que o servidor DHCP pode conceder aos
clientes DHCP, como computadores e outros dispositivos. Se você acessar e configurar
manualmente alguns servidores e outros dispositivos com endereços IP estáticos do
mesmo intervalo de endereços IP usado pelo servidor DHCP, poderá criar
acidentalmente um conflito de endereços IP, onde você e o servidor DHCP atribuem o
mesmo endereço IP a dispositivos diferentes.
Para resolver esse problema, você pode criar um intervalo de exclusão para o escopo
DHCP. Um intervalo de exclusão é um intervalo contíguo de endereços IP dentro do
intervalo de endereços IP do escopo que o servidor DHCP não tem permissão para usar.
Se você criar um intervalo de exclusão, o servidor DHCP não atribuirá os endereços
nesse intervalo, permitindo que você atribua manualmente esses endereços sem criar
um conflito de endereços IP.
Você pode excluir endereços IP da distribuição pelo servidor DHCP, criando um intervalo
de exclusão para cada escopo. Use as exclusões para todos os dispositivos configurados
com um endereço IP estático. Os endereços excluídos devem incluir todos os endereços
IP que você atribuiu manualmente a outros servidores, clientes não-DHCP, estações de
trabalho sem disco ou clientes de Roteamento, Acesso Remoto e PPP.
Recomendamos que você configure o intervalo de exclusão com endereços extras para
acomodar o crescimento futuro da rede. A tabela a seguir fornece um intervalo de
exclusão de exemplo para um escopo com um intervalo de endereços IP 10.0.0.1 a
10.0.0.254 e uma máscara de sub-rede de 255.255.255.0.
Endereço IP Inicial do intervalo de exclusão 10.0.0.1
Endereço IP Final do intervalo de exclusão 10.0.0.25
Planejando a configuração estática do TCP/IP

Certos dispositivos, como roteadores, servidores DHCP e servidores DNS, devem ser
configurados com um endereço IP estático. Além disso, você pode ter dispositivos
adicionais, como impressoras, onde deve garantir sempre o mesmo endereço IP. Liste os
dispositivos que você deseja configurar estaticamente para cada sub-rede e planeje o
intervalo de exclusão que deseja usar no servidor DHCP para garantir que o servidor
DHCP não conceda o endereço IP de um dispositivo configurado estaticamente. Um
intervalo de exclusão é uma sequência limitada de endereços IP dentro de um escopo,
excluído das ofertas de serviço DHCP. Os intervalos de exclusão garantem que os
endereços nesses intervalos não sejam oferecidos pelo servidor a clientes DHCP na sua
rede.
Por exemplo, se o intervalo de endereços IP de uma sub-rede for 192.168.0.1 a

192.168.0.254 e você tiver dez dispositivos que deseja configurar com um endereço IP
estático, poderá criar um intervalo de exclusão para o escopo 192.168.0.x que inclui dez
ou mais endereços IP: 192.168.0.1 a 192.168.0.15.
Neste exemplo, você usa dez dos endereços IP excluídos para configurar servidores e
outros dispositivos com endereços IP estáticos e cinco endereços IP adicionais ficam
disponíveis para uma configuração estática de novos dispositivos que você possa
desejar adicionar no futuro. Com este intervalo de exclusão, o servidor DHCP fica com
um pool de endereços de 192.168.0.16 até 192.168.0.254.
Itens de configuração de exemplo adicionais para o AD DS e o DNS são fornecidos na

tabela a seguir.
Ligações de Conexão de Rede Ethernet
Configurações do servidor DNS DC1.corp.contoso.com
Valores de escopo 1. Sub-rede primária
1. Nome do escopo
2. 10.0.0.1
2. Endereço IP inicial
3. 10.0.0.254
3. Endereço IP final
4. 255.255.255.0
4. Máscara de Sub-rede
5. 10.0.0.1
5. Gateway padrão (opcional)

6. 8 dias
6. Duração da concessão
Modo de Operação do Servidor DHCP IPv6 não ativado
Usando este guia em um laboratório de teste

Você pode usar este guia para implantar o DHCP em um laboratório de teste antes de
implantar em um ambiente de produção.
７ Observação
Se você não quiser implantar o DHCP em um laboratório de teste, pode pular para
a seção Implantar DHCP.
Os requisitos para seu laboratório diferem dependendo se você está usando servidores
físicos ou VMs (máquinas virtuais) e se você está usando um domínio do Active
Directory ou implantando um servidor DHCP autônomo.
Você pode usar as informações a seguir para determinar os recursos mínimos

necessários para testar a implantação de DHCP usando este guia.
Testar requisitos do Laboratório com VMs

Para implantar o DHCP em um laboratório de teste com VMs, você precisa dos recursos
a seguir.
Para implantação de domínio ou implantação autônoma, você precisa de um servidor

configurado como um host Hyper-V.
Implantação de domínio
Essa implantação requer um servidor físico, um comutador virtual, dois servidores

virtuais e um cliente virtual:
No servidor físico, no Gerenciador do Hyper-V, crie os seguintes itens.
1. Um comutador virtual interno . Não crie um comutador virtual externo , pois se o

host Hyper-V estiver em uma sub-rede que inclua um servidor DHCP, suas VMs de
teste receberão um endereço IP do servidor DHCP. Além disso, o servidor DHCP de
teste que você implanta pode atribuir endereços IP a outros computadores na
sub-rede em que o host Hyper-V está instalado.
2. Uma VM em execução Windows Server 2016 configurada como um controlador de
domínio com Active Directory Domain Services que está conectado ao comutador
virtual interno criado. Para corresponder a este guia, este servidor deve ter um
endereço IP configurado estaticamente de 10.0.0.2. Para obter informações sobre
como implantar o AD DS, consulte a seção Implantando DC1 no Guia de Rede do
3. Uma VM em execução Windows Server 2016 que você configurará como um
servidor DHCP usando este guia e que está conectada ao comutador virtual
interno criado.
4. Uma VM executando um sistema operacional cliente Windows conectado ao
comutador virtual interno criado e que você usará para verificar se o servidor
DHCP está alocando dinamicamente endereços IP e opções DHCP para clientes
DHCP.
Implantação autônoma do servidor DHCP

Essa implantação requer um servidor físico, um comutador virtual, um servidor virtual e
um cliente virtual:
No servidor físico, no Gerenciador do Hyper-V, crie os seguintes itens.
1. Um comutador virtual interno . Não crie um comutador virtual externo , pois se o

host Hyper-V estiver em uma sub-rede que inclua um servidor DHCP, suas VMs de
teste receberão um endereço IP do servidor DHCP. Além disso, o servidor DHCP de
teste que você implanta pode atribuir endereços IP a outros computadores na
sub-rede em que o host Hyper-V está instalado.
2. Uma VM em execução Windows Server 2016 que você configurará como um
servidor DHCP usando este guia e que está conectada ao comutador virtual
interno criado.
3. Uma VM executando um sistema operacional cliente Windows conectado ao
comutador virtual interno criado e que você usará para verificar se o servidor
DHCP está alocando dinamicamente endereços IP e opções DHCP para clientes
DHCP.
Testar os requisitos do Laboratório com servidores físicos

Para implantar o DHCP em um laboratório de teste com servidores físicos, você precisa
dos recursos a seguir.
Implantação de domínio
Essa implantação requer um hub ou comutador, dois servidores físicos e um cliente

físico:
1. Um hub Ethernet ou alternar para o qual você pode conectar os computadores

físicos com cabos Ethernet
2. Um computador físico em execução Windows Server 2016 configurado como um
controlador de domínio com Active Directory Domain Services. Para corresponder
a este guia, este servidor deve ter um endereço IP configurado estaticamente de
10.0.0.2. Para obter informações sobre como implantar o AD DS, consulte a seção
Implantando DC1 no Guia de Rede do Windows Server 2016 Core.
3. Um computador físico executando Windows Server 2016 que você configurará
como um servidor DHCP usando este guia.
4. Um computador físico executando um sistema operacional cliente Windows que
você usará para verificar se o servidor DHCP está alocando dinamicamente
endereços IP e opções DHCP para clientes DHCP.
７ Observação
Se você não tiver computadores de teste suficientes para essa implantação, poderá
usar um computador de teste para AD DS e DHCP , no entanto, essa configuração
não é recomendada para um ambiente de produção.
Implantação autônoma do servidor DHCP
Essa implantação requer um hub ou comutador, um servidor físico e um cliente físico:
1. Um hub Ethernet ou alternar para o qual você pode conectar os computadores

físicos com cabos Ethernet
2. Um computador físico executando Windows Server 2016 que você configurará
como um servidor DHCP usando este guia.
3. Um computador físico que executa um sistema operacional cliente Windows que
você usará para verificar se o servidor DHCP está alocando dinamicamente
endereços IP e opções DHCP para clientes DHCP.
Implantar DHCP
Esta seção fornece comandos de Windows PowerShell de exemplo que você pode usar
para implantar o DHCP em um servidor. Antes de executar esses comandos de exemplo
no servidor, você deve modificar os comandos para corresponder à rede e ao ambiente.
Por exemplo, antes de executar os comandos, você deve substituir valores de exemplo
nos comandos para os seguintes itens:
Nomes de computadores
Intervalo de endereços IP para cada escopo que você deseja configurar (1 escopo
por sub-rede)
Máscara de sub-rede para cada intervalo de endereços IP que você deseja
configurar
Nome do escopo para cada escopo
Intervalo de exclusão para cada escopo
Valores de opção DHCP, como gateway padrão, nome de domínio e servidores
DNS ou WINS
Nomes de interface
） Importante
Examine e modifique cada comando para seu ambiente antes de executar o

comando.
Onde instalar o DHCP – em um computador físico ou em
uma VM?
Você pode instalar a função de servidor DHCP em um computador físico ou em uma VM
(máquina virtual) instalada em um host Hyper-V. Se você estiver instalando o DHCP em
uma VM e quiser que o servidor DHCP forneça atribuições de endereço IP para
computadores na rede física à qual o host Hyper-V está conectado, você deve conectar
o adaptador de rede virtual da VM a um Comutador Virtual Hyper-V que seja Externo.
Para obter mais informações, consulte a seção Criar um Comutador Virtual com o
Gerenciador do Hyper-V no tópico Criar uma rede virtual.
Executar Windows PowerShell como administrador

Você pode usar o procedimento a seguir para executar Windows PowerShell com
privilégios de Administrador.
1. Em um computador executando Windows Server 2016, clique em Iniciar e clique

com o botão direito do mouse no ícone Windows PowerShell. Um menu é exibido.
2. No menu, clique em Mais e clique em Executar como administrador. Se solicitado,

digite as credenciais de uma conta que tenha privilégios de administrador no
computador. Se a conta de usuário com a qual você está conectado ao
computador for uma conta de nível administrador, você não receberá um prompt
de credencial.
3. Windows PowerShell abre com privilégios de Administrador.
Renomear o servidor DHCP e configurar um endereço IP

estático
Se você ainda não fez isso, poderá usar os comandos Windows PowerShell a seguir para
renomear o servidor DHCP e configurar um endereço IP estático para o servidor.
Você pode usar os comandos a seguir para atribuir um endereço IP estático ao servidor
DHCP e configurar as propriedades TCP/IP do servidor DHCP com o endereço IP correto
do servidor DNS. Você também deve substituir os nomes de interface e os endereços IP
neste exemplo pelos valores que deseja usar para configurar o seu computador.

10.0.0.2
Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
New-NetIPAddress
Set-DnsClientServerAddress
Você pode usar os comandos a seguir para renomear e reiniciar o computador.
Rename-Computer -Name DHCP1
Restart-Computer
Rename-Computer
Restart-Computer
Ingressar o computador no domínio (opcional)

Se você estiver instalando seu servidor DHCP em um ambiente de domínio do Active
Directory, deverá ingressar o computador no domínio. Abra Windows PowerShell com
privilégios de Administrador e execute o comando a seguir depois de substituir o nome
CORP do NetBios do domínio por um valor apropriado para seu ambiente.
Add-Computer CORP
Quando solicitado, digite as credenciais de uma conta de usuário de domínio que tenha
permissão para ingressar um computador no domínio.
Restart-Computer
Para obter mais informações sobre o comando Add-Computer, consulte o tópico a

seguir.
Add-Computer
Instalar o DHCP
Depois que o computador for reiniciado, abra Windows PowerShell com privilégios de
Administrador e instale o DHCP executando o comando a seguir.
Para obter mais informações sobre esse comando, consulte o tópico a seguir.
Criar grupos de segurança DHCP

Para criar grupos de segurança, você deve executar um comando netsh (Network Shell)
no Windows PowerShell e reiniciar o serviço DHCP para que os novos grupos se tornem
ativos.
Quando você executa o comando netsh a seguir no servidor DHCP, os administradores

dhcp e grupos de segurança de usuários DHCP são criados em usuários e grupos
locais no servidor DHCP.
netsh dhcp add securitygroups
O comando a seguir reinicia o serviço DHCP no computador local.
Restart-Service dhcpserver

Restart-Service
Autorizar o servidor DHCP no Active Directory (opcional)

Se você estiver instalando o DHCP em um ambiente de domínio, deverá executar as
etapas a seguir para autorizar o servidor DHCP a operar no domínio.
７ Observação
Servidores DHCP não autorizados instalados em domínios do Active Directory não

podem funcionar corretamente e não concedem endereços IP a clientes DHCP. A
desabilitação automática de servidores DHCP não autorizados é um recurso de
segurança que impede que servidores DHCP não autorizados atribuam endereços
IP incorretos a clientes em sua rede.
Você pode usar o comando a seguir para adicionar o servidor DHCP à lista de servidores
DHCP autorizados no Active Directory.
７ Observação
Se você não tiver um ambiente de domínio, não execute este comando.
Add-DhcpServerInDC -DnsName DHCP1.corp.contoso.com -IPAddress 10.0.0.3
Para verificar se o servidor DHCP está autorizado no Active Directory, você pode usar o
comando a seguir.
Get-DhcpServerInDC
A seguir estão os resultados de exemplo exibidos em Windows PowerShell.
IPAddress DnsName
--------- -------
10.0.0.3 DHCP1.corp.contoso.com
Add-DhcpServerInDC
Get-DhcpServerInDC
Notifique Gerenciador do Servidor que a configuração de
DHCP pós-instalação está concluída (opcional)
Depois de concluir tarefas pós-instalação, como criar grupos de segurança e autorizar o
servidor DHCP no Active Directory, Gerenciador do Servidor ainda poderá exibir um
alerta na interface do usuário informando que as etapas pós-instalação devem ser
concluídas usando o assistente de Configuração de Pós-Instalação DHCP.
Você pode impedir que essa mensagem agora desnecessária e imprecisa apareça em
Gerenciador do Servidor configurando a seguinte chave do Registro usando este
comando Windows PowerShell.
Set-ItemProperty –Path
registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\Roles\12 –Name
ConfigurationState –Value 2
Para obter mais informações sobre esse comando, consulte o tópico a seguir.
Set-ItemProperty
Definir configurações de configuração de atualização

dinâmica DNS no nível do servidor (opcional)
Se você quiser que o servidor DHCP execute atualizações dinâmicas de DNS para
computadores cliente DHCP, execute o comando a seguir para definir essa
configuração. Essa é uma configuração de nível de servidor, não uma configuração de
nível de escopo, portanto, afetará todos os escopos que você configura no servidor. Este
comando de exemplo também configura o servidor DHCP para excluir registros de
recursos DNS para clientes quando o cliente menos expirar.
Set-DhcpServerv4DnsSetting -ComputerName "DHCP1.corp.contoso.com" -

DynamicUpdates "Always" -DeleteDnsRRonLeaseExpiry $True
Você pode usar o comando a seguir para configurar as credenciais que o servidor DHCP
usa para registrar ou cancelar o registro de registros de cliente em um servidor DNS.
Este exemplo salva uma credencial em um servidor DHCP. O primeiro comando usa Get-
Credential para criar um objeto PSCredential e armazena o objeto na variável
$Credential . O comando solicita o nome de usuário e a senha, portanto, certifique-se
de fornecer credenciais para uma conta que tenha permissão para atualizar registros de
recursos no servidor DNS.
$Credential = Get-Credential
Set-DhcpServerDnsCredential -Credential $Credential -ComputerName

"DHCP1.corp.contoso.com"
Set-DhcpServerv4DnsSetting
Set-DhcpServerDnsCredential
Configurar o escopo corpnet

Depois que a instalação do DHCP for concluída, você poderá usar os comandos a seguir
para configurar e ativar o escopo corpnet, criar um intervalo de exclusão para o escopo
e configurar o gateway padrão de opções DHCP, o endereço IP do servidor DNS e o
nome de domínio DNS.


EndRange 10.0.0.15

Add-DhcpServerv4Scope
Add-DhcpServerv4ExclusionRange
Set-DhcpServerv4OptionValue
Configurar o escopo corpnet2 (opcional)

Se você tiver uma segunda sub-rede conectada à primeira sub-rede com um roteador
em que o encaminhamento DHCP está habilitado, você poderá usar os comandos a
seguir para adicionar um segundo escopo, chamado Corpnet2 para este exemplo. Este
exemplo também configura um intervalo de exclusão e o endereço IP para o gateway
padrão (o endereço IP do roteador na sub-rede) da sub-rede Corpnet2.

EndRange 10.0.1.15

Se você tiver sub-redes adicionais que são atendidas por esse servidor DHCP, poderá
repetir esses comandos, usando valores diferentes para todos os parâmetros de
comando, para adicionar escopos para cada sub-rede.
） Importante
Verifique se todos os roteadores entre seus clientes DHCP e seu servidor DHCP
estão configurados para encaminhamento de mensagens DHCP. Consulte a
documentação do roteador para obter informações sobre como configurar o
encaminhamento DHCP.
Verificar a funcionalidade do servidor

Para verificar se o servidor DHCP está fornecendo alocação dinâmica de endereços IP
para clientes DHCP, você pode conectar outro computador a uma sub-rede atendida.
Depois de conectar o cabo Ethernet ao adaptador de rede e à energia no computador,
ele solicitará um endereço IP do servidor DHCP. Você pode verificar a configuração
bem-sucedida usando o comando ipconfig /all e revisando os resultados ou
executando testes de conectividade, como tentar acessar recursos da Web com seu
navegador ou compartilhamentos de arquivos com Windows Explorer ou outros
aplicativos.
Se o cliente não receber um endereço IP do servidor DHCP, execute as seguintes etapas

de solução de problemas.
1. Verifique se o cabo Ethernet está conectado ao computador e ao comutador, hub

ou roteador Ethernet.
2. Se você conectou o computador cliente a um segmento de rede separado do
servidor DHCP por um roteador, verifique se o roteador está configurado para
encaminhar mensagens DHCP.
3. Verifique se o servidor DHCP está autorizado no Active Directory executando o
comando a seguir para recuperar a lista de servidores DHCP autorizados do Active
Directory. Get-DhcpServerInDC.
4. Verifique se os escopos são ativados abrindo o console DHCP (Gerenciador do
Servidor, Ferramentas, DHCP), expandindo a árvore do servidor para examinar
escopos e clicando com o botão direito do mouse em cada escopo. Se o menu
resultante incluir a seleção Ativar, clique em Ativar. (Se o escopo já estiver ativado,
a seleção de menu lerá Deactivate.)
Comandos Windows PowerShell para DHCP

A referência a seguir fornece descrições de comando e sintaxe para todos os comandos
do servidor DHCP Windows PowerShell para Windows Server 2016. O tópico lista
comandos em ordem alfabética com base no verbo no início dos comandos, como Get
ou Set.
７ Observação
Você não pode usar comandos Windows Server 2016 no Windows Server 2012 R2.
Módulo DhcpServer
A referência a seguir fornece descrições de comando e sintaxe para todos os comandos

do servidor DHCP Windows PowerShell para Windows Server 2012 R2. O tópico lista
comandos em ordem alfabética com base no verbo no início dos comandos, como Get
ou Set.
７ Observação
Você pode usar Windows Server 2012 comandos R2 em Windows Server 2016.
Cmdlets do servidor DHCP no Windows PowerShell
Lista de comandos de Windows PowerShell

neste guia
Veja a seguir uma lista simples de comandos e valores de exemplo usados neste guia.


10.0.0.2
Rename-Computer -Name DHCP1
Restart-Computer
Add-Computer CORP
Restart-Computer
netsh dhcp add securitygroups
Restart-Service dhcpserver
Add-DhcpServerInDC -DnsName DHCP1.corp.contoso.com -IPAddress 10.0.0.3
Get-DhcpServerInDC
Set-ItemProperty –Path
registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager\Roles\12 –Name
ConfigurationState –Value 2
Set-DhcpServerv4DnsSetting -ComputerName "DHCP1.corp.contoso.com" -

DynamicUpdates "Always" -DeleteDnsRRonLeaseExpiry $True
Set-DhcpServerDnsCredential -Credential $Credential -ComputerName

"DHCP1.corp.contoso.com"
rem At prompt, supply credential in form DOMAIN\user, password
rem Configure scope Corpnet


EndRange 10.0.0.15

rem Configure scope Corpnet2


EndRange 10.0.1.15

Guia de solução de problemas do

PROTOCOLO DHCP
Para que qualquer dispositivo (como um computador ou telefone) possa operar em

uma rede, ele deve receber um endereço IP. Você pode atribuir um endereço IP manual
ou automaticamente. A atribuição automática é tratada pelo serviço DHCP (Microsoft ou
servidor de terceiros).
Neste artigo, discutiremos as etapas gerais de solução de problemas para o Microsoft

cliente e servidor DHCP IPv4.
Mais informações
O procedimento para atribuição de endereço IPv4 geralmente envolve três
componentes principais:
Um dispositivo cliente DHCP que precisa obter um endereço IP
Um serviço DHCP que fornece endereços IP para o cliente com base em

configurações específicas
Um agente de retransmissão DHCP /Auxiliar de IP para enviar solicitações de

difusão DHCP para um segmento de rede diferente
Uma comunicação de cliente para servidor DHCP consiste em três tipos de interação
entre os dois pares:
DORA baseado em difusão (Descobrir, Oferta, Solicitação, Confirmação). O

processo é composto pelas seguintes etapas:
O cliente DHCP envia uma solicitação de difusão dhcp discover para todos os
servidores DHCP disponíveis dentro do intervalo.
Uma resposta de difusão da oferta DHCP é recebida do servidor DHCP,

oferecendo uma concessão de endereço IP disponível.
A Solicitação de difusão do cliente DHCP solicita a concessão de endereço IP

oferecida e a Confirmação de difusão DHCP no final.
Se o cliente e o servidor DHCP estiverem localizados em diferentes segmentos

de rede lógica, um agente de retransmissão DHCP atuará como um
encaminhador, enviando os pacotes de difusão DHCP entre pares.
Solicitações de renovação DHCP Unicast: elas são enviadas diretamente ao

servidor DHCP do cliente DHCP para renovar a atribuição de endereço IP após 50%
do tempo de concessão do endereço IP.
Reassociar solicitações de difusão DHCP: elas são feitas a qualquer servidor

DHCP dentro do intervalo do cliente. Eles são enviados após 87,5% da duração da
concessão de endereço IP porque isso indica que a solicitação unicast direcionada
não funcionou. Quanto ao processo do DORA, esse processo envolve uma
comunicação do agente de retransmissão DHCP.
Se um Microsoft cliente DHCP não receber um endereço DHCP IPv4 válido, o cliente
provavelmente estará configurado para usar um endereço APIPA. Para obter mais
informações, consulte o seguinte artigo da Base de Dados de Conhecimento: 220874
Como usar o endereçamento TCP/IP automático sem um servidor DHCP
Toda a comunicação é feita nas portas UDP 67 e 68. Para obter mais informações,
consulte o seguinte artigo da Base de Dados de Conhecimento: 169289 noções
básicas do DHCP (Dynamic Host Configuration Protocol).
Noções básicas do DHCP (Dynamic Host
Configuration Protocol)
O protocolo DHCP é um protocolo padrão definido pelo RFC 1541 (que é superado pelo
RFC 2131) que permite que um servidor distribua dinamicamente informações de
endereçamento IP e configuração para clientes. Normalmente, o servidor DHCP fornece
ao cliente pelo menos essas informações básicas:
Endereço IP
Máscara de Sub-rede
Gateway Padrão Outras informações também podem ser fornecidas, como

endereços de servidor DNS (Serviço de Nome de Domínio) e endereços de
servidor WINS (Serviço de Nomes Windows Internet). O administrador do sistema
configura o servidor DHCP com as opções que são analisados para o cliente.
Mais informações
Os seguintes produtos da Microsoft fornecem a funcionalidade do cliente DHCP:
Windows NT Server versões 3.5, 3.51 e 4.0
Windows NT Workstation versões 3.5, 3.51 e 4.0
Windows 95
Microsoft Network Client versão 3.0 para MS-DOS
Microsoft LAN Manager Client versão 2.2c para MS-DOS
Microsoft TCP/IP-32 para Windows para Grupos de Trabalho versões 3.11, 3.11a e
3.11b
Clientes DHCP diferentes são suportados por diferentes opções que podem receber do
servidor DHCP.
Os seguintes sistemas operacionais do servidor Microsoft fornecem a funcionalidade do

servidor DHCP:
Windows NT Server versão 3.5

Quando um cliente é inicializado pela primeira vez depois de configurado para receber
informações de DHCP, ele inicia uma conversa com o servidor.
Veja abaixo uma tabela de resumo da conversa entre o cliente e o servidor, que é
seguida por uma descrição no nível do pacote do processo:
Source Dest Source Dest Packet
MAC addr MAC addr IP addr IP addr Description
-----------------------------------------------------------------
Client Broadcast 0.0.0.0 255.255.255.255 DHCP Discover
DHCPsrvr Broadcast DHCPsrvr 255.255.255.255 DHCP Offer
Client Broadcast 0.0.0.0 255.255.255.255 DHCP Request
DHCPsrvr Broadcast DHCPsrvr 255.255.255.255 DHCP ACK
A conversa detalhada entre o cliente DHCP e o servidor DHCP é a seguinte:
DHCPDISCOVER
O cliente envia um pacote DHCPDISCOVER. Veja a seguir um trecho de uma captura de
monitor de rede mostrando as partes IP e DHCP de um pacote DHCPDISCOVER. Na
seção IP, você pode ver que o Endereço de destino é 255.255.255.255 e o endereço de
origem é 0.0.0.0. A seção DHCP identifica o pacote como um pacote Discover e
identifica o cliente em dois locais usando o endereço físico da placa de rede. Observe
que os valores no campo LTDDR e no campo DHCP: Identificador de Cliente são
idênticos.
IP: ID = 0x0; Proto = UDP; Len: 328
IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput

IP: .....0.. = Normal Reliability
IP: Total Length = 328 (0x148)
IP: Identification = 0 (0x0)
IP: Flags Summary = 0 (0x0)
IP: .......0 = Last fragment in datagram
IP: ......0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x39A6
IP: Source Address = 0.0.0.0
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)
DHCP: Discover (xid=21274A1D)
DHCP: Op Code (op) = 1 (0x1)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 556223005 (0x21274A1D)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = 0.0.0.0
DHCP: Your IP Address (yiaddr) = 0.0.0.0
DHCP: Server IP Address (siaddr) = 0.0.0.0
DHCP: Relay IP Address (giaddr) = 0.0.0.0
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Discover
DHCP: Client-identifier = (Type: 1) 08 00 2b 2e d8 5e
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field
DHCPOFFER
O servidor DHCP responde enviando um pacote DHCPOFFER. Na seção IP do trecho de
captura abaixo, o Endereço de origem agora é o endereço IP do servidor DHCP e o
Endereço de destino é o endereço de difusão 255.255.255.255.255. A seção DHCP
identifica o pacote como uma Oferta. O campo LTDADDR é preenchido com o endereço
IP que o servidor está oferecendo ao cliente. Observe que o campo LTDDR ainda
contém o endereço físico do cliente solicitante. Além disso, vemos na seção Campo de
Opção DHCP as várias opções que estão sendo enviadas pelo servidor junto com o
endereço IP. Nesse caso, o servidor está enviando a Máscara de Sub-rede, o Gateway
Padrão (Roteador), o Tempo de Concessão, o endereço do servidor WINS (Serviço de
Nome NetBIOS) e o Tipo de Nó NetBIOS.
IP: ID = 0x3C30; Proto = UDP; Len: 328

IP: Identification = 15408 (0x3C30)
IP: Checksum = 0x2FA8
DHCP: Offer (xid=21274A1D)
DHCP: DHCP Message Type = DHCP Offer
DHCP: Subnet Mask = 255.255.240.0
DHCP: Renewal Time Value (T1) = 8 Days, 0:00:00
DHCP: Rebinding Time Value (T2) = 14 Days, 0:00:00
DHCP: IP Address Lease Time = 16 Days, 0:00:00
DHCP: Server Identifier = 157.54.48.151
DHCP: Router = 157.54.48.1
DHCP: NetBIOS Name Service = 157.54.16.154
DHCP: NetBIOS Node Type = (Length: 1) 04
DHCPREQUEST
O cliente responde ao DHCPOFFER enviando um DHCPREQUEST. Na seção IP da
captura abaixo, o endereço de origem do cliente ainda é 0.0.0.0 e o Destino do pacote
ainda é 255.255.255.255.255. O cliente retém 0.0.0.0 porque o cliente não recebeu a
verificação do servidor de que não há problema em começar a usar o endereço
oferecido. O Destino ainda é transmitido, porque mais de um servidor DHCP pode ter
respondido e estar mantendo uma reserva para uma Oferta feita ao cliente. Isso permite
que esses outros servidores DHCP saibam que podem liberar seus endereços oferecidos
e devolvê-los aos pools disponíveis. A seção DHCP identifica o pacote como uma
Solicitação e verifica o endereço oferecido usando o campo DHCP: Endereço Solicitado.
O campo DHCP: Identificador de Servidor mostra o endereço IP do servidor DHCP que
oferece a concessão.


DHCP: Request (xid=21274A1D)
DHCP: DHCP Message Type = DHCP Request
DHCP: Requested Address = 157.54.50.5
DHCPACK
O servidor DHCP responde ao DHCPREQUEST com um DHCPACK, concluindo assim o
ciclo de inicialização. O endereço de origem é o endereço IP do servidor DHCP e o
Endereço de destino ainda é 255.255.255.255. O campo LTDADDR contém o endereço
do cliente e os campos DEDDD e DHCP: Identificador do Cliente são o endereço físico
da placa de rede no cliente solicitante. A seção Opção DHCP identifica o pacote como
um ACK.
IP: ID = 0x3D30; Proto = UDP; Len: 328

IP: Identification = 15664 (0x3D30)
IP: Checksum = 0x2EA8
DHCP: ACK (xid=21274A1D)
DHCP: DHCP Message Type = DHCP ACK
DHCP: Renewal Time Value (T1) = 8 Days, 0:00:00
DHCP: Rebinding Time Value (T2) = 14 Days, 0:00:00
DHCP: IP Address Lease Time = 16 Days, 0:00:00
DHCP: Subnet Mask = 255.255.240.0
DHCP: Router = 157.54.48.1
DHCP: NetBIOS Name Service = 157.54.16.154
DHCP: NetBIOS Node Type = (Length: 1) 04
Se o cliente tiver anteriormente um endereço IP atribuído a DHCP e ele for reiniciado, o

cliente solicitará especificamente o endereço IP arrendado anteriormente em um pacote
DHCPREQUEST especial. O endereço de origem é 0.0.0.0 e o Destino é o endereço de
difusão 255.255.255.255. Os clientes da Microsoft preencherão o DHCP Campo de
Opção DHCP: Endereço Solicitado com o endereço atribuído anteriormente. Os clientes
estritamente compatíveis com RFC preencherão o campo CIADDR com o endereço
solicitado. O servidor DHCP da Microsoft aceitará qualquer um deles.

DHCP: Request (xid=2757554E)
DHCP: Transaction ID (xid) = 660034894 (0x2757554E)
DHCP: DHCP Message Type = DHCP Request
Neste ponto, o servidor pode ou não responder. O comportamento do Windows NT

servidor DHCP depende da versão do sistema operacional que está sendo usada, bem
como de outros fatores, como a supercopiação. Se o servidor determinar que o cliente
ainda pode usar o endereço, ele permanecerá silencioso ou ACK o DHCPREQUEST. Se o
servidor determinar que o cliente não pode ter o endereço, ele enviará um NACK.
IP: ID = 0x3F1A; Proto = UDP; Len: 328

IP: Identification = 16154 (0x3F1A)
IP: Checksum = 0x2CBE
DHCP: NACK (xid=74A005CE)
DHCP: Transaction ID (xid) = 1956644302 (0x74A005CE)
DHCP: DHCP Message Type = DHCP NACK
Em seguida, o cliente iniciará o processo de descoberta, mas o pacote DHCPDISCOVER

ainda tentará concessão do mesmo endereço. Em muitas instâncias, o cliente obterá o
mesmo endereço, mas talvez não.


DHCP: Discover (xid=3ED14752)
DHCP: Transaction ID (xid) = 1053902674 (0x3ED14752)
DHCP: DHCP Message Type = DHCP Discover
As informações de DHCP obtidas pelo cliente de um servidor DHCP terão um tempo de

concessão associado a ele. O tempo de concessão define por quanto tempo o cliente
pode usar as informações atribuídas ao DHCP. Quando a concessão atingir
determinados marcos, o cliente tentará renovar suas informações de DHCP.
Para exibir informações de IP em um Windows ou Windows para workgroups, use o

utilitário IPCONFIG. Se o cliente for Windows 95, use WINIPCFG.
Referências
Para obter mais informações sobre o DHCP, consulte RFC1541 e RFC2131. RfCs podem
ser obtidos por meio da Internet em vários sites, por exemplo: http://www.rfc-
editor.org/ e http://www.tech-nic.qc.ca/
Diretrizes gerais para solucionar
problemas do DHCP
Antes de começar a solucionar problemas, verifique os itens a seguir. Eles podem ajudá-
lo a encontrar a causa raiz do problema.
Lista de verificação
Quando começou o problema?
Há mensagens de erro?
O servidor DHCP estava funcionando anteriormente ou nunca funcionou?

Se
funcionou anteriormente, qualquer coisa mudou antes do início do problema. Por
exemplo, uma atualização foi instalada? Foi feita uma alteração na infraestrutura?
O problema é persistente ou intermitente? Se for intermitente, quando ela ocorreu

pela última vez?
As falhas de concessão de endereço estão ocorrendo para todos os clientes ou

apenas para clientes específicos, como uma sub-rede de escopo único?
Há clientes na mesma sub-rede de rede que o servidor DHCP?
Se os clientes residiem na mesma sub-rede de rede, eles podem obter endereços

IP?
Se os clientes não estão na mesma sub-rede de rede, os roteadores ou

comutadores VLAN estão configurados corretamente para ter agentes de
retransmissão DHCP (também conhecidos como Auxiliares de IP)?
O servidor DHCP é autônomo ou está configurado para alta disponibilidade, como

escopo dividido ou failover de DHCP?
Verifique os dispositivos intermediários em busca de recursos como VRRP/HSRP,

Inspeção dinâmica de ARP ou assegamento DHCP que são conhecidos por causar
problemas.
Como usar o endereçamento TCP/IP
automático sem um servidor DHCP
Este artigo descreve como usar o endereçamento do protocolo TCP/IP (protocolo de

controle de transmissão) automático sem que um servidor DHCP esteja presente na
rede. As versões do sistema operacional listadas na seção "aplica-se a" deste artigo têm
um recurso chamado APIPA (endereçamento IP privado automático). com esse recurso,
um computador Windows pode atribuir a si mesmo um endereço IP (Internet Protocol)
caso um servidor DHCP não esteja disponível ou não exista na rede. Esse recurso torna a
configuração e o suporte a uma pequena rede local (LAN) que executa TCP/IP com
menos dificuldade.
Mais informações
） Importante
Siga as etapas nesta seção com cuidado. Problemas sérios podem ocorrer se você
modificar o Registro incorretamente. Antes de modificá-lo, faça backup do
Registro para a restauração em caso de problemas.
um computador baseado em Windows configurado para usar o DHCP pode

automaticamente atribuir a si próprio um endereço IP (Internet Protocol) se um servidor
DHCP não estiver disponível. Por exemplo, isso pode ocorrer em uma rede sem um
servidor DHCP, ou em uma rede se um servidor DHCP estiver temporariamente inativo
para manutenção.
A IANA (Internet Assigned Numbers Authority) reservou o 169.254.0.0-169.254.255.255

para o endereçamento IP privado automático. Como resultado, o APIPA fornece um
endereço que está garantido para não entrar em conflito com endereços roteáveis.
Depois que o adaptador de rede tiver sido atribuído um endereço IP, o computador
poderá usar TCP/IP para se comunicar com qualquer outro computador que esteja
conectado à mesma LAN e que também esteja configurado para APIPA ou que tenha o
endereço IP definido manualmente como 169.254. x. y (em que x. y é o intervalo de
endereços do cliente) com uma máscara de sub-rede de 255.255.0.0. Observe que o
computador não pode se comunicar com computadores em outras sub-redes ou com
computadores que não usam o endereçamento IP privado automático. O
endereçamento IP privado automático é habilitado por padrão.
Talvez você queira desabilitá-lo em qualquer um dos seguintes casos:
Sua rede usa roteadores.
Sua rede está conectada à Internet sem um servidor NAT ou de proxy.
A menos que você tenha desabilitado mensagens relacionadas ao DHCP, as mensagens

DHCP fornecem notificações quando você altera entre o endereçamento DHCP e o
endereçamento IP privado automático. Se o sistema de mensagens DHCP for
desabilitado acidentalmente, você poderá ativar as mensagens DHCP novamente
alterando o valor do valor PopupFlag na seguinte chave do registro de 00 para 01:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP
Observe que você deve reiniciar o computador para que a alteração entre em vigor.
você também pode determinar se o computador está usando o APIPA usando a
ferramenta Winipcfg no Windows Millennium edition, Windows 98 ou Windows 98
Second edition:
Clique em Iniciar, executar, digite "winipcfg" (sem as aspas) e, em seguida, clique em OK.
Clique em mais informações. Se a caixa endereço de configuração automática de IP
contiver um endereço IP dentro do intervalo 169.254. x. x, o endereçamento IP privado
automático será habilitado. Se a caixa de endereço IP existir, o endereçamento IP
privado automático não estará habilitado no momento.
para Windows 2000, Windows
XP ou Windows Server 2003, você pode determinar se o computador está usando o
APIPA usando o comando IPconfig em um prompt de comando:
Clique em Iniciar, executar, digite "cmd" (sem as aspas) e clique em OK para abrir uma
janela de linha de comando do MS-DOS. Digite "ipconfig/all" (sem as aspas) e, em
seguida, pressione a tecla ENTER. Se a linha ' autoconfiguração habilitada ' disser "Sim"
e o ' endereço IP de configuração automática ' for 169.254. x. y (em que x. y é o
identificador exclusivo do cliente), o computador estará usando APIPA. Se a linha '
autoconfiguração habilitada ' disser "não", o computador não está usando APIPA no
momento.
Você pode desabilitar o endereçamento IP privado automático usando
qualquer um dos métodos a seguir.
Você pode configurar as informações de TCP/IP manualmente, o que desabilita

completamente o DHCP. Você pode desabilitar o endereçamento IP privado automático
(mas não o DHCP) editando o registro. você pode fazer isso adicionando a entrada de
registro DWORD "IPAutoconfigurationEnabled" com um valor de 0x0 para a seguinte
chave do registro para Windows Millennium edition, Windows98 ou Windows 98
Second edition: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP
para Windows 2000, Windows XP e Windows Server 2003, o APIPA pode ser
desabilitado adicionando a entrada de registro DWORD "IPAutoconfigurationEnabled"
com um valor de 0x0 para a seguinte chave do
registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Inter
faces\<Adapter GUID>
７ Observação
A subchave do GUID do adaptador é um GUID (identificador global exclusivo) para

o adaptador de LAN do computador.
A especificação de um valor de 1 para a entrada DWORD IPAutoconfigurationEnabled

habilitará o APIPA, que é o estado padrão quando esse valor é omitido do registro.
Exemplos de onde o APIPA pode ser útil
Exemplo 1: nenhum endereço IP anterior e nenhum

servidor DHCP
quando o computador baseado em Windows (configurado para DHCP) estiver sendo
inicializado, ele difundirá três ou mais mensagens de "descoberta". se um servidor DHCP
não responder depois que várias mensagens de descoberta forem transmitidas, o
computador Windows atribuirá a si mesmo um endereço de classe B (APIPA). em
seguida, o computador Windows exibirá uma mensagem de erro para o usuário do
computador (fornecendo a ele nunca foi atribuído um endereço IP de um servidor
DHCP no passado). o computador Windows enviará uma mensagem de descoberta a
cada três minutos em uma tentativa de estabelecer comunicações com um servidor
DHCP.
Exemplo 2: endereço IP anterior e nenhum servidor DHCP

O computador verifica o servidor DHCP e, se nenhum for encontrado, será feita uma
tentativa de entrar em contato com o gateway padrão. se o gateway padrão responder,
o computador Windows manterá o endereço IP concedido anteriormente. No entanto,
se o computador não receber uma resposta do gateway padrão ou se nenhum for
atribuído, ele usará o recurso de endereçamento IP privado automático para atribuir a si
mesmo um endereço IP. Uma mensagem de erro é apresentada ao usuário e as
mensagens de descoberta são transmitidas a cada 3 minutos. Quando um servidor
DHCP entra na linha, uma mensagem é gerada informando que as comunicações foram
restabelecidas com um servidor DHCP.
Exemplo 3: a concessão expira e nenhum servidor DHCP

o computador baseado em Windows tenta restabelecer a concessão do endereço IP. se
o computador Windows não encontrar um servidor DCHP, ele atribuirá a si mesmo um
endereço IP depois de gerar uma mensagem de erro. Em seguida, o computador
transmite quatro mensagens de descoberta e, após a cada 5 minutos, ele repete o
procedimento inteiro até que um servidor DHCP venha a ficar online. Uma mensagem é
gerada informando que as comunicações foram restabelecidas com o servidor DHCP.
Solucionar problemas no cliente DHCP
rapidamente problemas comuns de DHCP.
Este artigo discute como solucionar problemas que ocorrem em clientes DHCP.
Lista de verificação de solução de problemas

Verifique os seguintes dispositivos e configurações:
Os cabos estão conectados e funcionando.
A filtragem de MAC está habilitada nos comutadores aos quais o cliente está
conectado.
O adaptador de rede está habilitado.
O driver de adaptador de rede correto está instalado e atualizado.
O serviço cliente DHCP é iniciado e está em execução. Para verificar isso, execute o
comando net start e procure o cliente DHCP.
Não há nenhuma porta de bloqueio de firewall 67 e 68 UDP no computador

cliente.
Logs de eventos
Examine os logs de eventos do cliente Microsoft-Windows-DHCP/Eventos operacionais
e do cliente Microsoft-Windows-DHCP/Administração. Todos os eventos relacionados
ao serviço cliente DHCP são enviados para esses logs de eventos.
Os Eventos do Cliente
Microsoft-Windows-DHCP estão localizados no Visualizador de Eventos em Logs de
Aplicativos e Serviços.
O comando do PowerShell "Get-NetAdapter -IncludeHidden" fornece as informações

necessárias para interpretar os eventos listados nos logs. Por exemplo, ID da interface,
endereço MAC e assim por diante.
Coleta de dados
Recomendamos que você colete dados simultaneamente no lado do cliente DHCP e do
servidor quando o problema ocorrer. No entanto, dependendo do problema real, você
também pode iniciar sua investigação usando um único conjunto de dados no cliente
DHCP ou no servidor DHCP.
Para coletar dados do servidor e do cliente afetado, use Wireshark . Comece a coletar
ao mesmo tempo no cliente DHCP e nos computadores do servidor DHCP.
Execute os seguintes comandos no cliente que está enfrentando o problema:
Console
ipconfig /release
ipconfig /renew
Em seguida, interrompa o Wireshark no cliente e no servidor. Verifique os rastreamentos

gerados. Eles devem, pelo menos, dizer em qual estágio a comunicação para.
Solucionar problemas no servidor DHCP
rapidamente problemas comuns de DHCP.
Este artigo discute como solucionar problemas que ocorrem no servidor DHCP.
Lista de verificação de solução de problemas

Verifique as seguintes configurações:
O serviço do servidor DHCP é iniciado e está em execução. Para verificar essa

configuração, execute o comando net start e procure o servidor DHCP.
O servidor DHCP está autorizado. Consulte Autorização do servidor DHCP do

Windows no cenário ingressado no domínio.
Verifique se as concessões de endereço IP estão disponíveis no escopo do servidor

DHCP para a sub-rede em que o cliente DHCP está. Para fazer isso, consulte a
estatística do escopo apropriado no console de gerenciamento do servidor DHCP.
Verifique se alguma listagem de BAD_ADDRESS pode ser encontrada em

Concessões de Endereço.
Verifique se algum dispositivo na rede tem endereços IP estáticos que não foram
excluídos do escopo do DHCP.
Verifique se o servidor DHCP está associado a pelo menos um endereço IP e se

isso está dentro da sub-rede dos escopos dos quais os endereços IP devem ser
concedidos (a menos que usem a retransmissão DHCP). Para fazer isso, execute o
cmdlet Get-DhcpServerv4Binding ou Get-DhcpServerv6Binding . As associações
de conexão de servidor são configuradas no console de gerenciamento do
servidor DHCP em Propriedades Avançadas IPv4/IPv6.
Verifique se apenas o servidor DHCP está escutando na porta UDP 67 e 68.

Nenhum outro processo ou serviço (como WDS ou PXE) deve ocupar essas portas.
Para fazer isso, execute o comando netstat -anb .
Verifique se a isenção IPsec do servidor DHCP será adicionada se você estiver

lidando com um ambiente implantado por IPsec.
Verifique se o endereço IP do agente de retransmissão pode receber ping do
servidor DHCP.
Enumere e verifique as políticas e filtros DHCP configurados.
Logs de eventos
Verifique os logs de eventos de serviço do Sistema e do Servidor DHCP (Logs de
Aplicativos e Serviços>Microsoft>Windows>DHCP-Server) para obter problemas
relatados relacionados ao problema observado.
Dependendo do tipo de problema, um
evento é registrado em um dos seguintes canais de evento: Eventos Operacionais do
Servidor DHCP Eventos Administrativos do Servidor DHCP Eventos do Sistema dhcp
eventos de notificação de filtro de servidor DHCP Eventos de auditoria do servidor
DHCP
Coleta de dados
Log do servidor DHCP

Os logs de depuração do serviço do servidor DHCP fornecem mais informações sobre a
atribuição de concessão de endereço IP e as atualizações dinâmicas de DNS feitas pelo
servidor DHCP. Por padrão, esses logs estão localizados em %windir%\System32\Dhcp.
Para obter mais informações, consulte Analisar arquivos de log do servidor DHCP.
Rastreamento de rede
Um rastreamento de rede correlacionado pode indicar o que o servidor DHCP estava
fazendo no momento em que o evento foi registrado. Para criar esse rastreamento, siga
estas etapas:
1. Acesse o GitHub e baixe o arquivo tss_tools.zip.
2. Copie o arquivo Tss_tools.zip e expanda-o para um local no disco local, como para
a pasta C:\tools.
3. Execute o seguinte comando em C:\tools em uma janela do Prompt de Comando

com privilégios elevados:
Console
TSS Ron Trace <Stop:Evt:>20321:<Other:>DhcpAdminEvents NoSDP NoPSR

NoProcmon NoGPresult
７ Observação
Neste comando, substitua <Stop:Evt:> e <Outros:> pela ID do evento e pelo

canal de eventos no qual você se concentrará na sessão de rastreamento.
Os
arquivos Tss.cmd_ReadMe_Help.docx contidos no arquivo Tss_tools.zip
fornecem mais informações sobre todas as configurações disponíveis.
4. Depois que o evento é disparado, a ferramenta cria uma pasta chamada

C:\MS_DATA. Essa pasta conterá alguns arquivos de saída úteis que fornecem
informações gerais sobre a configuração de rede e domínio do computador.
O
arquivo mais interessante nessa pasta é
%Computername%_date_time_packetcapture_InternetClient_dbg.etl.
Usando o
aplicativo Monitor de Rede , você pode carregar o arquivo e definir o filtro de
exibição no protocolo "DHCP ou DNS" para examinar o que está acontecendo nos
bastidores.
EAP (protocolo de autenticação
extensível) para acesso à rede
aplica-se a: Windows server 2022, Windows server 2019, Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows 8.1
O EAP (protocolo de autenticação extensível) é uma estrutura arquitetônica que fornece

extensibilidade para métodos de autenticação para tecnologias de acesso à rede
protegidas comumente usadas, como o acesso sem fio baseado em IEEE 802.1 X, o
acesso com fio baseado em IEEE 802.1 X e conexões de protocolo PPP (PPP), como VPN
(rede virtual privada). O EAP não é um método de autenticação como o MS-CHAP v2,
mas sim uma estrutura no cliente de acesso e no servidor de autenticação que permite
aos fornecedores de rede desenvolver e instalar facilmente novos métodos de
autenticação conhecidos como métodos EAP.
Métodos de autenticação
Este tópico contém informações específicas sobre configuração dos seguintes métodos
de autenticação em EAP. Observe que os métodos de autenticação EAP usados em
métodos EAP encapsulados são comumente conhecidos como métodos internos ou
tipos de EAP.
EAP protegido (PEAP)
Esta seção contém informações de configuração para os dois métodos EAP

internos padrão fornecidos com o PEAP.
Protocolo EAP-TLS (Transport Layer Security)
Aparecendo como cartão inteligente ou outras propriedades de certificado no

sistema operacional, o EAP-TLS pode ser implantado como um método interno
para PEAP ou como um método EAP autônomo. Quando é configurado como
método de autenticação interno, as definições de configuração do EAP-TLS são
idênticas às definições usadas para implantar o EAP-TLS como método externo,
com a diferença de que ele é configurado para operar no PEAP. Para obter
detalhes de configuração, consulte cartão inteligente ou outros itens de
configuração de propriedades de certificado.
MS-CHAP v2 (EAP-Microsoft Challenge Handshake Authentication Protocol
versão 2)
EAP-MS-CHAP v2 de senha segura é um tipo de EAP que pode ser usado com o
PEAP para autenticação de rede baseada em senha. O EAP-MsCHAP V2 também
pode ser usado como um método autônomo para VPN, mas somente como um
método interno de PEAP para sem fio.
Protocolo EAP-TTLS (Tunneled Transport Layer Security)
EAP-SIM (Subscriber Identity Module), EAP- AKA (Authentication and Key

Agreement), e EAP-AKA' (AKA Prime)
Permite a autenticação usando cartões SIM e é implementado quando um cliente

adquire um plano de serviço de banda larga sem fio de uma operadora de rede
móvel. Como parte do plano, o cliente normalmente recebe um perfil móvel que é
pré-configurado para autenticação SIM.
Este tópico fornece informações sobre o seguinte:

Definições de configuração de EAP-SIM
Definições de configuração de EAP-AKA e EAP-AKA
EAP-TLS, PEAP e EAP-TTLS

Você pode acessar as propriedades do EAP para acesso sem fio e com fio autenticado
802.1X das seguintes formas:
Ao configurar as extensões das Políticas de Rede com Fio (IEEE 802.3) e das
Políticas de Rede sem Fio (IEEE 802.11) na Política de Grupo.
Ao configurar manualmente conexões com ou sem fio em computadores cliente.
Você pode acessar as propriedades do EAP para conexões VPN das seguintes formas:
Usando o Kit de administração do Gerenciador de conexões (CMAK) para

configurar as conexões VPN.
Configurando manualmente conexões VPN em computadores cliente.
Por padrão, você pode definir configurações do EAP para os seguintes métodos de
autenticação para acesso com fio autenticado 802.1X, acesso sem fio autenticado
802.1X e VPN:
Microsoft: cartão inteligente ou outro certificado (EAP-TLS)

Microsoft: EAP protegido (PEAP)
Microsoft: EAP-TTLS
Além disso, o método de autenticação de rede MS-CHAP-V2 está disponível para VPN
por padrão.
Definições de configuração de propriedades

EAP protegidas
Esta seção lista as configurações que podem ser configuradas para EAP protegido.
） Importante
A implantação do mesmo tipo de método de autenticação para PEAP e EAP cria

uma vulnerabilidade de segurança. Quando você implantar PEAP e EAP (que não é
protegido), não use o mesmo tipo de autenticação. Por exemplo, se você implantar
o PEAP-TLS, não implante também o EAP-TLS.
Verificar a identidade do servidor Validando o certificado

Este item especifica que o cliente verifica se os certificados de servidor apresentados ao
computador cliente têm as assinaturas corretas, não expiraram e foram emitidos por
uma autoridade de certificação (CA) raiz confiável. A configuração padrão é "Enabled".
Se você desabilitar essa caixa de seleção, os computadores cliente não poderão
verificar a identidade dos servidores durante o processo de autenticação. Se a
autenticação do servidor não ocorrer, os usuários ficarão expostos a riscos de
segurança graves, incluindo a possibilidade de que os usuários possam se conectar
inadvertidamente a uma rede não autorizada.
Conectar-se a estes servidores

Este item permite que você especifique o nome para servidores de serviço RADIUS
(RADIUS) que fornecem autenticação e autorização de rede. Observe que você deve
digitar o nome exatamente como ele aparece no campo assunto de cada certificado de
servidor RADIUS ou usar expressões regulares para especificar o nome do servidor. A
sintaxe completa da expressão regular pode ser usada para especificar o nome do
servidor, mas para diferenciar uma expressão regular com a cadeia de caracteres literal,
você deve usar pelo menos um "" na cadeia de caracteres especificada. Por exemplo,
você pode especificar nps.example.com para especificar o servidor RADIUS
nps1.example.com ou nps2.example.com.
Mesmo que nenhum servidor RADIUS seja especificado, o cliente verificará se o
certificado desse servidor foi emitido por uma autoridade de certificação raiz confiável.
Padrões:
Com fio e sem fio = não habilitado

VPN = habilitado
Autoridades de Certificação Confiáveis

Este item lista as autoridades de certificação raiz confiáveis. A lista é criada a partir das
CAs raiz confiáveis que estão instaladas no computador e nos repositórios de
certificados do usuário. Você pode especificar quais certificados de autoridade de
certificação raiz confiáveis que os suplicantes usarão para determinar se confiam em
seus servidores, como seu servidor que executa o NPS ou o servidor de
provisionamento. Se nenhuma autoridade de certificação raiz confiável for selecionada,
o cliente 802.1X verificará se o certificado do computador do servidor RADIUS foi
emitido por uma autoridade de certificação raiz confiável instalada. Se uma ou várias
autoridades de certificação raiz confiável forem selecionadas, o cliente 802.1X verificará
se o certificado do computador do servidor RADIUS foi emitido por uma autoridade de
certificação raiz confiável selecionada. Mesmo que nenhuma autoridade de certificação
raiz confiável esteja selecionada, o cliente verificará se o certificado do servidor RADIUS
foi emitido por uma autoridade de certificação raiz confiável.
Se você tiver uma infraestrutura de chave pública (PKI) na sua rede e tiver usado uma
autoridade de certificação para emitir certificados para os servidores RADIUS, seu
certificado da autoridade de certificação será automaticamente adicionado à lista de
Você também pode comprar um certificado de uma autoridade de certificação que não
seja da Microsoft. Algumas das autoridades de certificação raiz confiáveis que não são
da Microsoft fornecem softwares com os certificados comprados que instalam
automaticamente o certificado no repositório de certificados Autoridades de
Certificação Raiz Confiáveis. Nesse caso, a autoridade de certificação raiz confiável
aparece automaticamente na lista de autoridades de certificação raiz confiáveis.
７ Observação
Não especifique um certificado de autoridade de certificação raiz confiável que

ainda não esteja listado nos repositórios de certificados Autoridades de
Certificação Raiz Confiáveis dos computadores clientes para o Usuário Atual e
Computador Local. Se você designar um certificado que não esteja instalado nos
computadores cliente, a autenticação falhará.
Padrão = não habilitado, nenhuma autoridade de certificação raiz confiável selecionada
Notificações antes da conexão

Este item especifica se o usuário será notificado se o nome do servidor ou o certificado
raiz não for especificado ou se a identidade do servidor não puder ser verificada.
Por padrão, as seguintes opções são fornecidas:
Caso 1: Não pedir para o usuário autorizar novos servidores ou autoridades de

certificação confiáveis especifica que:
Se o nome do servidor não estiver na lista Conectar a estes servidores
ou o certificado raiz for localizado, mas não estiver selecionado na lista de
Autoridades de Certificação Raiz Confiáveis em Propriedades PEAP
ou o certificado raiz não for localizado no computador
o usuário não será notificado, e a tentativa de conexão irá falhar.
Caso 2: Informar o usuário se o nome do servidor ou certificado raiz não for

especificado especifica que:
em seguida, o usuário será avisado se deseja aceitar o certificado raiz. Se o usuário

aceitar o certificado, a autenticação continuará. Se o usuário rejeitar o certificado, a
tentativa de conexão irá falhar. Nessa opção, se o certificado raiz não estiver
presente no computador, o usuário não será notificado e as tentativas de conexão
falharão.
Caso 3: informe ao usuário se a identidade do servidor não pode ser verificada

especifica se:
ou o certificado raiz não for localizado no computador
em seguida, o usuário será avisado se deseja aceitar o certificado raiz. Se o usuário

aceitar o certificado, a autenticação continuará. Se o usuário rejeitar o certificado, a
tentativa de conexão irá falhar.
Selecionar método de autenticação
Este item permite que você selecione o tipo de EAP a ser usado com o PEAP para
autenticação de rede. Por padrão, dois tipos de EAP estão disponíveis, senha segura
(EAP-MSCHAP v2) e cartão inteligente ou outro certificado (EAP-TLS). No entanto, o
EAP é um protocolo flexível que permite a inclusão de métodos adicionais de EAP e não
está restrito a esses dois tipos.
Itens de configuração de propriedades de senha segura (EAP-MSCHAP v2)
Cartões inteligentes ou outros itens de configuração de propriedades de

certificado
Padrão = senha segura (EAP-MSCHAP v2)
Configurar
Esse item fornece acesso às configurações de propriedade para o tipo de EAP
especificado.
Habilitar reconexão rápida

Permite criar uma associação de segurança nova ou atualizada com mais eficiência ou
em um número menor de viagens de ida e volta, no caso em que uma associação de
segurança foi estabelecida anteriormente.
Para conexões VPN, a Reconexão Rápida usa a tecnologia IKEv2 para fornecer
conectividade VPN contínua e consistente quando os usuários perdem
temporariamente a conexão com a Internet. Os usuários que se conectam usando
banda larga móvel sem fio terão mais benefícios com esse recurso.
Um exemplo desse benefício é um cenário comum em que um usuário está viajando em

um trem, usa uma placa de banda larga móvel sem fio para se conectar à Internet e
estabelece uma conexão VPN com a rede corporativa.
Toda vez que o trem passa por um túnel, a conexão com a Internet é perdida. Quando o
trem está fora do túnel, a placa de banda larga móvel sem fio reconecta-se
automaticamente à Internet.
A Reconexão Rápida restabelecerá automaticamente as conexões VPN ativas quando a

conectividade com a Internet for estabelecida novamente. Embora a reconexão possa
levar vários segundos para ocorrer, ela é realizada de forma transparente para os
usuários.
Padrão = habilitado
Impor a proteção de acesso à rede

Este item especifica que, antes que as conexões com uma rede sejam permitidas, as
verificações de saúde do sistema são executadas em supplicantes de EAP para
determinar se atendem aos requisitos de saúde do sistema.
Padrão = não habilitado
Desconectar se o servidor não tiver TLV com ligação de

criptografia
Este item especifica que os clientes que se conectam deverão encerrar o processo de
autenticação de rede se o servidor RADIUS não apresentar a criptografia TLV (Type-
Length-Value). O TLV com ligação de criptografia aumenta a segurança do túnel de TLS
em PEAP combinando as autenticações de método interno e externo para que os
invasores não consigam executar ataques man-in-the-middle redirecionando uma
autenticação MS-CHAP v2 usando o canal PEAP.
Habilitar privacidade de identidade (Windows 8 somente)

Especifica se os clientes são configurados de modo que não possam enviar sua
identidade antes de o cliente autenticar o servidor RADIUS e, como opção, fornece um
local para digitar um valor de identidade anônima. Por exemplo, se você selecionar
Habilitar Privacidade de Identidade e digitar "convidado" como o valor de identidade
anônimo, a resposta de identidade para um usuário com identidade alice@example será
guest@example. Se você selecionar Habilitar Privacidade de Identidade, mas não
fornecer um valor de identidade anônimo, a resposta de identidade para o usuário
alice@example será .
Essa configuração se aplica somente a computadores que executam Windows 8 e

anteriores.

Proteger itens de configuração de
propriedades de senha
A verificação Usar automaticamente meu nome de logon do Windows e senha (e
domínio, se tiver) especifica que o nome de logon e a senha atuais baseados no usuário
Windows são usados como credenciais de autenticação de rede.
Padrões:
Com fio e sem fio = habilitado

VPN = não habilitado
Cartão inteligente ou outros itens de

configuração de propriedades de certificado
Esta seção lista os itens que podem ser configurados para EAP-TLS.
Usar meu cartão inteligente

Este item especifica que os clientes que fazem solicitações de autenticação devem
apresentar um certificado de cartão inteligente para autenticação de rede.
Padrões:

VPN = habilitado
Usar um certificado neste computador

Este item especifica que a autenticação de clientes deve usar um certificado localizado
nos armazenamentos de certificados usuário atual ou computador local.
Padrões:

Usar seleção de certificado simples (recomendado)

Este item especifica se Windows filtra certificados que são improváveis de atender aos
requisitos de autenticação. Isso serve para limitar a lista de certificados disponíveis ao
solicitar que o usuário selecione um certificado.
Padrões:

Avançado
Esse item abre a caixa de diálogo Configurar Seleção de Certificado. Para obter mais
informações sobre Configurar Seleção de Certificado, consulte Configurar novos itens
de configuração de seleção de certificado.
Verificar a identidade do servidor validando o certificado

Este item especifica que o cliente verifica se os certificados do servidor apresentados ao
computador cliente têm as assinaturas corretas, não expiraram e foram emitidos por
uma AC (autoridade de certificação) raiz confiável. Não desmarque esta caixa de
seleção ou os computadores cliente não poderão verificar a identidade dos servidores
durante o processo de autenticação. Se a autenticação do servidor não ocorrer, os
usuários ficarão expostos a graves riscos de segurança, incluindo a possibilidade de
poderem se conectar desavisadamente a uma rede não autorizada.
Padrão = habilitado

Esse item permite que você especifique o nome dos servidores RADIUS que fornecem
autenticação e autorização de rede. Observe que você deve digitar o nome exatamente
como ele aparece no campo Assunto de cada certificado do servidor RADIUS ou usar
expressões regulares para especificar o nome do servidor. A sintaxe completa da
expressão regular pode ser usada para especificar o nome do servidor, mas para
diferenciar uma expressão regular com a cadeia de caracteres literal, você deve usar
pelo menos um "" na cadeia de caracteres especificada. Por exemplo, você pode
especificar nps.example.com para especificar o servidor RADIUS nps1.example.com ou
nps2.example.com.
Mesmo que nenhum servidor RADIUS seja especificado, o cliente verificará se o

certificado desse servidor foi emitido por uma autoridade de certificação raiz confiável.
Padrões:
VPN = habilitado
Autoridades de certificação raiz confiáveis

Este item lista as autoridades de certificação raiz confiáveis. A lista é criada com base
nas AAs raiz confiáveis instaladas nos armazenamentos de certificados do computador e
do usuário. Você pode especificar os certificados de autoridade de certificação raiz
confiáveis que os suplicantes usarão para determinar se confiam em seus servidores,
como seu servidor executando NPS ou o servidor de provisionamento. Se nenhuma
autoridade de certificação raiz confiável for selecionada, o cliente 802.1X verificará se o
certificado do computador do servidor RADIUS foi emitido por uma autoridade de
certificação raiz confiável instalada. Se uma ou várias autoridades de certificação raiz
confiável forem selecionadas, o cliente 802.1X verificará se o certificado do computador
do servidor RADIUS foi emitido por uma autoridade de certificação raiz confiável
selecionada.
aparece automaticamente na lista de autoridades de certificação raiz confiáveis. Mesmo
que nenhuma autoridade de certificação raiz confiável esteja selecionada, o cliente
verificará se o certificado do servidor RADIUS foi emitido por uma autoridade de
certificação raiz confiável.
Não especifique um certificado de autoridade de certificação raiz confiável que ainda

não esteja listado nos repositórios de certificados Autoridades de Certificação Raiz
Confiáveis dos computadores clientes para o Usuário Atual e Computador Local.
７ Observação
Se você designar um certificado que não esteja instalado nos computadores

cliente, a autenticação falhará.
Padrão = não habilitado, nenhuma autoridade de certificação raiz confiável selecionada.
Exibir certificado
Esse item permite que você veja as propriedades do certificado selecionado.
Não solicitar ao usuário autorização para novos

servidores ou autoridades de certificação confiáveis
Esse item impede que o usuário seja solicitado a confiar em um certificado do servidor
se esse certificado estiver configurado incorretamente, se ainda não for confiável ou
ambos (se habilitado). É recomendável selecionar essa caixa de seleção para simplificar a
experiência do usuário e impedi-lo de escolher inadvertidamente confiar em um
servidor implantado por um invasor.
Usar um nome de usuário diferente para a conexão

Este item especifica se um nome de usuário deve ser usado para autenticação diferente
do nome de usuário no certificado.
Configurar Nova Seleção de Certificado - itens

de configuração
Use Nova Seleção de Certificado para configurar os critérios que os computadores
clientes usam para selecionar automaticamente o certificado correto no computador
cliente para fins de autenticação. Quando a configuração é fornecida aos computadores
clientes da rede por meio de Políticas de Rede com Fio (IEEE 802.3), Políticas de Rede
sem Fio (IEEE 802.11) ou pelo Kit de Administração do Gerenciador de conexões (CMAK)
para VPN, os clientes são automaticamente provisionados com os critérios de
autenticação especificados.
Esta seção lista os itens de configuração de Nova Seleção de Certificado, juntamente

com uma descrição de cada um.
Emissor do certificado
Este item especifica se a filtragem do Emissor do Certificado está habilitada.
Padrão = não selecionado
ListaEmissor do Certificado
Usada para especificar um ou vários emissores para os certificados.
Lista os nomes de todos os emissores para os quais há certificados de autoridade de

certificação presentes no repositório de certificados Autoridades de Certificação Raiz
Confiáveis ou Autoridades de Certificação Intermediárias da conta do computador
local.
Inclui todas as autoridades de certificação raiz e intermediárias.
Contém somente os emissores para os quais há certificados válidos

correspondentes presentes no computador (por exemplo, certificados que não
estejam expirados ou revogados).
A lista final de certificados permitidos para autenticação contém apenas aqueles que
foram emitidos por um dos emissores selecionados nesta lista.
Padrão = nenhum selecionado
Uso Estendido de Chave (EKU)

Você pode selecionar Todas as Finalidades, Autenticação do Cliente, Qualquer
Finalidade ou qualquer combinação deles. Especifica que, quando uma combinação é
selecionada, todos os certificados que satisfazem a pelo menos uma das três condições
são considerados válidos para fins de autenticação do cliente no servidor. Se a filtragem
EKU estiver habilitada, será necessário selecionar uma das opções; caso contrário, o
controle do comando OK será desabilitado.
Todas as Finalidades
Quando selecionado, esse item especifica que os certificados que têm o EKU de Todas
as Finalidades são considerados certificados válidos para fins de autenticação do cliente
para o servidor.
Padrão = selecionado quando o EKU (Uso Estendido de Chave) está selecionado

Autenticação de cliente
Quando selecionado, esse item especifica que os certificados que têm o EKU de
Autenticação de Cliente e a lista especificada de EKUs são considerados certificados
válidos para fins de autenticação do cliente para o servidor.
Qualquer Finalidade
Quando selecionado, esse item especifica que todos os certificados com EKU de
Qualquer Finalidade e a lista especificada de EKUs são considerados certificados válidos
para fins de autenticação do cliente para o servidor.
Adicionar
Este item abre a caixa de diálogo Selecionar EKUs, que permite adicionar EKUs padrão,
personalizadas ou específicas do fornecedor à lista Autenticação do Cliente ou
Qualquer Finalidade.
Padrão = nenhum EKU listado
Remover
Esse item remove o EKU selecionado da lista Autenticação de Clienteou Qualquer
Finalidade.
Padrão = N/D
７ Observação
Quando Emissor de Certificado e Uso Estendido de Chave (EKU) estão habilitados,

somente os certificados que satisfazem às duas condições são considerados válidos
para fins de autenticação do cliente no servidor.
Selecionar EKUs
Você pode selecionar um EKU na lista fornecida ou adicionar um novo.
Item Detalhes
Adicionar Abre a caixa de diálogo Adicionar ou Editar EKU , que permite definir e adicionar
EKUs personalizadas. Em Selecione os EKUs da lista abaixo, selecione um EKU na lista
e clique em OK para adicionar o EKU à lista Autenticação de Cliente ou Qualquer
Finalidade.
Editar Abre a caixa de diálogo Adicionar ou Editar EKU e permite editar EKUs
personalizadas que você adicionou. Você não pode editar os EKUs padrão
predefinidos.
Remover Remove o EKU personalizado selecionado da lista de EKUs na caixa de diálogo

Selecionar EKUs . Você não pode remover os EKUs padrão predefinidos.
Adicionar ou Editar EKU

Item Detalhes
Insira Fornece um local para digitar o nome do EKU personalizado.

o
nome
de
EKU
Insira Fornece um local para digitar o OID do EKU. Somente números, separadores e “.” são
o OID permitidos. É permitido inserir curingas. Nesse caso, todos os OIDs filhos na hierarquia
do são permitidos. Por exemplo, se você informar 1.3.6.1.4.1.311.*, serão permitidos
EKU 1.3.6.1.4.1.311.42 e 1.3.6.1.4.1.311.42.2.1
TTLS - itens de configuração

EAP-TTLS é um método de túnel EAP com base em padrões que oferece suporte à
autenticação mútua e fornece um túnel seguro para autenticação de inclusão de cliente
usando métodos EAP e outros protocolos legados. A adição de EAP-TTLS no Windows
Server 2012 fornece suporte apenas do lado do cliente, com a finalidade de dar suporte
à interoperação com os servidores RADIUS implantados com mais comumente que
suportam EAP-TTLS.
Esta seção lista os itens que podem ser configurados para EAP-TTLS.
Habilitar Privacidade de Identidade (Windows 8 somente)

Este item especifica que os clientes são configurados para que eles não podem enviar
sua identidade antes que o cliente tenha autenticado o servidor RADIUS e,
opcionalmente, fornece um local para digitar um valor de identidade anônima. Por
exemplo, se você selecionar Habilitar Privacidade de Identidade e digitar "convidado"
como o valor de identidade anônimo, a resposta de identidade para um usuário com
identidade alice@example será guest@example. Se você selecionar Habilitar
Privacidade de Identidade, mas não fornecer um valor de identidade anônimo, a
resposta de identidade para o usuário alice@example será .
Essa configuração se aplica somente a computadores que executam Windows 8.

Esse item permite que você especifique o nome dos servidores RADIUS que fornecem
autenticação e autorização de rede. Observe que você deve digitar o nome exatamente
como ele aparece no campo Assunto de cada certificado do servidor RADIUS ou usar
expressões regulares para especificar o nome do servidor. A sintaxe completa da
expressão regular pode ser usada para especificar o nome do servidor. Mas, para
diferenciar uma expressão regular com a cadeia de caracteres literal, você deve usar
pelo menos um * na cadeia de caracteres especificada. Por exemplo, você pode
especificar nps*.exemplo.com para especificar o nps1.exemplo.com ou
nps2.exemplo.com do servidor RADIUS. Mesmo que nenhum servidor RADIUS seja
especificado, o cliente verificará se o certificado desse servidor foi emitido por uma
autoridade de certificação raiz confiável.
Padrão = nenhum
Autoridades de Certificação Confiáveis

Este item lista as autoridades de certificação raiz confiáveis. A lista é criada com base
nas AAs raiz confiáveis instaladas nos armazenamentos de certificados do computador e
do usuário. Você pode especificar os certificados de autoridade de certificação raiz
confiáveis que os suplicantes usarão para determinar se confiam em seus servidores,
como seu servidor executando NPS ou o servidor de provisionamento. Se nenhuma
autoridade de certificação raiz confiável for selecionada, o cliente 802.1X verificará se o
certificado do computador do servidor RADIUS foi emitido por uma autoridade de
certificação raiz confiável instalada. Se uma ou várias autoridades de certificação raiz
confiável forem selecionadas, o cliente 802.1X verificará se o certificado do computador
do servidor RADIUS foi emitido por uma autoridade de certificação raiz confiável
selecionada. Mesmo que nenhuma autoridade de certificação raiz confiável esteja
selecionada, o cliente verificará se o certificado do servidor RADIUS foi emitido por uma
autoridade de certificação raiz confiável.
autoridades de certificação raiz confiáveis. Se a opção for selecionada, seu certificado de
autoridade de certificação raiz será instalado em um computador cliente quando os
computadores forem associados ao domínio.
aparece automaticamente na lista de autoridades de certificação raiz confiáveis.
Não especifique um certificado de autoridade de certificação raiz confiável que ainda

não esteja listado nos repositórios de certificados Autoridades de Certificação Raiz
Confiáveis dos computadores clientes para o Usuário Atual e Computador Local.
７ Observação
Se você designar um certificado que não esteja instalado nos computadores

cliente, a autenticação falhará.
Padrão = não habilitado, nenhuma AC raiz confiável selecionada
Não perguntar ao usuário se não puder autorizar o

servidor
Este item especifica (quando não selecionado) que, se a validação do certificado do
servidor falhar devido a qualquer um dos seguintes motivos, o usuário deverá aceitar ou
rejeitar o servidor:
Um certificado raiz para o certificado do servidor não é encontrado ou selecionado

na lista Autoridades de Certificação Raiz Confiáveis.
Um ou mais certificados raiz intermediários na cadeia de certificados não são
encontrados.
O nome do assunto no certificado do servidor não corresponde a nenhum dos
servidores especificados na lista Conectar-se a estes servidores.
Padrão = não selecionado
Selecionar um método não EAP para autenticação

Especifica se um tipo não EAP ou EAP é usado para autenticação. Se Selecionar um
método não EAP para autenticação estiver selecionado, Selecionar um método EAP
para autenticação será desabilitado. Se a opção Selecionar um método não EAP para
autenticação for selecionada, os seguintes tipos de autenticação não EAP serão
fornecidos na lista suspensa:
PAP
CHAP
MS-CHAP
MS-CHAP v2
Padrões:
Selecionar um método não EAP para autenticação = habilitado

Tipo não EAP = PAP
Usar automaticamente o meu nome e a minha senha de

logon do Windows
Quando habilitado, esse item usa Windows credenciais de login. Esta marca de seleção é
habilitada somente quando MS-CHAP v2 é selecionado na lista suspensa Selecionar um
método não EAP para autenticação. Use automaticamente meu nome Windows logon
de usuário e a senha está desabilitada para os tipos de autenticação PAP, CHAP e MS-
CHAP.
Selecionar um método EAP para autenticação

Este item especifica se um tipo de EAP ou um tipo não EAP é usado para autenticação.
Se Selecionar um método EAP para autenticação estiver selecionado, Selecionar um
método não EAP para autenticação será desabilitado. Se a opção Selecionar um
método não EAP para autenticação for selecionada, os seguintes tipos de autenticação
não EAP serão fornecidos por padrão na lista suspensa:
Microsoft: Cartão Inteligente ou outro Certificado
Microsoft: MS-CHAP v2
MS-CHAP
MS-CHAP v2
７ Observação
A lista de listas listadas selecionar um método EAP para autenticação

enumerará todos os métodos de EAP instalados no servidor, exceto os
métodos PEAPe FAST tunnel. Os tipos EAP são listados na ordem em que são
descobertos pelo computador.
Configurar
Abre a caixa de diálogo de propriedades do tipo EAP especificado. Para obter detalhes
sobre os tipos de EAP padrão, consulte Itens de configuração de propriedades de cartão
inteligente ou outros itens de configuração de propriedades de certificado ou Senha
segura (EAP-MSCHAP v2).
Definições de configuração do EAP-SIM

O EAP-SIM é usado na distribuição de chaves de sessão e autenticação para sistemas
GSM (Global System for Mobile Communications). EAP-SIM é definido em RFC 4186.
A tabela a seguir lista as definições de configuração do EAP-SIM.
Item Descrição
Usar chaves de Se selecionada, especifica que o perfil usa criptografia forte.

Criptografia fortes
Não revelar a Quando habilitada, força o cliente a falhar na autenticação quando as

identidade real no solicitações do servidor por identidade permanente no cliente têm uma
servidor quando a identidade de pseudônimo. As identidades de pseudônimos são usadas na
identidade do privacidade de identidades, de modo que o identidade real ou permanente
pseudônimo de um usuário não seja revelada durante a autenticação.
estiver disponível
Habilitar uso de Fornece um local para digitação do nome do realm. Se esse campo for
realms deixado em branco com Habilitar uso de realms selecionado, o realm será
derivado da IMSI (Identidade do Assinante Móvel Internacional) usando o
realm 3gpp.org, conforme descrito no Project 3GPP (3GPP) padrão 23.003
V6.8.0.
Especificar um Fornece um local para digitar o nome do realm

realm
Definições de configuração do EAP-AKA
EAP-AKA para UMTS (Universal Mobile Telecommunications System) é usado na
distribuição de chaves de sessão e autenticação usando USIM (Universal Subscriber
Identity Module) UMTS. EAP-AKA é definido em RFC 4187.
A tabela a seguir lista as definições de configuração para EAP-AKA.
Item Descrição

identidade real no solicitações do servidor por identidade permanente no cliente têm uma
servidor quando a identidade de pseudônimo. As identidades de pseudônimos são usadas na
identidade do privacidade de identidades, de modo que o identidade real ou permanente
pseudônimo de um usuário não seja revelada durante a autenticação.
estiver disponível
V6.8.0.
Especificar um Fornece um local para digitação do nome do realm.

realm
Definições de configuração do EAP-AKA

EAP- AKA' é uma versão modificada de EAP-AKA, usada para conceder acesso a redes
com base em 3GPP usando padrões que não sejam 3GPP, como:
WiFi - às vezes chamada de fidelidade sem fio
EVDO (Evolution-Data Optimized)
WiMax (Worldwide Interoperability for Microwave Access)
EAP-AKA' é definido em RFC 5448.
A tabela a seguir lista as definições de configuração para EAP-AKA'.
Item Descrição
Item Descrição

identidade real solicitações do servidor por identidade permanente no cliente têm uma
no servidor identidade de pseudônimo. As identidades de pseudônimos são usadas na
quando a privacidade de identidades, de modo que o identidade real ou permanente
identidade do de um usuário não seja revelada durante a autenticação.
pseudônimo
estiver disponível
V6.8.0.
Especificar um Fornece um local para digitação do nome do realm.

realm
Ignorar O cliente compara o nome da rede conhecido com o nome enviado pelo
incompatibilidade servidor RADIUS durante a autenticação. Se houver incompatibilidade, ela
de nome de rede será ignorada se essa opção estiver selecionada. Se não estiver selecionada,
haverá falha de autenticação.
Habilitar Especifica que a reautenticação rápida está habilitada. Esse recurso é útil
Reautenticação quando a autenticação SIM é realizada com frequência. As chaves de
Rápida criptografia derivadas da autenticação completa são reutilizadas. Como
resultado, o algoritmo SIM não precisa ser executado em cada tentativa de
autenticação, e o número de operações de rede resultantes das tentativas
frequentes de autenticação é reduzido.
Recursos adicionais
Para obter informações adicionais sobre configurações sem fio autenticadas no Política
de Grupo, consulte Gerenciando a nova rede sem fio (IEEE 802.11) Políticas
Configurações
Para obter informações adicionais sobre configurações com fio autenticadas no Política
de Grupo, consulte Gerenciando as políticas de nova rede com fio (IEEE 802.3)
Configurações
Para obter informações sobre configurações avançadas para acesso com fio autenticado
e acesso sem fio autenticado, consulte Advanced Security Settings for Wired and
Wireless Network Policies.
Rede de alto desempenho (HPN)
aplica-se a: Windows server 2022, Windows server 2019, Azure Stack HCI, versões
21H2 e 20H2
Redes de alto desempenho (HPNs) desempenham uma função em requisitos de

processamento de dados em tempo real. Por exemplo, atividades como a replicação do
datacenter, a recuperação de desastres do datacenter e a computação distribuída de
alto desempenho exigem alta transferência de dados de volume e baixa latência de
rede. HPNs com recursos de conexão dinâmica tornam os recursos de rede de alto
desempenho mais acessíveis e gerenciáveis. Para saber mais, confira requisitos de rede
do host para Azure Stack HCI.
Os tópicos de rede de alto desempenho incluem:
Tecnologias de descarregamento e de otimização de rede
Recursos e tecnologias de SO (apenas software)
Recursos e tecnologias integrados a SH (software e hardware)
Tecnologias e recursos de HO (apenas hardware)
Propriedades avançadas de NIC
RSC no vSwitch
Tecnologias de descarregamento e
otimização de rede
Aplica-se a: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versões
21H2 e 20H2
Neste tópico, apresentamos uma visão geral dos diferentes recursos de

descarregaamento e otimização de rede disponíveis no Windows Server 2016 e
discutiremos como eles ajudam a tornar a rede mais eficiente. Essas tecnologias incluem
recursos e tecnologias so (somente software), recursos e tecnologias integrados de SH
(Software e Hardware) e tecnologias e recursos e tecnologias somente hardware (HO).
Para saber mais, confira Requisitos de rede de host para Azure Stack HCI.
As três categorias de recursos de rede disponíveis no Windows Server 2016 são:
1. Tecnologias e recursos somente de software (SO) : esses recursos são

implementados como parte do sistema operacional e são independentes das
NIC(s) subjacentes. Às vezes, esses recursos exigirão algum ajuste da NIC para uma
operação ideal. Exemplos disso incluem recursos do Hyper-V, como vmQoS, ACLs
e recursos não Hyper-V, como o NIC Teaming.
2. Recursos e tecnologias integrados de SOFTWARE e Hardware (SH) : esses recursos

têm componentes de software e hardware. O software está intimamente vinculado
aos recursos de hardware necessários para que o recurso funcione. Exemplos disso
incluem VMMQ, VMQ, Descarregado de Soma de Verificação IPv4 do lado de
envio e RSS.
3. Tecnologias e recursos de HO (Hardware Only) : essas acelerações de hardware

melhoram o desempenho de rede em conjunto com o software, mas não fazem
parte de nenhum recurso de software. Exemplos disso incluem Moderação de
interrupção, Flow controle e descarregamento de verificação IPv4 do lado do
recebimento.
4. Propriedades avançadas da NIC: você pode gerenciar NICs e todos os recursos por
meio Windows PowerShell usando o cmdlet NetAdapter. Você também pode
gerenciar NICs e todos os recursos usando Painel de Controle (ncpa.cpl).
 Dica
Os recursos e tecnologias do SO estão disponíveis em todas as arquiteturas
de hardware, independentemente da velocidade da NIC ou dos recursos de
NIC.
Os recursos sh e HO estão disponíveis somente quando o adaptador de rede

dá suporte aos recursos ou tecnologias.
Somente software (SO) recursos e
tecnologias
aplica-se a: Windows server 2022, Windows server 2019, Azure Stack HCI, versões
21H2 e 20H2
Os recursos somente de software são implementados como parte do sistema

operacional e são independentes das NIC (s) subjacentes. Às vezes, esses recursos
exigem algum ajuste da NIC para uma operação ideal. Exemplos disso incluem recursos
do Hyper-V, como vmQoS (qualidade de serviço) de máquina virtual, ACLs (listas de
controle de acesso) e recursos não Hyper-V como agrupamento NIC. Para saber mais,
confira requisitos de rede do host para Azure Stack HCI.
ACLs (Listas de Controle de Acesso)

Um recurso do Hyper-V e do SDNv1 para gerenciar a segurança de uma VM. Esse
recurso se aplica à pilha Hyper-V não virtualizada e à pilha HVNv1. Você pode gerenciar
ACLs de comutador Hyper-V por meio de cmdlets do PowerShell Add-
VMNetworkAdapterAcl e Remove-VMNetworkAdapterAcl .
ACLs estendidas
ACLs estendidas do comutador virtual do Hyper-V permitem que você configure as
ACLs de porta estendida do comutador virtual do Hyper-v para fornecer proteção de
firewall e impor políticas de segurança para as VMs de locatário em data centers. Como
as ACLs de porta são configuradas no comutador virtual do Hyper-V em vez de nas
VMs, o administrador pode gerenciar políticas de segurança para todos os locatários em
um ambiente multilocatário.
Você pode gerenciar ACLs estendidas do comutador Hyper-V por meio dos cmdlets do
PowerShell Add-VMNetworkAdapterExtendedAcl e Remove-
VMNetworkAdapterExtendedAcl .
 Dica
Esse recurso se aplica à pilha HNVv1. Para ACLs na pilha SDN, consulte ACLs de
rede definida pelo software SDN) abaixo.
Para obter mais informações sobre as listas de controle de acesso de porta estendida
nesta biblioteca, consulte criar políticas de segurança com listas de controle de acesso
de porta estendida.
Agrupamento NIC
O agrupamento NIC, também chamado de acoplamento NIC, é a agregação de várias
portas NIC em uma entidade que o host percebe como uma única porta NIC. O
agrupamento NIC protege contra a falha de uma única porta NIC (ou o cabo conectado
a ela). Ele também agrega o tráfego de rede para uma taxa de transferência mais rápida.
com Windows Server 2016 você tem duas maneiras de fazer o agrupamento:
1. solução de agrupamento Windows Server 2012
2. agrupamento de comutador inserido Windows Server 2016 (conjunto)
RSC no vSwitch
A União de segmento de recebimento (RSC) no vSwitch é um recurso que usa pacotes
que fazem parte do mesmo fluxo e chegam entre interrupções de rede e os une em um
único pacote antes de entregá-los ao sistema operacional. o comutador virtual no
Windows Server 2019 tem esse recurso. Para obter mais detalhes sobre esse recurso,
confira União de segmento de recebimento no vSwitch.
ACLs de SDN (rede definida pelo software)

a extensão SDN no Windows Server 2016 maneiras aprimoradas de dar suporte a ACLs.
na pilha Windows Server 2016 sdn v2, as acls de sdn são usadas em vez de acls e acls
estendidas. Você pode usar o controlador de rede para gerenciar ACLs de SDN.
QoS (Qualidade de Serviço) da SDN

a extensão SDN no Windows Server 2016 maneiras aprimoradas de fornecer controle de
largura de banda (reservas de egresso, limites de saída e limites de entrada) em uma
base de 5 tuplas. Normalmente, essas políticas são aplicadas no nível vNIC ou vmNIC,
mas você pode torná-las muito mais específicas. na pilha Windows Server 2016 sdn v2,
o sdn QoS é usado em vez de vmQoS. Você pode usar o controlador de rede para
gerenciar a QoS de SDN.
Alternar equipe inserida (SET)
O conjunto é uma solução de agrupamento NIC alternativa que você pode usar em
ambientes que incluem o Hyper-V e a pilha de SDN (rede definida pelo software) no
Windows Server 2016. O conjunto integra algumas funcionalidades de agrupamento
NIC ao comutador virtual Hyper-V. Para obter informações sobre o comutador
incorporado na biblioteca, consulte acesso remoto direto à memória (RDMA) e
comutador inserido de equipe (Set).
vRSS (Virtual Receive Side Scaling)

O vRSS de software é usado para distribuir o tráfego de entrada destinado a uma VM
entre vários processadores lógicos (LPs) da VM. O vRSS de software dá à VM a
capacidade de lidar com mais tráfego de rede do que um único LP seria capaz de lidar.
VmQoS (qualidade de serviço de máquina

virtual)
A qualidade de serviço da máquina virtual é um recurso do Hyper-V que permite que a
mudança defina limites no tráfego gerado por cada VM. Ele também permite que uma
VM Reserve uma quantidade de largura de banda na conexão de rede externa para que
uma VM não possa ficar sem nenhuma outra VM para largura de banda. na pilha
Windows Server 2016 sdn v2, o sdn QoS substitui vmQoS.
vmQoS pode definir limites de saída e reservas de saída. Você deve determinar o modo
de reserva de saída (peso relativo ou largura de banda absoluta) antes de criar o
comutador do Hyper-V.
Determine o modo de reserva de saída com o parâmetro –

MinimumBandwidthMode do cmdlet New-VMSwitch PowerShell.
Defina o valor do limite de saída com o parâmetro – MaximumBandwidth no

cmdlet Set-VMNetworkAdapter PowerShell.
Defina o valor da reserva de saída com um dos seguintes parâmetros do cmdlet

Set VMNetworkAdapter PowerShell:
Se o parâmetro – MinimumBandwidthMode no cmdlet New-VMSwitch for

absoluto, defina o parâmetro – MinimumBandwidthAbsolute no cmdlet Set
VMNetworkAdapter.
Se o parâmetro – MinimumBandwidthMode no cmdlet New-VMSwitch for
Weight, defina o parâmetro – MinimumBandwidthWeight no cmdlet Set
VMNetworkAdapter.
Devido às limitações no algoritmo usado para esse recurso, recomendamos que o peso
mais alto ou a largura de banda absoluta não seja superior a 20 vezes o peso mais baixo
ou a largura de banda absoluta. Se for necessário mais controle, considere usar a pilha
SDN e o recurso SDN-QoS.
Software e hardware (SH) integrado
recursos e tecnologias
21H2 e 20H2
Esses recursos têm componentes de software e hardware. O software está intimamente

vinculado aos recursos de hardware necessários para que o recurso funcione. Exemplos
deles incluem VMMQ, VMQ, Descarregamento de Soma de Verificação IPv4 do lado de
envio e RSS. Para saber mais, consulte os requisitos de rede de host para o Azure Stack
HCI.
 Dica
Os recursos de SH e HO estarão disponíveis se a NIC instalada der suporte a ele. As

descrições do recurso abaixo abordarão como informar se a NIC dá suporte ao
recurso.
NIC convergida
A NIC convergida é uma tecnologia que permite que NICs virtuais no host Hyper-V
exponham serviços RDMA a processos de host. Windows Server 2016 não requer mais
NICs separadas para RDMA. O recurso NIC Convergido permite que as NICs Virtuais na
partição host (vNICs) exponham o RDMA à partição de host e compartilhem a largura
de banda das NICs entre o tráfego RDMA e a VM e outro tráfego TCP/UDP de maneira
justa e gerenciável.
Você pode gerenciar a operação NIC convergida por meio do VMM ou Windows
PowerShell. Os cmdlets do PowerShell são os mesmos cmdlets usados para RDMA (veja
abaixo).
Para usar a funcionalidade de NIC convergida:
1. Certifique-se de configurar o host para DCB.
2. Certifique-se de habilitar o RDMA na NIC ou, no caso de uma equipe SET, as NICs
estão associadas ao comutador Hyper-V.
3. Certifique-se de habilitar o RDMA nos vNICs designados para RDMA no host.
Para obter mais detalhes sobre RDMA e SET, consulte RDMA (Acesso remoto direto à
memória) e set (agrupamento incorporado com comutador).
DCB (Data Center Bridging)

O DCB é um conjunto de padrões do Instituto de Engenheiros Elétricos e Eletrônicos
(IEEE) que habilitam malhas convergidas em data centers. O DCB fornece gerenciamento
de largura de banda baseado em fila de hardware em um host com cooperação do
comutador adjacente. Todo o tráfego para armazenamento, rede de dados, IPC
(comunicação Inter-Process cluster) e gerenciamento compartilham a mesma
infraestrutura de rede Ethernet. Em Windows Server 2016, o DCB pode ser aplicado a
qualquer NIC individualmente e NICs associadas ao comutador Hyper-V.
Para DCB, Windows Server usa o PFC (controle de Flow baseado em prioridade),
padronizado no IEEE 802.1Qbb. O PFC cria uma malha de rede (quase) sem perda
impedindo o estouro dentro das classes de tráfego. Windows Server também usa ETS
(Seleção de Transmissão Avançada), padronizada no IEEE 802.1Qaz. O ETS habilita a
divisão da largura de banda em partes reservadas para até oito classes de tráfego. Cada
classe de tráfego tem sua própria fila de transmissão e, por meio do uso do PFC, pode
iniciar e interromper a transmissão dentro de uma classe.

Versão Descrição
v1 Introduzido em Windows Server 2012, o HNV (Hyper-V Network Virtualization)

(HNVv1) permite a virtualização de redes de clientes, além de uma infraestrutura de rede física
compartilhada. Com o mínimo de alterações necessárias na malha de rede física, o
HNV dá aos provedores de serviços a agilidade para implantar e migrar cargas de
trabalho de locatário em qualquer lugar entre as três nuvens: a nuvem do provedor de
serviços, a nuvem privada ou a nuvem pública Microsoft Azure.
NVGRE Em Windows Server 2016 e System Center Virtual Machine Manager, a Microsoft
v2 fornece uma solução de virtualização de rede de ponta a ponta que inclui Gateway ras,
(HNVv2 balanceamento de carga de software, controlador de rede e muito mais. Para obter
NVGRE) mais informações, consulte a Visão geral da Virtualização de Rede do Hyper-V no
VxLAN No Windows Server 2016, faz parte da extensão SDN, que você gerencia por meio do
v2 Controlador de Rede.
(HNVv2
VxLAN)
IPsec Task Offload (IPsecTO)

O descarregamento de tarefas IPsec é um recurso nic que permite que o sistema
operacional use o processador na NIC para o trabalho de criptografia IPsec.
） Importante
O Descarregamento de Tarefas IPsec é uma tecnologia herdada que não tem

suporte da maioria dos adaptadores de rede e, onde ela existe, está desabilitada
por padrão.
PVLAN (Rede de Área Local Virtual Privada).
Os PVLANs permitem a comunicação somente entre máquinas virtuais no mesmo
servidor de virtualização. Uma rede virtual privada não está associada a um adaptador
de rede físico. Uma rede virtual privada é isolada de todo o tráfego de rede externa no
servidor de virtualização, bem como qualquer tráfego de rede entre o sistema
operacional de gerenciamento e a rede externa. Esse tipo de rede é útil quando você
precisa criar um ambiente isolado de rede, como um domínio de teste isolada. As pilhas
Hyper-V e SDN dão suporte apenas ao modo de porta isolada PVLAN.
Para obter detalhes sobre o isolamento PVLAN, consulte System Center: blog de
engenharia Virtual Machine Manager .
Acesso Remoto Direto à Memória (RDMA)

O RDMA é uma tecnologia de rede que fornece comunicação de baixa latência e alta
taxa de transferência, minimizando o uso da CPU. O RDMA dá suporte à rede de cópia
zero, permitindo que o adaptador de rede transfira dados diretamente para ou da
memória do aplicativo. Capaz de RDMA significa que a NIC (física ou virtual) é capaz de
expor RDMA a um cliente RDMA. Habilitado para RDMA, por outro lado, significa que
uma NIC compatível com RDMA está expondo a interface RDMA na pilha.
Para obter mais detalhes sobre RDMA, consulte RDMA (Acesso remoto direto à
memória) e alternância de agrupamento inserido (SET).
RSS (Receive Side Scaling)

O RSS é um recurso nic que separa diferentes conjuntos de fluxos e os entrega a
diferentes processadores para processamento. O RSS paraleliza o processamento de
rede, permitindo que um host seja dimensionado para taxas de dados muito altas.
Para obter mais detalhes, consulte o RSS (Receive Side Scaling).
Virtualização de Input-Output de raiz única

(SR-IOV)
O SR-IOV permite que o tráfego de VM se mova diretamente da NIC para a VM sem
passar pelo host Hyper-V. SR-IOV é uma melhoria incrível no desempenho de uma VM,
mas não tem a capacidade do host de gerenciar esse pipe. Use apenas SR-IOV quando a
carga de trabalho for bem comportada, confiável e geralmente a única VM no host.
O tráfego que usa SR-IOV ignora o comutador Hyper-V, o que significa que quaisquer
políticas, por exemplo, ACLs ou gerenciamento de largura de banda não serão
aplicadas. O tráfego SR-IOV também não pode ser passado por nenhuma
funcionalidade de virtualização de rede, portanto, o encapsulamento NV-GRE ou VxLAN
não pode ser aplicado. Use apenas SR-IOV para cargas de trabalho bem confiáveis em
situações específicas. Além disso, você não pode usar as políticas de host, o
gerenciamento de largura de banda e as tecnologias de virtualização.
No futuro, duas tecnologias permitiriam SR-IOV: GFT (Generic Flow Tables) e Hardware
QoS Offload (gerenciamento de largura de banda na NIC) – uma vez que as NICs em
nosso ecossistema dão suporte a elas. A combinação dessas duas tecnologias tornaria o
SR-IOV útil para todas as VMs, permitiria que políticas, virtualização e regras de
gerenciamento de largura de banda fossem aplicadas e poderia resultar em grandes
avanços na aplicação geral do SR-IOV.
Para obter mais detalhes, consulte Visão geral da Virtualização de E/S de Raiz Única (SR-
IOV).
Descarregamento de chaminé TCP

O descarregamento de chaminé TCP, também conhecido como TOE (descarregamento
do mecanismo TCP), é uma tecnologia que permite ao host descarregar todo o
processamento TCP para a NIC. Como a pilha TCP do servidor Windows é quase sempre
mais eficiente do que o mecanismo TOE, não é recomendável usar o Descarregamento
de Chaminé TCP.
） Importante
O Descarregamento de Chaminé TCP é uma tecnologia preterida. Recomendamos

que você não use o Descarregamento de Chaminé TCP, pois a Microsoft pode parar
de dar suporte a ele no futuro.
VLAN (Virtual Local Area Network)

A VLAN é uma extensão para o cabeçalho do quadro Ethernet para habilitar o
particionamento de uma LAN em vários VLANs, cada um usando seu próprio espaço de
endereço. Em Windows Server 2016, os VLANs são definidos em portas do comutador
Hyper-V ou definindo interfaces de equipe em equipes de agrupamento nic.
VMQ (Fila de Máquina Virtual)
O VMQs é um recurso nic que aloca uma fila para cada VM. Sempre que você tiver o
Hyper-V habilitado; você também deve habilitar o VMQ. Em Windows Server 2016, as
VMQs usam vPorts do NIC Switch com uma única fila atribuída ao vPort para fornecer a
mesma funcionalidade.
VMMQ (VMMQ)
O VMMQ é um recurso nic que permite que o tráfego de uma VM se espalhe por várias
filas, cada uma processada por um processador físico diferente. Em seguida, o tráfego é
passado para vários LPs na VM como seria no vRSS, o que permite fornecer largura de
banda de rede substancial para a VM.
Tecnologias e recursos do hardware
apenas (HO)
21H2 e 20H2
Essas acelerações de hardware melhoram o desempenho de rede em conjunto com o

software, mas não fazem parte de nenhum recurso de software. Exemplos disso incluem
Moderação de interrupção, Flow controle e descarregamento de verificação IPv4 do
lado do recebimento. Para saber mais, confira Requisitos de rede de host para Azure
Stack HCI.
 Dica
Os recursos SH e HO estarão disponíveis se a NIC instalada for compatível com ele.

As descrições do recurso abaixo abrangem como saber se a NIC dá suporte ao
recurso.
Descarregado da verificação de endereço

Descarregas de verificação de endereço são um recurso de NIC que descarrega o
cálculo de verificações de endereço (IP, TCP, UDP) para o hardware NIC para enviar e
receber.
No caminho de recebimento, o descarregamento de verificação calcula as verificações

nos headers IP, TCP e UDP (conforme apropriado) e indica ao sistema operacional se as
verificações foram aprovadas, falharam ou não foram verificadas. Se a NIC declarar que
as verificações são válidas, o sistema operacional aceitará o pacote sem desafio. Se a
NIC declarar que as verificações são inválidas ou não marcadas, a pilha IP/TCP/UDP
calcula internamente as verificações novamente. Se a verificação computada falhar, o
pacote será descartado.
No caminho de envio, a carga de verificação calcula e insere as verificações no header

IP, TCP ou UDP, conforme apropriado.
Desabilitar descarregamentos de verificação no caminho de envio não desabilita o

cálculo e a inserção de verificação para pacotes enviados ao driver de miniporte usando
o recurso LSO (Descarregamento de Envio Grande). Para desabilitar todos os cálculos
de descarrega de carga de verificação, o usuário também deve desabilitar o LSO.
Gerenciar descarregas de verificação de endereço
Nas Propriedades Avançadas, há várias propriedades distintas:
Descarregado de carga de verificação de IPv4
Descarregado de verificação TCP (IPv4)
Descarregado de verificação TCP (IPv6)
Descarrega do UDP Checksum (IPv4)
Descarregado de verificação UDP (IPv6)
Por padrão, todos eles estão sempre habilitados. É recomendável sempre habilenciar
todos esses descarregamentos.
Os Descarregadores de Verificação podem ser gerenciados usando os cmdlets Enable-

NetAdapterChecksumOffload e Disable-NetAdapterChecksumOffload de verificação. Por
exemplo, o cmdlet a seguir habilita os cálculos de verificação TCP (IPv4) e UDP (IPv4) :
PowerShell
Enable-NetAdapterChecksumOffload –Name * -TcpIPv4 -UdpIPv4
Dicas sobre como usar descarregas de verificação de endereço
Descarregas de verificação de endereço devem ser sempre habilitados

independentemente da carga de trabalho ou da circunstância. Isso é mais básico de
todas as tecnologias de descarregada sempre melhoram o desempenho da rede. O
descarregamento de soma de verificação também é necessário para que outros
descarregamentos sem estado funcionem, incluindo RSS (escala lateral de recebimento),
RSC (união de segmento de recebimento) e LSO (descarregamento de envio grande).
Moderação de interrupção (IM)

O IM em buffer de vários pacotes recebidos antes de interromper o sistema operacional.
Quando uma NIC recebe um pacote, ela inicia um temporizador. Quando o buffer
estiver cheio ou o temporizador expirar, o que ocorrer primeiro, a NIC interromperá o
sistema operacional.
Muitas NICs são mais do que apenas on/off para Moderação de Interrupção. A maioria
das NICs suporta os conceitos de uma taxa baixa, média e alta para IM. As diferentes
taxas representam temporizadores mais curtos ou mais longos e ajustes de tamanho de
buffer apropriados para reduzir a latência (baixa moderação de interrupção) ou reduzir
interrupções (moderação de interrupção alta).
Há um equilíbrio entre reduzir interrupções e atrasar excessivamente a entrega de

pacotes. Em geral, o processamento de pacotes é mais eficiente com a Moderação de
Interrupção habilitada. Aplicativos de alto desempenho ou baixa latência podem
precisar avaliar o impacto da desabilitação ou redução da Moderação de Interrupção.
Quadros jumbo
Frames Dols é um recurso de rede e NIC que permite que um aplicativo envie quadros
muito maiores do que os 1500 bytes padrão. Normalmente, o limite em quadros de
frames do Frames é de cerca de 9.000 bytes, mas pode ser menor.
Não houve nenhuma alteração no suporte a quadros de quadro no Windows Server

2012 R2.
No Windows Server 2016 há um novo descarregado: MTU_for_HNV. Esse novo

descarregamento funciona com as configurações de Frame do York para garantir que o
tráfego encapsulado não requer segmentação entre o host e o computação adjacente.
Esse novo recurso da pilha SDN faz com que a NIC calcule automaticamente qual MTU
anunciar e qual MTU usar na transmissão. Esses valores para MTU serão diferentes se
qualquer descarregado de HNV estiver em uso. (Na tabela de compatibilidade de
recursos, Tabela 1, MTU_for_HNV teria as mesmas interações que os descarregados
HNVv2, pois ele está diretamente relacionado às descarregadas HNVv2.)
LSO (Descarregamento de Envio Grande)

O LSO permite que um aplicativo passe um grande bloco de dados para a NIC e a NIC
divide os dados em pacotes que se ajustam à MTU (Unidade de Transferência Máxima)
da rede.
Receive Segment Coalescing (RSC)

O Receive Segment Coalescing, também conhecido como Descarregamento de
Recebimento Grande, é um recurso de NIC que aceita pacotes que fazem parte do
mesmo fluxo que chega entre interrupções de rede e os coaliza em um único pacote
antes de forneciá-los ao sistema operacional. A RSC não está disponível em NICs que
estão vinculadas ao Com switch virtual do Hyper-V. Para obter mais informações,
consulte RSC (Coalescing de Segmento de Recebimento).
As propriedades avançadas de NIC
21H2 e 20H2
Você pode gerenciar NICs e todos os recursos por meio de Windows PowerShell usando
o cmdlet NetAdapter. Você também pode gerenciar NICs e todos os recursos usando
Painel de Controle de rede (ncpa.cpl). Para saber mais, confira os requisitos de rede do
host para o Azure Stack HCI.
1. Em Windows PowerShell, execute o Get‑NetAdapterAdvancedProperty cmdlet em

dois modelos/criação diferentes de NICs.
Há semelhanças e diferenças nessas duas Listas de Propriedades Avançadas da

NIC.
2. No Painel de Controle de Rede (ncpa.cpl), faça o seguinte:
a. Clique com o botão direito do mouse na NIC.
b. Na caixa de diálogo Propriedades, clique em Configurar.
c. Clique na guia Avançado para exibir as propriedades avançadas.
Os itens nesta lista se correlacionam com os itens na Get-

NetAdapterAdvancedProperties saída.
RSC no vSwitch
21H2 e 20H2
O RSC (Receive Segment Coalescing) no vSwitch é um recurso no Windows Server 2019

e no Atualização de outubro de 2018 para o Windows 10 que ajuda a reduzir a
utilização da CPU do host e aumenta a taxa de transferência para cargas de trabalho
virtuais por meio da conciliação de vários segmentos TCP em menos segmentos, mas
em segmentos maiores. O processamento de menos segmentos grandes (coalesced) é
mais eficiente do que processar vários segmentos pequenos. Para saber mais, confira
Requisitos de rede de host para Azure Stack HCI.
Windows Server 2012 e posterior incluíram uma versão de descarregamento somente

de hardware (implementada no adaptador de rede física) da tecnologia também
conhecida como Coalescing de Segmento de Recebimento. Essa versão descarregada
do RSC ainda está disponível em versões posteriores do Windows. No entanto, ele é
incompatível com cargas de trabalho virtuais e foi desabilitado depois que um
adaptador de rede física é anexado a um vSwitch. Para obter mais informações sobre a
versão somente de hardware do RSC, consulte RSC (Coalescing de Segmento de
Recebimento).
Cenários que se beneficiam da RSC no vSwitch

As cargas de trabalho cujo caminho de dados atravessa um comu switch virtual se
beneficiam desse recurso.
Por exemplo:
NICs virtuais de host, incluindo:
Host do Hyper-V
Espaços de Armazenamento Direct
NICs virtuais convidadas do Hyper-V
Gateways gre de rede definidos pelo software

Contêiner
As cargas de trabalho que não são compatíveis com esse recurso incluem:
Gateways IPSEC de rede definidos pelo software
NICs virtuais habilitadas para SR-IOV
SMB Direct
Configurar a RSC no vSwitch

Por padrão, no vSwitches externo, a RSC está habilitada.
Veja as configurações atuais:
PowerShell
Get-VMSwitch -Name vSwitchName | Select-Object *RSC*
Habilitar ou desabilitar a RSC no vSwitch
） Importante
Importante: a RSC no vSwitch pode ser habilitada e desabilitada em tempo real

sem afetar as conexões existentes.
Desabilitar a RSC no vSwitch
PowerShell
Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $false
Habilitar a RSC no vSwitch
PowerShell
Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $True
Para obter mais informações, consulte Set-VMSwitch.

API de serviço HCN (rede de
computação de host) para VMs e
contêineres
Aplica-se a: Windows Server 2022, Windows Server 2019
A API de serviço da HCN (Rede de Computação de Host) é uma API do Win32 que
fornece acesso no nível da plataforma para gerenciar as redes virtuais, pontos de
extremidade virtuais e políticas associadas. juntos, isso fornece conectividade e
segurança para VMs (máquinas virtuais) e contêineres em execução em um host
Windows.
Os desenvolvedores usam a API de serviço HCN para gerenciar a rede para VMs e
contêineres em seus fluxos de trabalho de aplicativo. A API HCN foi projetada para
fornecer a melhor experiência para os desenvolvedores. Os usuários finais não
interagem diretamente com essas APIs.
Recursos da API do serviço HCN

Implementada como C API hospedada pelo serviço de rede do host (HNS) no
Oncore/VM.
Fornece a capacidade de criar, modificar, excluir e enumerar objetos HCN, como

redes, pontos de extremidade, namespaces e políticas. As operações são
executadas em identificadores para os objetos (por exemplo, um identificador de
rede) e internamente esses identificadores são implementados usando
identificadores de contexto RPC.
Baseado em esquema. A maioria das funções da API definem parâmetros de

entrada e saída como cadeias de caracteres que contêm os argumentos da
chamada de função como documentos JSON. Os documentos JSON são baseados
em esquemas com controle de versão e fortemente tipados, esses esquemas
fazem parte da documentação pública.
Uma API de assinatura/retorno de chamada é fornecida para permitir que os

clientes se registrem para notificações de eventos de todo o serviço, como as
exclusões e criações de rede.
a API do HCN funciona em aplicativos Ponte de Desktop (conhecido como
Centennial) em execução nos serviços do sistema. A API verifica a ACL recuperando
o token do usuário do chamador.
 Dica
A API do serviço HCN tem suporte em tarefas em segundo plano e em janelas que
não são de primeiro plano.
Terminologia: host versus computação

O serviço de computação do host permite que os chamadores criem e gerenciem
máquinas virtuais e contêineres em um único computador físico. Ele é nomeado para
seguir a terminologia do setor.
O host é amplamente usado no setor de virtualização para se referir ao sistema

operacional que fornece recursos virtualizados.
A computação é usada para se referir a métodos de virtualização mais amplos do

que apenas máquinas virtuais. O serviço de rede de computação do host permite
que os chamadores criem e gerenciem a rede para máquinas virtuais e contêineres
em um único computador físico.
Documentos de configuração baseados em

esquema
Os documentos de configuração baseados em esquemas bem definidos são um padrão
industrial estabelecido no espaço de virtualização. A maioria das soluções de
virtualização, como Docker e kubernetes, fornece APIs baseadas em documentos de
configuração. Várias iniciativas do setor, com a participação da Microsoft, orientam um
ecossistema para definir e validar esses esquemas, como openapi . Essas iniciativas
também orientam a padronização de definições de esquema específicas para os
esquemas usados para contêineres, como o OCI (Open container Initiative) .
O idioma usado para criar documentos de configuração é JSON , que você usa em
combinação com:
Definições de esquema que definem um modelo de objeto para o documento

Validação de se um documento JSON está em conformidade com um esquema
Conversão automatizada de documentos JSON de e para representações nativas
desses esquemas nas linguagens de programação usadas pelos chamadores das
APIs
As definições de esquema usadas com frequência são openapi e esquema JSON ,

que permite especificar as definições detalhadas das propriedades em um documento,
por exemplo:
O conjunto válido de valores para uma propriedade, como 0-100 para uma
propriedade que representa uma porcentagem.
A definição de enumerações, que são representadas como um conjunto de cadeias
de caracteres válidas para uma propriedade.
Uma expressão regular para o formato esperado de uma cadeia de caracteres.
Como parte da documentação das APIs do HCN, estamos planejando publicar o

esquema de nossos documentos JSON como uma especificação OpenAPI. Com base
nessa especificação, representações específicas de idioma do esquema podem permitir
o uso seguro de tipo dos objetos de esquema na linguagem de programação usada
pelo cliente.
Exemplo
Veja a seguir um exemplo desse fluxo de trabalho para o objeto que representa um
controlador SCSI no documento de configuração de uma VM.
enum IpamType
[NewIn("2.0")] Static,
[NewIn("2.0")] Dhcp,
};
class Ipam
// Type : dhcp
[NewIn("2.0"),OmitEmpty] IpamType Type;
[NewIn("2.0"),OmitEmpty] Subnet Subnets[];
};
class Subnet : HCN.Schema.Common.Base
[NewIn("2.0"),OmitEmpty] string IpAddressPrefix;
[NewIn("2.0"),OmitEmpty] SubnetPolicy Policies[];
[NewIn("2.0"),OmitEmpty] Route Routes[];
};
enum SubnetPolicyType
[NewIn("2.0")] VLAN
};
class SubnetPolicy
[NewIn("2.0"),OmitEmpty] SubnetPolicyType Type;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Common.PolicySettings Data;
};
class PolicySettings
[NewIn("2.0"),OmitEmpty] string Name;
};
class VlanPolicy : HCN.Schema.Common.PolicySettings
[NewIn("2.0")] uint32 IsolationId;
};
class Route
[NewIn("2.0"),OmitEmpty] string NextHop;
[NewIn("2.0"),OmitEmpty] string DestinationPrefix;
[NewIn("2.0"),OmitEmpty] uint16 Metric;
};
 Dica
As anotações [NewIn ("2.0") fazem parte do suporte de controle de versão para as

definições de esquema.
A partir desta definição interna, geramos as especificações
de OpenAPI para o esquema:
"swagger" : "2.0",
"info" : {
"version" : "2.1",
"title" : "HCN API"
},
"definitions": {
"Ipam": {
"type": "object",
"properties": {
"Type": {
"type": "string",
"enum": [
"Static",
"Dhcp"
],
"description": " Type : dhcp"
},
"Subnets": {
"type": "array",
"items": {
"$ref": "#/definitions/Subnet"
},
"Subnet": {
"type": "object",
"properties": {
"ID": {
"type": "string",
"pattern": "^[0-9A-Fa-f]{8}-([0-9A-Fa-f]{4}-){3}[0-9A-
Fa-f]{12}$"
},
"IpAddressPrefix": {
"type": "string"
},
"Policies": {
"type": "array",
"items": {
"$ref": "#/definitions/SubnetPolicy"
},
"Routes": {
"type": "array",
"items": {
"$ref": "#/definitions/Route"
},
"SubnetPolicy": {
"type": "object",
"properties": {
"Type": {
"type": "string",
"enum": [
"VLAN",
"VSID"
},
"Data": {
"$ref": "#/definitions/PolicySettings"
},
"PolicySettings": {
"type": "object",
"properties": {
"Name": {
"type": "string"
},
"VlanPolicy": {
"type": "object",
"properties": {
"Name": {
"type": "string"
},
"IsolationId": {
"type": "integer",
"format": "uint32"
},
"Route": {
"type": "object",
"properties": {
"NextHop": {
"type": "string"
},
"DestinationPrefix": {
"type": "string"
},
"Metric": {
"type": "integer",
"format": "uint16"
Você pode usar ferramentas, como o Swagger , para gerar representações específicas
de idioma da linguagem de programação de esquema usada por um cliente. O Swagger
dá suporte a uma variedade de linguagens, como C#, go, JavaScript e Python.
exemplo de código C# gerado para o objeto de IPAM de nível superior da sub-

rede.
exemplo de código Go gerado para o objeto de IPAM de sub-rede de nível

superior. Go é usado pelo Docker e kubernetes, que são dois dos consumidores
das APIs de serviço de rede de computação do host. O Go tem suporte interno
para empacotamento de tipos Go de e para documentos JSON.
além da geração de código e da validação, você pode usar ferramentas para simplificar
o trabalho com documentos JSON, ou seja, Visual Studio Code .
Objetos de nível superior definidos no esquema HCN

Os objetos de nível superior são:
HostComputeNetwork
HostComputeEndpoint
HostComputeNamespace
HostComputeLoadBalancer
class HostComputeNetwork : HCN.Schema.Common.Base
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.NetworkMode Type;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.NetworkPolicy
Policies[];
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.MacPool
MacPool;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.DNS Dns;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.Ipam
Ipams[];
};
class HostComputeEndpoint : HCN.Schema.Common.Base
[NewIn("2.0"),OmitEmpty] string
HostComputeNetwork;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.Endpoint.EndpointPolicy
Policies[];
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.Endpoint.IpConfig
IpConfigurations[];
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.DNS Dns;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Network.Route
Routes[];
[NewIn("2.0"),OmitEmpty] string
MacAddress;
};
class HostComputeNamespace : HCN.Schema.Common.Base
[NewIn("2.0"),OmitEmpty] uint32
NamespaceId;
[NewIn("2.0"),OmitEmpty] Guid
NamespaceGuid;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Namespace.NamespaceType Type;
[NewIn("2.0"),OmitEmpty] HCN.Schema.Namespace.NamespaceResource
Resources[];
};
class HostComputeLoadBalancer : HCN.Schema.Common.Base
[NewIn("2.0"), OmitEmpty] string

HostComputeEndpoints[];
[NewIn("2.0"), OmitEmpty] string

VirtualIPs[];
[NewIn("2.0"), OmitEmpty]
HCN.Schema.Network.Endpoint.Policy.PortMappingPolicy PortMappings[];
[NewIn("2.0"), OmitEmpty] HCN.Schema.LoadBalancer.LoadBalancerPolicy

Policies[];
};
Próximas etapas
Saiba mais sobre os cenários comuns de HCN.
Saiba mais sobre os identificadores de contexto RPC para HCN.
Saiba mais sobre os esquemas de documento JSON HCN.

Cenários comuns
Cenário: HCN
Criar um HCN
Este exemplo mostra como usar a API do Serviço de Rede de Computação de Host para
criar uma Rede de Computação de Host no host que pode ser usada para conectar a
NICS Virtual a Máquinas Virtuais ou contêineres.
C++
using unique_hcn_network = wil::unique_any<
HCN_NETWORK,
decltype(&HcnCloseNetwork),
HcnCloseNetwork>;
/// Creates a simple HCN Network, waiting synchronously to finish the task
void CreateHcnNetwork()
unique_hcn_network hcnnetwork;
wil::unique_cotaskmem_string result;
std::wstring settings = LR"(
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "WDAGNetwork",
"Flags" : 0,
"Type" : 0,
"Ipams" : [
"Type" : 0,
"Subnets" : [
"IpAddressPrefix" : "192.168.1.0/24",
"Policies" : [
"Type" : "VLAN",
"IsolationId" : 100,
],
"Routes" : [
"NextHop" : "192.168.1.1",
"DestinationPrefix" : "0.0.0.0/0",
],
},
],
"MacPool": {
"Ranges" : [
"EndMacAddress": "00-15-5D-52-CF-FF",
"StartMacAddress": "00-15-5D-52-C0-00"
],
},
"Dns" : {
"Suffix" : "net.home",
"ServerList" : ["10.0.0.10"],
})";
GUID networkGuid;
HRESULT result = CoCreateGuid(&networkGuid);
result = HcnCreateNetwork(
networkGuid, // Unique ID
settings.c_str(), // Compute system settings document

&hcnnetwork,
&result
);
if (FAILED(result))
// UnMarshal the result Json
// ErrorSchema
// {
// "ErrorCode" : <uint32>,
// "Error" : <string>,
// "Success" : <bool>,
// }
// Failed to create network
THROW_HR(result);
// Close the Handle
result = HcnCloseNetwork(hcnnetwork.get());
if (FAILED(result))
THROW_HR(result);
Excluir um HCN
abrir & a exclusão de uma rede de computação de host
C++
wil::unique_cotaskmem_string errorRecord;
GUID networkGuid; // Initialize it to appropriate network guid value
HRESULT hr = HcnDeleteNetwork(networkGuid, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
Enumerar todas as redes

enumerar todas as redes de computação de host.
C++
wil::unique_cotaskmem_string resultNetworks;
// Filter to select Networks based on properties
std::wstring filter [] = LR"(
"Name" : "WDAG",
})";
HRESULT result = HcnEnumerateNetworks(filter.c_str(), &resultNetworks,

&errorRecord);
if (FAILED(result))
THROW_HR(result);
Propriedades da rede de consulta

consultar propriedades de rede.
C++
wil::unique_cotaskmem_string properties;
std:wstring query = LR"(
// Future
})";
GUID networkGuid; // Initialize it to appropriate network guid value
HRESULT hr = HcnOpenNetwork(networkGuid, &hcnnetwork, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
hr = HcnQueryNetworkProperties(hcnnetwork.get(), query.c_str(),
&properties, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
Cenário: ponto de extremidade HCN
Criar um ponto de extremidade HCN

criar um ponto de extremidade de rede de computação de host e, em seguida,
adicioná-lo à Máquina Virtual ou a um Contêiner.
C++
using unique_hcn_endpoint = wil::unique_any<
HCN_ENDPOINT,
decltype(&HcnCloseEndpoint),
HcnCloseEndpoint>;
void CreateAndHotAddEndpoint()
unique_hcn_endpoint hcnendpoint;
std::wstring settings[] = LR"(
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "Sample",
"Flags" : 0,
"HostComputeNetwork" : "87fdcf16-d210-426e-959d-2a1d4f41d6d3",
"DNS" : {
"Suffix" : "net.home",
"ServerList" : "10.0.0.10",
})";
GUID endpointGuid;
HRESULT result = CoCreateGuid(&endpointGuid);
result = HcnOpenNetwork(
networkGuid, // Unique ID
&hcnnetwork,
&errorRecord
);
if (FAILED(result))
// Failed to find network

THROW_HR(result);
result = HcnCreateEndpoint(
hcnnetwork.get(),
endpointGuid, // Unique ID

&hcnendpoint,
&errorRecord
);
if (FAILED(result))
// Failed to create endpoint
THROW_HR(result);
// Can use the sample from HCS API Spec on how to attach this endpoint
// to the VM using AddNetworkAdapterToVm
result = HcnCloseEndpoint(hcnendpoint.get());
if (FAILED(result))
THROW_HR(result);
Excluir um ponto de extremidade

excluir um ponto de extremidade de rede de computação de host.
C++
GUID endpointGuid; // Initialize it to appropriate endpoint guid value
HRESULT hr = HcnDeleteEndpoint(endpointGuid, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
Modificar um ponto de extremidade

modificar um ponto de extremidade de rede de computação de host.
C++
HRESULT hr = HcnOpenEndpoint(endpointGuid, &hcnendpoint, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
std::wstring ModifySettingAddPortJson = LR"(
"ResourceType" : 0,
"RequestType" : 0,
"Settings" : {
"PortName" : "acbd341a-ec08-44c0-9d5e-61af0ee86902"
"VirtualNicName" : "641313e1-7ae8-4ddb-94e5-3215f3a0b218-
-87fdcf16-d210-426e-959d-2a1d4f41d6d1"
"VirtualMachineId" : "641313e1-7ae8-4ddb-94e5-3215f3a0b218"
)";
hr = HcnModifyEndpoint(hcnendpoint.get(),
ModifySettingAddPortJson.c_str(), &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
Enumerar todos os pontos de extremidade

enumerar todos os pontos de extremidade de rede de computação de host.
C++
wil::unique_cotaskmem_string resultEndpoints;
// Filter to select Endpoint based on properties
"Name" : "sampleNetwork",
})";
result = HcnEnumerateEndpoints(filter.c_str(), &resultEndpoints,

&errorRecord);
if (FAILED(result))
THROW_HR(result);
Propriedades do ponto de extremidade de consulta

consultar todas as propriedades de um ponto de extremidade de rede de computação
de host.
C++
HRESULT hr = HcnOpenEndpoint(endpointGuid, &hcnendpoint, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
// Future
})";
hr = HcnQueryEndpointProperties(hcnendpoint.get(), query.c_str(),
if (FAILED(hr))
// UnMarshal the errorRecord Json
THROW_HR(hr);
Cenário: namespace HCN
Criar um namespace HCN

criar um Namespace de Rede de Computação de Host no host que pode ser usado para
conectar Ponto de Extremidade e Contêineres.
C++
using unique_hcn_namespace = wil::unique_any<
HCN_NAMESPACE,
decltype(&HcnCloseNamespace),
HcnCloseNamespace>;
/// Creates a simple HCN Network, waiting synchronously to finish the task
void CreateHcnNamespace()
unique_hcn_namespace handle;
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "Sample",
"Flags" : 0,
"Type" : 0,
})";
GUID namespaceGuid;
HRESULT result = CoCreateGuid(&namespaceGuid);
result = HcnCreateNamespace(
namespaceGuid, // Unique ID

&handle,
&errorRecord
);
if (FAILED(result))
// ErrorSchema
// {
// }
THROW_HR(result);
result = HcnCloseNamespace(handle.get());
if (FAILED(result))
THROW_HR(result);
Excluir um namespace HCN

excluir um Namespace de Rede de Computação de Host.
C++
GUID namespaceGuid; // Initialize it to appropriate namespace guid value
HRESULT hr = HcnDeleteNamespace(namespaceGuid, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
Modificar um namespace HCN

modificar um Namespace de Rede de Computação de Host.
C++
HRESULT hr = HcnOpenNamespace(namespaceGuid, &handle, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
static std::wstring ModifySettingAddEndpointJson = LR"(
"ResourceType" : 1,
"RequestType" : 0,
"Settings" : {
"EndpointId" : "87fdcf16-d210-426e-959d-2a1d4f41d6d1"
)";
hr = HcnModifyNamespace(handle.get(),
ModifySettingAddEndpointJson.c_str(), &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
hr = HcnCloseNamespace(handle.get());
if (FAILED(hr))
THROW_HR(hr);
Enumerar todos os namespaces

enumerar todos os Namespaces de Rede de Computação de Host.
C++
wil::unique_cotaskmem_string resultNamespaces;
// Future
})";
HRESULT hr = HcnEnumerateNamespace(filter.c_str(), &resultNamespaces,

&errorRecord);
if (FAILED(hr))
THROW_HR(hr);
Propriedades do namespace de consulta

consultar as propriedades do Namespace de Rede de Computação de Host
C++
HRESULT hr = HcnOpenNamespace(namespaceGuid, &handle, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
// Future
})";
HRESULT hr = HcnQueryNamespaceProperties(handle.get(), query.c_str(),

if (FAILED(hr))
THROW_HR(hr);
Cenário: Balanceador de carga HCN
Criar um balanceador de carga HCN

criar uma rede de computação de host Load Balancer no host que pode ser usada para
balancear a carga do Ponto de Extremidade entre a computação.
C++
using unique_hcn_loadbalancer = wil::unique_any<
HCN_LOADBALANCER,
decltype(&HcnCloseLoadBalancer),
HcnCloseLoadBalancer>;
/// Creates a simple HCN LoadBalancer, waiting synchronously to finish the

task
void CreateHcnLoadBalancer()
unique_hcn_loadbalancer handle;
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "Sample",
"HostComputeEndpoints" : [
"87fdcf16-d210-426e-959d-2a1d4f41d6d1"
],
"VirtualIPs" : [ "10.0.0.10" ],
"PortMappings" : [
"Protocol" : 0,
"InternalPort" : 8080,
"ExternalPort" : 80,
],
"EnableDirectServerReturn" : true,
"InternalLoadBalancer" : false,
)";
GUID lbGuid;
HRESULT result = CoCreateGuid(&lbGuid);
HRESULT hr = HcnCreateLoadBalancer(
lbGuid, // Unique ID
settings.c_str(), // LoadBalancer settings document
&handle,
&errorRecord
);
if (FAILED(hr))
// ErrorSchema
// {
// }
THROW_HR(hr);
hr = HcnCloseLoadBalancer(handle.get());
if (FAILED(hr))
THROW_HR(hr);
Excluir um balanceador de carga HCN

excluir um Load Balancer de Rede de Computação de Host.
C++
GUID lbGuid; // Initialize it to appropriate loadbalancer guid value
HRESULT hr = HcnDeleteLoadBalancer(lbGuid , &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
Modificar um balanceador de carga HCN

modificar uma rede de computação de host Load Balancer.
C++
HRESULT hr = HcnOpenLoadBalancer(lbGuid, &handle, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
static std::wstring ModifySettingAddEndpointJson = LR"(
"ResourceType" : 1,
"RequestType" : 0,
"Settings" : {
"EndpointId" : "87fdcf16-d210-426e-959d-2a1d4f41d6d1"
)";
hr = HcnModifyLoadBalancer(handle.get(),
ModifySettingAddEndpointJson.c_str(), &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
hr = HcnCloseLoadBalancer(handle.get());
if (FAILED(hr))
THROW_HR(hr);
Enumerar todos os balanceadores de carga

enumerar todos os Load Balancer de Rede de Computação de Host.
C++
wil::unique_cotaskmem_string resultLoadBalancers;
// Future
})";
HRESULT result = HcnEnumerateLoadBalancers(filter.c_str(), &

resultLoadbalancers, &errorRecord);
if (FAILED(result))
THROW_HR(result);
Propriedades do balanceador de carga de consulta

consultar propriedades de rede de computação de host Load Balancer.
C++
HRESULT hr = HcnOpenLoadBalancer(lbGuid, &handle, &errorRecord);
if (FAILED(hr))
THROW_HR(hr);
"ID" : "",
"Type" : 0,
})";
hr = HcnQueryNProperties(handle.get(), query.c_str(), &properties,

&errorRecord);
if (FAILED(hr))
THROW_HR(hr);
Cenário: Notificações de HCN
Registrar e cancelar o registro de notificações em todo o

serviço
Este exemplo demonstra como usar a API do Serviço de Rede de Computação de Host
para registrar e cancelar o registro de notificações em todo o serviço. Isso permite que o
chamador receba uma notificação (por meio da função de retorno de chamada
especificada durante o registro) sempre que ocorreu uma operação em todo o serviço,
como um novo evento de criação de rede.
C++
using unique_hcn_callback = wil::unique_any<
HCN_CALLBACK,
decltype(&HcnUnregisterServiceCallback),
HcnUnregisterServiceCallback>;
// Callback handle returned by registration api. Kept at
// global or module scope as it will automatically be
// unregistered when it goes out of scope.
unique_hcn_callback g_Callback;
// Event notification callback function.
void
CALLBACK
ServiceCallback(
DWORD NotificationType,
void* Context,
HRESULT NotificationStatus,
PCWSTR NotificationData)
// Optional client context
UNREFERENCED_PARAMETER(context);
// Reserved for future use
UNREFERENCED_PARAMETER(NotificationStatus);
switch (NotificationType)
case HcnNotificationNetworkCreate:
// TODO: UnMarshal the NotificationData
//
// // Notification
// {
// "ID" : Guid,
// "Flags" : <uint32>,
// };
break;
case HcnNotificationNetworkDelete:
// TODO: UnMarshal the NotificationData
break;
Default:
// TODO: handle other events.
break;
/// Register for service-wide notifications
void RegisterForServiceNotifications()
THROW_IF_FAILED(HcnRegisterServiceCallback(
ServiceCallback,
nullptr,
&g_Callback));
/// Unregister from service-wide notifications
void UnregisterForServiceNotifications()
// As this is a unique_hcn_callback, this will cause

HcnUnregisterServiceCallback to be invoked
g_Callback.reset();
Próximas etapas
Saiba mais sobre as alças de contexto RPC para HCN.
Saiba mais sobre os esquemas de documento JSON do HCN.
Identificadores de contexto de RPC para
HCN
HCN_Network
Uma Rede HCN é uma entidade usada para representar uma rede de computação de
host e seus recursos e políticas do sistema associados. Normalmente, uma rede HCN
pode incluir:
Um conjunto de metadados (ID, nome, tipo)

Um comutador virtual
Um adaptador de rede virtual do host (atuando como um gateway padrão para a
rede)
Uma instância nat (se necessário pelo tipo de rede)
Um conjunto de pools de sub-rede e MAC
Todas as políticas em toda a rede a serem aplicadas (por exemplo, ACLs)
As entidades de rede HCN são representadas usando HCN_NETWORK identificadores

de contexto RPC.
/// Handle to an operation
DECLARE_HANDLE(HCN_NETWORK);
/// Return a list of existing Networks
///
/// \param Query Optionally specifies a JSON document for a query
/// containing properties of the specific Networks to
/// return. By default, all networks are returned.
/// \retval Networks Receives a JSON document with the list of

Networks.
/// \retval ErrorRecord Optional, receives a JSON document on failure

with extended result
/// information. The caller must release the buffer

using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnEnumerateNetworks(
_In_ PCWSTR Query,
_Outptr_ PWSTR* Networks,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Create a Network
///
/// \param Id Specifies the unique ID for the new Network.
/// \param Settings JSON document specifying the settings of the new
Network.
/// \retval Network Receives a handle to the new network.
/// \retval ErrorRecord Optional. Receives a JSON document on failure


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnCreateNetwork(
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_NETWORK Network,
);
/// Opens a handle to an existing Network.
///
/// \param Id Unique ID of the existing network.
/// \retval Network Receives a handle to the network.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnOpenNetwork(
_In_ REFGUID Id,
_Out_ PHCN_NETWORK Network,
);
/// Modify the settings of a Network
///
/// \param Network Handle to a network.
/// \param Settings JSON document specifying the new settings of the
network.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnModifyNetwork(
_In_ HCN_NETWORK Network,
);
/// Query Network properties
///
/// containing specific properties of the network
/// return. By default all properties are returned.
/// \retval Properties Receives a JSON document with Network properties.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnQueryNetworkProperties(
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
);
/// Delete a Network
///
/// \param Id Unique ID of the existing network.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnDeleteNetwork(
_In_ REFGUID Id,
);
/// Close a handle to a Network
///
///
///
HRESULT
WINAPI
HcnCloseNetwork(
_In_ HCN_NETWORK Network
);
HCN_Endpoint
Um ponto de extremidade HCN é uma entidade que é usada para representar um ponto
de extremidade IP em uma rede HCN e seus recursos e políticas do sistema associados.
Um ponto de extremidade HCN normalmente consiste em:
Um conjunto de metadados (ID, nome, ID de rede pai)

Sua identidade de rede (endereço IP, endereço MAC)
Quaisquer políticas específicas de ponto de extremidade a serem aplicadas (ACLs,
rotas)
As entidades de ponto de extremidade HCN são representadas usando HCN_ENDPOINT

DECLARE_HANDLE(HCN_ENDPOINT);
/// Return a list of existing endpoints
///
/// containing properties of the specific endpoints

to
/// return. By default all Endpoints are returned.
/// \retval Endpoints Receives a JSON document with the list of

endpoints.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnEnumerateEndpoints(
_In_ PCWSTR Query,
_Outptr_ PWSTR* Endpoints,
);
/// Create an Endpoint
///
/// \param Id Specifies the unique ID for the new endpoint.
/// \param Network Handle to the network on which endpoint is to be

created.
endpoint.
/// \retval Endpoint Receives a handle to the new endpoint.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnCreateEndpoint(
_In_ REFGUID Id,
_Out_ PHCN_ENDPOINT Endpoint,

);
/// Opens a handle to an existing Endpoint.
///
/// \param Id Unique ID of the existing endpoint.
/// \retval Endpoint Receives a handle to the endpoint.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnOpenEndpoint(
_In_ REFGUID Id,
_Out_ PHCN_ENDPOINT Endpoint,

);
/// Modify the settings of an Endpoint
///
/// \param Endpoint Handle to an endpoint.
endpoint.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnModifyEndpoint(
_In_ HCN_ENDPOINT Endpoint,
);
/// Query Endpoint properties
///
/// containing specific properties of the endpoint
/// \retval Properties Receives a JSON document with endpoint

properties.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnQueryEndpointProperties(
_In_ HCN_ENDPOINT Endpoint,
_In_ PCWSTR Query,
);
/// Delete an Endpoint
///
/// \param Id Unique ID of the existing endpoint.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnDeleteEndpoint(
_In_ REFGUID Id,
);
/// Close a handle to an endpoint

///
///
///
HRESULT
WINAPI
HcnCloseEndpoint(
_In_ HCN_ENDPOINT Endpoint
);
HCN_Namespace
Um namespace HCN é uma entidade usada para representar um namespace de rede de
computação de host. Os namespaces permitem que você tenha ambientes de rede
isolados em um único host, em que cada namespace tem seus próprios adaptadores de
rede e tabela de roteamento, separados de outros namespaces.
As entidades de namespace do HCN são representadas usando HCN_NAMESPACE

DECLARE_HANDLE(HCN_NAMESPACE);
/// Return a list of existing namespaces
///
/// containing properties of the specific namespaces

to
/// return. By default all Namespaces are returned.
/// \retval Namespaces Receives a JSON document with the list of

namespaces.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnEnumerateNamespaces(
_In_ PCWSTR Query,
_Outptr_ PWSTR* Namespaces,
);
/// Create a Namespace
///
/// \param Id Specifies the unique ID for the new namespace.
namespace.
/// \retval Namespace Receives a handle to the new namespace.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnCreateNamespace(
_In_ REFGUID Id,
_Out_ PHCN_NAMESPACE Namespace,
);
/// Opens a handle to an existing namespace.
///
/// \param Id Unique ID of the existing namespace.
/// \retval Namespace Receives a handle to the namespace.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnOpenNamespace(
_In_ REFGUID Id,
_Out_ PHCN_NAMESPACE Namespace,
);
/// Modify the settings of a namespace
///
/// \param Namespace Handle to a namespace.
namespace.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnModifyNamespace(
_In_ HCN_NAMESPACE Namespace,

);
/// Query Namespace properties
///
/// containing specific properties of the namespace
/// \retval Properties Receives a JSON document with Namespace

properties.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnQueryNamespaceProperties(
_In_ HCN_NAMESPACE Namespace,

_In_ PCWSTR Query,
);
/// Delete a Namespace
///
/// \param Id Unique ID of the existing namespace.


using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnDeleteNamespace(
_In_ REFGUID Id,
);
/// Close a handle to a Namespace

///
///
///
HRESULT
WINAPI
HcnCloseNamespace(
_In_ HCN_NAMESPACE Namespace
);
HCN_LoadBalancer
Um balanceador de carga HCN é uma entidade usada para representar um balanceador
de carga de rede de computação de host. Os balanceadores de carga permitem que
você tenha pontos de extremidade de rede de computação de host com balanceamento
de carga.
As entidades HCN LoadBalancer são representadas usando
HCN_LOADBALANCER identificadores de contexto RPC.
DECLARE_HANDLE(HCN_LOADBALANCER);
//////
/// LoadBalancer methods
/// Return a list of existing load balancers
///
/// containing properties of the specific load

balancers to
/// return. By default all load balancers are

returned.
/// \retval LoadBalancers Receives a JSON document with the list of load
balancers.
/// \retval ErrorRecord Optional. Receives a JSON document with extended

errorCode

using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnEnumerateLoadBalancers(
_In_ PCWSTR Query,
_Outptr_ PWSTR* LoadBalancer,

);
/// Create a load balancer
///
/// \param Id Specifies the unique ID for the new load

balancer.
load balancer.
/// \retval LoadBalancer Receives a handle to the new LoadBalancer.

errorCode

using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnCreateLoadBalancer(
_In_ REFGUID Id,
_Out_ PHCN_LOADBALANCER LoadBalancer,
);
/// Opens a handle to an existing LoadBalancer.
///
/// \param Id Unique ID of the existing load balancer.
/// \retval LoadBalancer Receives a handle to the load balancer.

errorCode

using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnOpenLoadBalancer(
_In_ REFGUID Id,
_Out_ PHCN_LOADBALANCER LoadBalancer,
);
/// Modify the settings of a PolcyList
///
/// \param PolcyList Handle to a PolcyList.
PolcyList.
/// \retval ErrorRecord Optional, receives a JSON document with extended

errorCode

using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnModifyLoadBalancer(
_In_ HCN_LOADBALANCER LoadBalancer,
);
/// Query LoadBalancer properties

///
/// \param LoadBalancer Handle to a load balancer.
/// containing specific properties of the load

balancer
/// \retval Properties Receives a JSON document with LoadBalancer

properties.
/// \retval ErrorRecord Optional, receives a JSON document with extended

errorCode

using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnQueryLoadBalancerProperties(
_In_ HCN_LOADBALANCER LoadBalancer,
_In_ PCWSTR Query,
);
/// Delete a LoadBalancer
///
/// \param Id Unique ID of the existing load balancer.

errorCode

using
/// CoTaskMemFree.
///
///
HRESULT
WINAPI
HcnDeleteLoadBalancer(
_In_ REFGUID Id,
);
/// Close a handle to a LoadBalancer
///
/// \param LoadBalancer Handle to a load balancer.
///
///
HRESULT
WINAPI
HcnCloseLoadBalancer(
_In_ HCN_LOADBALANCER LoadBalancer
HCN_Notification_Callback
Há funções que fornecem acesso a operações de todo o serviço, como notificações (por
exemplo, receber notificações de uma nova criação de rede).
/// Registers a callback function to receive notifications of service-wide
events such as network
/// creations/deletions.
///
/// \param Callback Function pointer to notification callback.
/// \param Context Context pointer.
/// \retval CallbackHandle Receives a handle to a callback registered on

a service.
///
///
HRESULT WINAPI
HcnRegisterServiceCallback(
_In_ HCN_NOTIFICATION_CALLBACK Callback,
_In_ void* Context,
_Out_ HCN_CALLBACK* CallbackHandle
);
/// Unregisters from service-wide notifications
///
/// \retval CallbackHandle Handle to a callback registered on a service.
///
///
HRESULT WINAPI
HcnUnregisterServiceCallback(
_In_ HCN_CALLBACK CallbackHandle
);
Esquemas de documento JSON de HCN

Esquema HCN
JSON
// Network
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"Flags" : <enum bit mask>,
// AsString; Values:
// "None" (0),
// "EnableDnsProxy" (1),
// "EnableDhcpServer" (2),
// "IsolateVSwitch" (8)
"Type" : <enum>,
// "NAT" (0),
// "ICS" (1),
// "Transparent" (2)
"Ipams" : [ {
"Type" : <enum>,
// "Static" (0),
// "Dhcp" (1)
"Subnets" : [ {
"IpAddressPrefix" : <ip prefix in CIDR>,
"Policies" : [ {
"Type" : <enum>,
// "VLAN" (0)
"Data" : <any>
} ],
"Routes" : [ {
"NextHop" : <ip address of the next hop gateway>,
"DestinationPrefix" : <ip prefix in cidr>,
"Metric" : <route metric in uint8>,
} ],
} ],
} ],
"Policies" : [{
"Type" : <enum>,
// "NetAdapterName" (1),
// "InterfaceConstraint" (2)
"Data" : <any>
}],
"Dns" : {
"Suffix" : <local connection specific suffix>,
"Search" : [<list of additional suffixes>],
"ServerList" : [<string>],
"Options" : [<string>],
},
"MacPool" : {
"Ranges" : [ {
"StartMacAddress" : <string>,
"EndMacAddress" : <string>
} ],
},
Esquema de ponto de extremidade HCN

JSON
// Endpoint
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
// "None" (0),
// "DisableInterComputeCommunication" (2)
"HostComputeNetwork" : <string>,
"MacAddress" : <string>,
"Policies" : [ {
"Type" : <enum>,
// "PortMapping" (0),
// "ACL" (1)
"Data" : <any>
} ],
"Dns" : {
"Suffix" : <local connection specific suffix>,
"Search" : [<list of additional suffixes>],
"ServerList" : [<string>],
"Options" : [<string>],
},
"IPConfigurations" : [ {
"IPAddress" : <ip address>,
"PrefixLength" : <prefix length uint16>,
} ],
"Routes" : [ {
"NextHop" : <ip address of the next hop gateway>,
"DestinationPrefix" : <ip prefix in cidr>,
"Metric" : <route metric in uint8>,
} ],
Esquema de política hcn

JSON
// VlanPolicy
"Type" : "VLAN",
"IsolationId" : <uint32>,
// PortMappingPolicy
"Type" : "PortMapping",
"Protocol" : <enum>,
// "Unknown" (0),
// "ICMPv4" (1),
// "IGMP" (2),
// "TCP" (6),
// "UDP" (17),
// "ICMPv6" (58)
"InternalPort" : <uint16>,
"ExternalPort" : <uint16>,
Esquema do balanceador de carga HCN

JSON
// Host Compute LoadBalancer
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
// "None" (0),
// "EnableDirectServerReturn" (1)
// "EnableInternalLoadBalancer" (2)
"HostComputeEndpoints" : [<Host compute Endpoint id>],
"VirtualIPs" : [<Virtual IpAddress>],
"PortMappings" : [ {
"Type" : "PortMapping",
"Protocol" : <enum>,
// "Unknown" (0),
// "ICMPv4" (1),
// "IGMP" (2),
// "TCP" (6),
// "UDP" (17),
// "ICMPv6" (58)
"InternalPort" : <uint16>,
"ExternalPort" : <uint16>,
} ],
"Policies" : [ {
"Type" : <enum>,
// "SourceVirtualIp" (0),
"Data" : <any>
} ],
Esquema de namespace hcn

JSON
// Namespace
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"NamespaceId" : <uint32>,
"NamespaceGuid" : <guid>,
"Type" : <enum>,
// "Host" (0),
// "HostDefault" (1),
// "Guest" (2),
// "GuestDefault" (3)
"Resources" : [ {
"Type" : <enum>,
// "Container" (0),
// "Endpoint" (1)
"Data" : <any>
} ],
Esquema de notificação do HCN

JSON
// Notification
"ID" : Guid,
"Flags" : <uint32>,
};
Esquema de erro de resultado

JSON
// ErrorSchema
"ErrorCode" : <uint32>,
"Error" : <string>,
"Success" : <bool>,
Exemplo de código gerado por C#

C#
/*
* HCN API
* No description provided (generated by Swagger Codegen

https://github.com/swagger-api/swagger-codegen)
* OpenAPI spec version: 2.1
* Generated by: https://github.com/swagger-api/swagger-codegen.git
*/
using System;
using System.Linq;
using System.IO;
using System.Text;
using System.Text.RegularExpressions;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Runtime.Serialization;
using Newtonsoft.Json;
using Newtonsoft.Json.Converters;
using System.ComponentModel.DataAnnotations;
using SwaggerDateConverter = IO.Swagger.Client.SwaggerDateConverter;
namespace IO.Swagger.Model
/// <summary>
/// Ipam
/// </summary>
[DataContract]
public partial class Ipam : IEquatable<Ipam>, IValidatableObject

{
/// <summary>
/// Type : dhcp
/// </summary>
/// <value> Type : dhcp</value>
[JsonConverter(typeof(StringEnumConverter))]
public enum TypeEnum
/// <summary>
/// Enum Static for value: Static
/// </summary>
[EnumMember(Value = "Static")]
Static = 1,
/// <summary>
/// Enum Dhcp for value: Dhcp
/// </summary>
[EnumMember(Value = "Dhcp")]
Dhcp = 2
/// <summary>
/// Type : dhcp
/// </summary>
/// <value> Type : dhcp</value>
[DataMember(Name="Type", EmitDefaultValue=false)]
public TypeEnum? Type { get; set; }
/// <summary>
/// Initializes a new instance of the <see cref="Ipam" /> class.
/// </summary>
/// <param name="Type"> Type : dhcp.</param>
/// <param name="Subnets">Subnets.</param>
public Ipam(TypeEnum? Type = default(TypeEnum?), List<Subnet>

Subnets = default(List<Subnet>))
this.Type = Type;
this.Subnets = Subnets;
/// <summary>
/// Gets or Sets Subnets
/// </summary>
[DataMember(Name="Subnets", EmitDefaultValue=false)]
public List<Subnet> Subnets { get; set; }
/// <summary>
/// Returns the string presentation of the object
/// </summary>
/// <returns>String presentation of the object</returns>
public override string ToString()
var sb = new StringBuilder();
sb.Append("class Ipam {\n");
sb.Append(" Type: ").Append(Type).Append("\n");
sb.Append(" Subnets: ").Append(Subnets).Append("\n");
sb.Append("}\n");
return sb.ToString();
/// <summary>
/// Returns the JSON string presentation of the object
/// </summary>
/// <returns>JSON string presentation of the object</returns>
public string ToJson()
return JsonConvert.SerializeObject(this, Formatting.Indented);
/// <summary>
/// Returns true if objects are equal
/// </summary>
/// <param name="input">Object to be compared</param>
/// <returns>Boolean</returns>
public override bool Equals(object input)
return this.Equals(input as Ipam);
/// <summary>
/// Returns true if Ipam instances are equal
/// </summary>
/// <param name="input">Instance of Ipam to be compared</param>
public bool Equals(Ipam input)
if (input == null)
return false;
return
this.Type == input.Type ||
(this.Type != null &&
this.Type.Equals(input.Type))
) &&
this.Subnets == input.Subnets ||
this.Subnets != null &&
this.Subnets.SequenceEqual(input.Subnets)
);
/// <summary>
/// Gets the hash code
/// </summary>
/// <returns>Hash code</returns>
public override int GetHashCode()
unchecked // Overflow is fine, just wrap
int hashCode = 41;
if (this.Type != null)
hashCode = hashCode * 59 + this.Type.GetHashCode();
if (this.Subnets != null)
hashCode = hashCode * 59 + this.Subnets.GetHashCode();
return hashCode;
/// <summary>
/// To validate all properties of the instance
/// </summary>
/// <param name="validationContext">Validation context</param>
/// <returns>Validation Result</returns>
IEnumerable<System.ComponentModel.DataAnnotations.ValidationResult>
IValidatableObject.Validate(ValidationContext validationContext)
yield break;
/*
* HCN API

* OpenAPI spec version: 2.1
* Generated by: https://github.com/swagger-api/swagger-codegen.git
*/
using System;
using System.Linq;
using System.IO;
using System.Text;
using System.Text.RegularExpressions;
using System.Collections;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Runtime.Serialization;
using Newtonsoft.Json;
using Newtonsoft.Json.Converters;
using System.ComponentModel.DataAnnotations;
using SwaggerDateConverter = IO.Swagger.Client.SwaggerDateConverter;
namespace IO.Swagger.Model
/// <summary>
/// Subnet
/// </summary>
[DataContract]
public partial class Subnet : IEquatable<Subnet>, IValidatableObject
/// <summary>
/// Initializes a new instance of the <see cref="Subnet" /> class.
/// </summary>
/// <param name="ID">ID.</param>
/// <param name="IpAddressPrefix">IpAddressPrefix.</param>
/// <param name="Policies">Policies.</param>
/// <param name="Routes">Routes.</param>
public Subnet(string ID = default(string), string IpAddressPrefix =

default(string), List<SubnetPolicy> Policies = default(List<SubnetPolicy>),
List<Route> Routes = default(List<Route>))
this.ID = ID;
this.IpAddressPrefix = IpAddressPrefix;
this.Policies = Policies;
this.Routes = Routes;
/// <summary>
/// Gets or Sets ID
/// </summary>
[DataMember(Name="ID", EmitDefaultValue=false)]
public string ID { get; set; }
/// <summary>
/// Gets or Sets IpAddressPrefix
/// </summary>
[DataMember(Name="IpAddressPrefix", EmitDefaultValue=false)]
public string IpAddressPrefix { get; set; }
/// <summary>
/// Gets or Sets Policies
/// </summary>
[DataMember(Name="Policies", EmitDefaultValue=false)]
public List<SubnetPolicy> Policies { get; set; }
/// <summary>
/// Gets or Sets Routes
/// </summary>
[DataMember(Name="Routes", EmitDefaultValue=false)]
public List<Route> Routes { get; set; }
/// <summary>
/// Returns the string presentation of the object
/// </summary>
/// <returns>String presentation of the object</returns>
public override string ToString()
var sb = new StringBuilder();
sb.Append("class Subnet {\n");
sb.Append(" ID: ").Append(ID).Append("\n");
sb.Append(" IpAddressPrefix:
").Append(IpAddressPrefix).Append("\n");
sb.Append(" Policies: ").Append(Policies).Append("\n");
sb.Append(" Routes: ").Append(Routes).Append("\n");
sb.Append("}\n");
return sb.ToString();
/// <summary>
/// Returns the JSON string presentation of the object
/// </summary>
/// <returns>JSON string presentation of the object</returns>
public string ToJson()
return JsonConvert.SerializeObject(this, Formatting.Indented);
/// <summary>
/// Returns true if objects are equal
/// </summary>
/// <param name="input">Object to be compared</param>
public override bool Equals(object input)
return this.Equals(input as Subnet);
/// <summary>
/// Returns true if Subnet instances are equal
/// </summary>
/// <param name="input">Instance of Subnet to be compared</param>
public bool Equals(Subnet input)
if (input == null)
return false;
return
this.ID == input.ID ||
(this.ID != null &&
this.ID.Equals(input.ID))
) &&
this.IpAddressPrefix == input.IpAddressPrefix ||
(this.IpAddressPrefix != null &&
this.IpAddressPrefix.Equals(input.IpAddressPrefix))
) &&
this.Policies == input.Policies ||
this.Policies != null &&
this.Policies.SequenceEqual(input.Policies)
) &&
this.Routes == input.Routes ||
this.Routes != null &&
this.Routes.SequenceEqual(input.Routes)
);
/// <summary>
/// Gets the hash code
/// </summary>
/// <returns>Hash code</returns>
public override int GetHashCode()
unchecked // Overflow is fine, just wrap
int hashCode = 41;
if (this.ID != null)
hashCode = hashCode * 59 + this.ID.GetHashCode();
if (this.IpAddressPrefix != null)
hashCode = hashCode * 59 +
this.IpAddressPrefix.GetHashCode();
if (this.Policies != null)
hashCode = hashCode * 59 + this.Policies.GetHashCode();
if (this.Routes != null)
hashCode = hashCode * 59 + this.Routes.GetHashCode();
return hashCode;
/// <summary>
/// To validate all properties of the instance
/// </summary>
/// <param name="validationContext">Validation context</param>
/// <returns>Validation Result</returns>
IEnumerable<System.ComponentModel.DataAnnotations.ValidationResult>
IValidatableObject.Validate(ValidationContext validationContext)
// ID (string) pattern
Regex regexID = new Regex(@"^[0-9A-Fa-f]{8}-([0-9A-Fa-f]{4}-){3}

[0-9A-Fa-f]{12}$", RegexOptions.CultureInvariant);
if (false == regexID.Match(this.ID).Success)
yield return new

System.ComponentModel.DataAnnotations.ValidationResult("Invalid value for
ID, must match a pattern of " + regexID, new [] { "ID" });
yield break;
Exemplo de código gerado por Go

Go
/*
* HCN API

* API version: 2.1
* Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-

codegen.git)
*/
package swagger
type Ipam struct {
// Type : dhcp
Type_ string `json:"Type,omitempty"`
Subnets []Subnet `json:"Subnets,omitempty"`
/*
* HCN API

* API version: 2.1
* Generated by: Swagger Codegen (https://github.com/swagger-api/swagger-

codegen.git)
*/
package swagger
type Subnet struct {
ID string `json:"ID,omitempty"`
IpAddressPrefix string `json:"IpAddressPrefix,omitempty"`
Policies []SubnetPolicy `json:"Policies,omitempty"`
Routes []Route `json:"Routes,omitempty"`
Comutador Virtual Hyper-V

Este tópico fornece uma visão geral do Comutador Virtual do Hyper-V, que fornece a
capacidade de conectar máquinas virtuais (VMs) a redes externas ao host Hyper-V,
incluindo a intranet da sua organização e a Internet.
Você também pode se conectar a redes virtuais no servidor que está executando o
Hyper-V ao implantar o SDN (Software Defined Networking).
７ Observação
Além deste tópico, a documentação do Comutador Virtual do Hyper-V a seguir

está disponível.
Gerenciar o comutador virtual do Hyper-V

Acesso Remoto Direto à Memória (RDMA) e Agrupamento incorporado de
comutador (SET)
Cmdlets de equipe do comutador de rede no Windows PowerShell
Novidades no VMM 2016
Configurar a malha de rede do VMM
Fórum do Hyper-V
Hyper-V: a extensão do comutador virtual WFP deve ser habilitada se for
exigida pelas extensões de terceiros
Para obter mais informações sobre outras tecnologias de rede, consulte Rede em
O Comutador Virtual do Hyper-V é um comutador de rede Ethernet baseado em

software 2 que está disponível no Gerenciador do Hyper-V quando você instala a função
de servidor Hyper-V.
O Comutador Virtual do Hyper-V inclui recursos gerenciados programaticamente e

extensíveis para conectar VMs a redes virtuais e à rede física. Além disso, o Comutador
Virtual Hyper-V fornece imposição de política para níveis de segurança, de isolamento e
de serviço.
７ Observação
O Comutador Virtual Hyper-V dá suporte apenas a Ethernet e não dá suporte a

quaisquer outras tecnologias de LAN (rede local) com fio, como Infiniband e Fibre
Channel.
O Comutador Virtual do Hyper-V inclui recursos de isolamento de locatário, formatação

de tráfego, proteção contra máquinas virtuais mal-intencionadas e solução de
problemas simplificada.
Com suporte interno para drivers de filtro NDIS (Especificação de Interface de

Dispositivo de Rede) e drivers de texto explicativo da Plataforma de Filtragem Windows
(WFP), o Comutador Virtual hyper-V permite que os ISVs (fornecedores de software
independentes) criem plug-ins extensíveis, chamados extensíveis de Extensões de
Comutador Virtual, que podem fornecer recursos avançados de rede e segurança. As
Extensões de Comutador Virtual que podem ser adicionadas ao Comutador Virtual
Hyper-V são listadas no recurso Gerenciador de Comutador Virtual do Gerenciador
Hyper-V.
Na ilustração a seguir, uma VM tem uma NIC virtual conectada ao Comutador Virtual do
Hyper-V por meio de uma porta de comutador.
Os recursos do Comutador Virtual do Hyper-V fornecem mais opções para impor o

isolamento do locatário, modelar e controlar o tráfego de rede e empregar medidas de
proteção contra VMs mal-intencionadas.
７ Observação
Em Windows Server 2016, uma VM com uma NIC virtual exibe com precisão a taxa
de transferência máxima para a NIC virtual. Para exibir a velocidade da NIC virtual
em Conexões de Rede, clique com o botão direito do mouse no ícone de NIC
virtual desejado e clique em Status. A caixa de diálogo Status da NIC virtual é
aberta. Em Conexão, o valor de Velocidade corresponde à velocidade da NIC física
instalada no servidor.
Usa para o Comutador Virtual do Hyper-V

A seguir estão alguns cenários de caso de uso para o Comutador Virtual do Hyper-V.
Exibindo estatísticas: um desenvolvedor em um fornecedor de nuvem hospedado

implementa um pacote de gerenciamento que exibe o estado atual do comutador
virtual Hyper-V. O pacote de gerenciamento pode consultar as funcionalidades atuais
em todo o comutador, as definições de configuração e estatísticas de redes de portas
individuais usando a WMI. Em seguida, o status do comutador é apresentado para dar
aos administradores uma visualização rápida do estado do comutador.
Acompanhamento de recursos: uma empresa de hospedagem está vendendo serviços

de hospedagem com preços de acordo com o nível de associação. Vários níveis de
associação incluem diferentes níveis de desempenho de rede. O administrador aloca
recursos para atender aos contratos de nível de serviço de maneira que equilibre a
disponibilidade da rede. O administrador rastreia programaticamente informações
como o uso atual da largura de banda atribuída e o número de VMs (fila de máquinas
virtuais) atribuídas à VMQ (máquina virtual) ou canais IOV. O mesmo programa também
registra periodicamente os recursos em uso, além dos recursos atribuídos por VM para
rastreamento ou recursos de dupla entrada.
Gerenciando a ordem das extensões de comutador: uma empresa instalou extensões

em seu host Hyper-V para monitorar o tráfego e relatar a detecção de intrusões.
Durante a manutenção, algumas extensões podem ser atualizadas causando a alteração
da ordem das extensões. Um programa de script simples é executado para reordenar as
extensões após as atualizações.
A extensão de encaminhamento gerencia a ID da VLAN: uma grande empresa de

comutador está criando uma extensão de encaminhamento que aplica todas as políticas
para rede. Um elemento que é gerenciado são as IDs de VLAN (rede local virtual). O
comutador virtual cede o controle da VLAN para uma extensão de encaminhamento. A
instalação da empresa de alternância chama programaticamente uma API (interface de
programação de aplicativo) da WMI (Instrumentação de Gerenciamento de Windows)
que ativa a transparência, informando ao Comutador Virtual hyper-V para passar e não
tomar nenhuma ação em marcas VLAN.
Funcionalidade do Comutador Virtual do
Hyper-V
Estes são alguns dos principais recursos incluídos no Comutador Virtual Hyper-V:
Proteção contra Envenenamento por ARP/ND (falsificação): fornece proteção

contra uma VM mal-intencionada usando falsificação do Protocolo de Resolução
de Endereços (ARP) para roubar endereços IP de outras VMs. Fornece proteção
contra ataques que podem ser iniciados para IPv6 usando falsificação ND
(Descoberta de Vizinhos).
Proteção do DHCP Guard: protege contra uma VM mal-intencionada que se

representa como um servidor DHCP (Dynamic Host Configuration Protocol) para
ataques man-in-the-middle.
ACLs de porta: fornece filtragem de tráfego com base em endereços/intervalos de

protocolo MAC (Controle de Acesso de Mídia) ou IP (Protocolo de Internet), o que
permite configurar o isolamento de rede virtual.
Modo tronco para uma VM: permite que os administradores configurem uma VM
específica como um dispositivo virtual e, em seguida, direcionem o tráfego de
vários VLANs para essa VM.
Monitoramento de tráfego de rede: permite que os administradores examinem o

tráfego que está atravessando o comutador de rede.
VLAN isolada (privada): permite que os administradores separem o tráfego em

várias vlans, para estabelecer comunidades de locatários isoladas com mais
facilidade.
A seguir está uma lista de funcionalidades que melhoram a capacidade de uso do

Comutador Virtual Hyper-V:
Limite de largura de banda e suporte à intermitência: o mínimo de largura de

banda garante a quantidade de largura de banda reservada. O máximo de largura
de banda limita a quantidade de largura de banda que uma VM pode consumir.
Suporte de marcação de ECN (Congestionamento Explícito): a marcação ECN,

também conhecida como DCTCP (Data CenterTCP), permite que o comutador
físico e o sistema operacional regulam o fluxo de tráfego de modo que os recursos
de buffer do comutador não sejam inundados, o que resulta em aumento da taxa
de transferência de tráfego.
Diagnóstico: o diagnóstico permite o rastreamento e o monitoramento fáceis de
eventos e pacotes por meio do comutador virtual.
IPAM (Gerenciamento de Endereços IP)
Gerenciamento de Endereço IP (IPAM) é um conjunto integrado de ferramentas para

habilitar o planejamento de ponta a ponta, a implantação, o gerenciamento e o
monitoramento da infraestrutura de endereços IP, com uma experiência de usuário rica.
O IPAM descobre automaticamente os servidores de infraestrutura de endereços IP e
servidores DNS (Sistema de Nomes de Domínio) na sua rede e permite que você os
gerencie com base em uma interface central.
７ Observação
Além deste tópico, o seguinte IPAM conteúdo está disponível.
Novidades no IPAM
Gerenciar IPAM
Gerenciamento de Endereço IP (IPAM) cmdlets de servidor no Windows
PowerShell
Novidades no IPAM
Este tópico descreve a funcionalidade Gerenciamento de Endereço IP (IPAM) que é nova

ou alterada no Windows Server 2016.
IPAM fornece recursos administrativos e de monitoramento altamente personalizáveis

para o endereço IP e a infraestrutura DNS em uma rede Enterprise ou CSP (Provedor de
Serviços de Nuvem). Você pode monitorar, auditar e gerenciar servidores que executam
o protocolo DHCP e o DNS (Sistema de Nomes de Domínio) usando IPAM.
Atualizações no IPAM Server

A seguir estão os recursos novos e aprimorados para IPAM em Windows Server 2016.
Recurso/funcionalidade Novo ou Descrição

melhorado
Gerenciamento de Melhoria IPAM recursos são aprimorados para cenários como

endereço IP aprimorado de lidar com sub-redes IPv4 /32 e IPv6 /128 e localizar
sub-redes e intervalos de endereço IP gratuitos em um
bloco de endereço IP.
Gerenciamento de Novo IPAM dá suporte ao registro de recursos DNS,

serviço DNS aprimorado encaminhador condicional e gerenciamento de zona
DNS para servidores DNS integrados ao Active
Directory e com suporte a arquivos ingressados no
domínio.
Gerenciamento Melhoria Várias novas experiências e operações integradas de

integrado de DNS, DHCP de gerenciamento do ciclo de vida estão habilitadas, como
e endereço IP (DDI) visualizar todos os registros de recursos DNS que
pertencem a um endereço IP, inventário automatizado
de endereços IP com base em registros de recursos
DNS e gerenciamento de ciclo de vida de endereço IP
para operações DNS e DHCP.
Suporte a várias florestas Novo Você pode usar IPAM para gerenciar os servidores DNS
do Active Directory e DHCP de várias florestas do Active Directory quando
houver uma relação de confiança de duas vias entre a
floresta em que o IPAM está instalado e cada uma das
florestas remotas.
melhorado
Limpar dados de Novo Agora você pode reduzir o tamanho IPAM banco de
utilização dados por meio da redução dos dados de utilização do
endereço IP mais antigos do que uma data
especificada.
Windows PowerShell Novo Você pode usar Windows PowerShell para definir
suporte para controle de escopos de acesso IPAM objetos.
acesso baseado em
função
Gerenciamento de endereço IP aprimorado

Os recursos a seguir melhoram os recursos IPAM gerenciamento de endereços.
７ Observação
Para a IPAM Windows PowerShell de comando, consulte cmdlets Gerenciamento

de Endereço IP (IPAM) do servidor Windows PowerShell.
Suporte para sub-redes /31, /32 e /128
IPAM em Windows Server 2016 agora dá suporte a /31, /32 e /128 sub-redes. Por
exemplo, uma sub-rede de dois endereços (/31 IPv4) pode ser necessária para um link
ponto a ponto entre as opções. Além disso, algumas opções podem exigir endereços de
loopback único (/32 para IPv4, /128 para IPv6).
Encontrar sub-redes gratuitas com Find-IpamFreeSubnet
Esse comando retorna sub-redes que estão disponíveis para alocação, considerando um
bloco IP, o comprimento do prefixo e o número de sub-redes solicitadas.
Se o número de sub-redes disponíveis for menor que o número de sub-redes

solicitadas, as sub-redes disponíveis serão retornadas com um aviso indicando que o
número disponível é menor que o número solicitado.
７ Observação
Na verdade, essa função não aloca as sub-redes, apenas relata sua disponibilidade.
No entanto, a saída do cmdlet pode ser canal para o comando Add-IpamSubnet
para criar a sub-rede.
Para obter mais informações, consulte Find-IpamFreeSubnet.
Encontrar intervalos de endereços gratuitos com Find-

IpamFreeRange
Esse novo comando retorna intervalos de endereços IP disponíveis considerando uma
sub-rede IP, o número de endereços necessários no intervalo e o número de intervalos
solicitados.
O comando procura uma série contínua de endereços IP não alocados que

corresponderem ao número de endereços solicitados. O processo é repetido até que o
número solicitado de intervalos seja encontrado ou até que não haja mais intervalos de
endereços disponíveis.
７ Observação
Na verdade, essa função não aloca os intervalos, apenas relata sua disponibilidade.
No entanto, a saída do cmdlet pode ser canal para o comando Add-IpamRange
para criar o intervalo.
Para obter mais informações, consulte Find-IpamFreeRange.
Gerenciamento de serviço DNS aprimorado

IPAM em Windows Server 2016 agora dá suporte à descoberta de servidores DNS
ingressados no domínio baseados em arquivo em uma floresta do Active Directory na
qual IPAM está em execução.
Além disso, as seguintes funções DNS foram adicionadas:
Coleta de zonas DNS e registros de recursos (que não as que pertencem ao

DNSSEC) de servidores DNS que executam Windows Server 2008 ou posterior.
Configure (criar, modificar e excluir) propriedades e operações em todos os tipos

de Registros de Recursos (diferentes daqueles pertencentes ao DNSSEC).
Configure (criar, modificar, excluir) propriedades e operações em todos os tipos de

zonas DNS, incluindo as zonas Secundária Primária e Stub).
Tarefas disparadas em zonas secundárias e de stub, independentemente de elas se
encaminharem ou reverterem zonas de lookup. Por exemplo, tarefas como
Transferir do Mestre ouTransferir nova cópia da zona do Mestre.
Controle de acesso baseado em função para a configuração de DNS com suporte

(registros DNS e zonas DNS).
Coleção e configuração de encaminhadores condicionais (criar, excluir, editar).
Gerenciamento integrado de DNS, DHCP e endereço IP

(DDI)
Ao exibir um endereço IP no Inventário de Endereços IP, você tem a opção na Exibição
de Detalhes para ver todos os registros de recursos DNS associados ao endereço IP.
Como parte da coleção de registros de recurso DNS, IPAM coleta os registros PTR para
as zonas de busca inversa do DNS. Para todas as zonas de busca inversa mapeadas para
qualquer intervalo de endereços IP, o IPAM cria os registros de endereço IP para todos
os registros PTR que pertencem a essa zona no intervalo de endereços IP mapeados
correspondente. Se o endereço IP já existir, o registro PTR será simplesmente associado
a esse endereço IP. Os endereços IP não serão criados automaticamente se a zona de
busca inversa não for mapeada para qualquer intervalo de endereços IP.
Quando um registro PTR é criado em uma zona de IPAM inversa, o inventário de

endereços IP é atualizado da mesma maneira que descrito acima. Durante a coleta
subsequente, como o endereço IP já existirá no sistema, o registro PTR será
simplesmente mapeado com esse endereço IP.
Suporte a várias florestas do Active Directory

No Windows Server 2012 R2, IPAM conseguiu descobrir e gerenciar servidores DNS e
DHCP que pertencem à mesma floresta do Active Directory que o IPAM servidor. Agora
você pode gerenciar servidores DNS e DHCP que pertencem a uma floresta do AD
diferente quando ela tem uma relação de confiança de duas vias com a floresta em que
o servidor IPAM está instalado. Você pode ir para a caixa de diálogo Configurar
Descoberta de Servidor e adicionar domínios de outras florestas confiáveis que você
deseja gerenciar. Depois que os servidores são descobertos, a experiência de
gerenciamento é a mesma que para os servidores que pertencem à mesma floresta em
que IPAM está instalado.
Para obter mais informações, consulte Gerenciar recursos em várias florestas do Active
Directory
Limpar dados de utilização
Limpar dados de utilização permite que você reduza o tamanho IPAM banco de dados
excluindo dados antigos de utilização de endereço IP. Para executar a exclusão de
dados, especifique uma data e IPAM todas as entradas de banco de dados mais antigas
ou iguais à data que você fornecer.
Para obter mais informações, consulte Limpar dados de utilização.
Windows PowerShell suporte para controle de acesso

baseado em função
Agora você pode usar o Windows PowerShell para configurar o Controle de Acesso
Baseado em Função. Você pode usar Windows PowerShell para recuperar objetos DNS e
DHCP no IPAM e alterar seus escopos de acesso. Por isso, você pode escrever scripts
Windows PowerShell para atribuir escopos de acesso aos objetos a seguir.
Espaço de endereço IP
Bloco de endereços IP
Sub-redes de endereço IP
Intervalos de endereços IP
Servidores DNS
Zonas DNS
Encaminhadores condicionais dns
Registros de recursos DNS
Servidores DHCP
Superescopos DHCP
Escopos do DHCP
Para obter mais informações, consulte Manage Role Based Access Control with Windows
PowerShelland Gerenciamento de Endereço IP (IPAM) Server Cmdlets in Windows
PowerShell.
Gerenciar o IPAM
este guia fornece informações de administração e solução de problemas para o recurso

de Gerenciamento de Endereço IP (IPAM) no Windows Server 2016.
no Windows Server 2016, o IPAM dá suporte ao registro de recursos dns, ao

encaminhador condicional e ao gerenciamento de zona dns para servidores DNS
integrados ao Active Directory domínio e com backup em arquivo. além disso, o IPAM
dá suporte ao controle de acesso baseado em função e a todas as funcionalidades em
versões anteriores da tecnologia.
Este guia inclui as seguintes seções:
Gerenciamento de registros de recursos de DNS
Gerenciamento de zona DNS
Gerenciar recursos em várias florestas de Active Directory
Controle de acesso baseado em função
Consulte Também
IPAM (Gerenciamento de Endereço IP)
Gerenciamento de registro de recursos
de DNS
Este tópico fornece informações sobre como gerenciar registros de recursos DNS
usando IPAM.
７ Observação
Além deste tópico, os tópicos de gerenciamento de registros de recursos DNS a

seguir estão disponíveis nesta seção.
Adicionar um registro de recurso DNS

Excluir registros de recursos DNS
Filtrar a exibição de registros de recursos DNS
Exibir registros de recursos DNS para um endereço IP específico
Visão geral do gerenciamento de registros de

recursos
Ao implantar IPAM em Windows Server 2016, você pode executar a descoberta do
servidor para adicionar servidores DHCP e DNS ao console de gerenciamento de
servidor IPAM. O servidor IPAM coleta dinamicamente dados DNS a cada seis horas dos
servidores DNS que ele está configurado para gerenciar. IPAM mantém um banco de
dados local onde armazena esses dados DNS. IPAM fornece uma notificação do dia e da
hora em que os dados do servidor foram coletados, bem como informando o dia
seguinte e a hora em que ocorrerá a coleta de dados de servidores DNS.
A barra de status amarela na ilustração a seguir mostra o local da interface do usuário

das notificações de IPAM.
Os dados DNS coletados incluem informações de zona DNS e registro de recursos. Você
pode configurar IPAM para coletar informações de zona do servidor DNS preferido.
IPAM coleta zonas baseadas em arquivo e no Active Directory.
７ Observação
IPAM coleta dados somente de servidores Microsoft DNS ingressados no domínio.

Não há suporte para servidores DNS de terceiros e servidores não ingressados no
domínio por IPAM.
Veja a seguir uma lista de tipos de registro de recurso DNS que são coletados por IPAM.
Banco de dados AFS
Endereço do ATM
CNAME
DHCID
DNAME
Hospedar A ou AAAA
Informações do host
ISDN
MX
Servidores de Nome
Ponteiro (PTR)
Pessoa responsável
Rotear através
Local do serviço
SOA
SRV
Texto
Serviços conhecidos
WINS
WINS-R
X.25
Em Windows Server 2016, IPAM fornece integração entre inventário de endereço IP,
zonas DNS e registros de recursos DNS:
Você pode usar IPAM para criar automaticamente um inventário de endereço IP de

registros de recursos DNS.
Você pode criar manualmente um inventário de endereço IP de registros de

recursos DNS A e AAAA.
Você pode exibir registros de recursos DNS para uma zona DNS específica e filtrar
os registros com base no tipo, endereço IP, dados de registro de recurso e outras
opções de filtragem.
IPAM cria automaticamente um mapeamento entre intervalos de endereços IP e

zonas de pesquisa reversa DNS.
IPAM cria endereços IP para os registros PTR presentes na zona de pesquisa

inversa e que estão incluídos nesse intervalo de endereços IP. Você também pode
modificar manualmente esse mapeamento, se necessário.
IPAM permite que você execute as seguintes operações em registros de recursos do

console IPAM.
Criar registros de recursos DNS
Editar registros de recursos DNS
Excluir registros de recurso DNS
Criar registros de recursos associados
IPAM registra automaticamente todas as alterações de configuração de DNS feitas

usando o console IPAM.
Consulte Também
Gerenciar IPAM
Adicionar um registro de recursos de
DNS
Você pode usar este tópico para adicionar um ou mais novos registros de recursos DNS
usando o console do cliente IPAM.

este procedimento.
Para adicionar um registro de recurso DNS

1. Em Gerenciador do Servidor, clique em IPAM. O console do cliente IPAM é exibido.
2. No painel de navegação, em MONITOR E GERENCIAR, clique em Zonas DNS. O

painel de navegação é dividido em um painel de navegação superior e em um
painel de navegação inferior.
3. No painel de navegação inferior, clique em Encaminhar Pesquisa. Todas as zonas

de pesquisa do DNS Forward gerenciadas por IPAM são exibidas nos resultados da
pesquisa do painel de exibição. Clique com o botão direito do mouse na zona em
que você deseja adicionar um registro de recurso e clique em Adicionar registro
de recurso DNS.
4. A caixa de diálogo Adicionar Registros de Recursos DNS é aberta. Nas
propriedades de registro de recurso, clique no servidor DNS e selecione o
servidor DNS no qual você deseja adicionar um ou mais novos registros de
recursos. Em Configurar registros de recursos DNS, clique em Novo.
5. A caixa de diálogo se expande para revelar Novo Registro de Recursos. Clique no

tipo de registro de recurso.
6. A lista de tipos de registro de recursos é exibida. Clique no tipo de registro de
recurso que você deseja adicionar.
7. Em Novo Registro de Recurso, em Nome, digite um nome de registro de recurso.
No Endereço IP, digite um endereço IP e selecione as propriedades de registro de
recurso apropriadas para sua implantação. Clique em Adicionar Registro de
Recurso.
8. Se você não quiser criar novos registros de recursos adicionais, clique em OK. Se
você quiser criar novos registros de recursos adicionais, clique em Novo.
9. A caixa de diálogo se expande para revelar Novo Registro de Recursos. Clique no
tipo de registro de recurso. A lista de tipos de registro de recursos é exibida.
Clique no tipo de registro de recurso que você deseja adicionar.
10. Em Novo Registro de Recurso, em Nome, digite um nome de registro de recurso.

No Endereço IP, digite um endereço IP e selecione as propriedades de registro de
recurso apropriadas para sua implantação. Clique em Adicionar Registro de
Recurso.
11. Se você quiser adicionar mais registros de recursos, repita o processo para criar
registros. Quando terminar de criar novos registros de recursos, clique em Aplicar.
12. A caixa de diálogo Adicionar Registro de Recurso exibe um resumo de registros
de recursos enquanto IPAM cria os registros de recursos no servidor DNS
especificado. Quando os registros são criados com êxito, o Status do registro é
êxito.
13. Clique em OK.

Consulte Também
Gerenciamento de Registro de Recurso DNSIPAM
Excluir registros de recursos de DNS
Você pode usar este tópico para excluir um ou mais registros de recursos DNS usando o
console do cliente IPAM.

este procedimento.
Para excluir registros de recursos DNS


3. Clique para expandir a Pesquisa De Encaminhamento e o domínio em que estão

localizados os registros de zona e de recursos que você deseja excluir. Clique na
zona e, no painel de exibição, clique no modo de exibição Atual. Clique em
Registros de Recursos.
4. No painel de exibição, localize e selecione os registros de recurso que você deseja

excluir.
5. Clique com o botão direito do mouse nos registros selecionados e clique em
Excluir registro de recurso DNS.
6. A caixa de diálogo Excluir Registro de Recurso DNS é aberta. Verifique se o

servidor DNS correto está selecionado. Se não estiver, clique no servidor DNS e
selecione o servidor do qual você deseja excluir os registros de recursos. Clique em
OK. IPAM exclui os registros de recurso do servidor DNS.
Consulte Também
Filtrar a exibição de registros de
recursos de DNS
Você pode usar este tópico para filtrar a exibição de registros de recursos DNS no

este procedimento.
Para filtrar a exibição de registros de recursos DNS


3. No painel de navegação inferior, clique em Encaminhar Pesquisa. Todas as zonas

de pesquisa do DNS Forward gerenciadas por IPAM são exibidas nos resultados da
pesquisa do painel de exibição.
4. Clique na zona cujos registros você deseja exibir e filtrar.
5. No painel de exibição, clique no modo de exibição Atual e clique em Registros de

Recursos. Os registros de recurso da zona são mostrados no painel de exibição.
6. No painel de exibição, clique em Adicionar critérios.

7. Selecione um critério na lista suspensa. Por exemplo, se você quiser exibir um tipo
de registro específico, clique em Tipo de Registro.
8. Clique em Adicionar.
9. O Tipo de Registro é adicionado como um parâmetro de pesquisa. Insira o texto
para o tipo de registro que você deseja encontrar. Por exemplo, se você quiser
exibir apenas registros SRV, digite SRV.
10. Pressione ENTER. Os registros de recursos DNS são filtrados de acordo com os
critérios e a frase de pesquisa que você especificou.
Consulte Também
Exibir registros de recurso de DNS para
um endereço IP específico
Você pode usar este tópico para exibir os registros de recursos DNS associados ao
Endereço IP escolhido.

este procedimento.
Para exibir registros de recursos de um endereço IP

2. No painel de navegação, no ESPAÇO DE ENDEREÇO IP, clique em Inventário de

Endereços IP. No painel de navegação inferior, clique em IPv4 ou IPv6. O
inventário de endereço IP aparece na exibição de pesquisa do painel de exibição.
Localize e selecione o endereço IP cujos registros de recurso DNS você deseja
exibir.
3. No painel de exibição Exibição de Detalhes, clique em registros de recursos DNS.
Os registros de recurso associados ao endereço IP selecionado são exibidos.
Consulte Também
Gerenciamento de zonas DNS
Este tópico fornece informações sobre como gerenciar zonas DNS usando o console
IPAM cliente.
７ Observação
Além deste tópico, os tópicos IPAM gerenciamento de zona DNS estão disponíveis
nesta seção.
Criar uma zona DNS

Editar uma zona DNS
Exibir registros de recursos DNS para uma zona DNS
Exibir zonas DNS
Ao implantar IPAM no Windows Server 2016, você pode usar IPAM para gerenciar zonas
DNS.
No console IPAM, você pode exibir registros de recursos DNS para uma zona DNS
específica e filtrar os registros com base no tipo, endereço IP, dados de registro de
recurso e outras opções de filtragem. Além disso, você pode editar registros de recursos
DNS para zonas específicas
Consulte Também
Gerenciar IPAM
Criar uma zona DNS
Você pode usar este tópico para criar uma zona DNS usando o console do cliente IPAM.

este procedimento.
Para criar uma zona DNS

2. No painel de navegação, em MONITOR E GERENCIAR, clique em Servidores DNS

e DHCP. No painel de exibição, clique em Tipo de Servidor e clique em DNS.
Todos os servidores DNS gerenciados por IPAM estão listados nos resultados da
pesquisa.
3. Localize o servidor onde você deseja adicionar uma zona e clique com o botão
direito do mouse no servidor. Clique em Criar zona DNS.
4. A caixa de diálogo Criar Zona DNS é aberta. Em Propriedades Gerais, selecione

uma categoria de zona, um tipo de zona e insira um nome no nome da zona.
Selecione também os valores apropriados para sua implantação em Propriedades
Avançadas e clique em OK.
Consulte Também
DNS ZoneManagementManage IPAM
Editar uma zona DNS
Você pode usar este tópico para editar uma zona DNS no console do cliente IPAM.

este procedimento.
Para editar uma zona DNS


painel de navegação se divide em um painel de navegação superior e em um
3. No painel de navegação inferior, faça uma das seguintes seleções:
Pesquisa de Encaminhamento
Pesquisa reversa IPv4
Pesquisa Reversa IPv6
4. Por exemplo, selecione Pesquisa Reversa IPv4.

5. No painel de exibição, clique com o botão direito do mouse na zona que você
deseja editar e clique em Editar Zona DNS.
6. A caixa de diálogo Editar Zona DNS é aberta com a página Geral selecionada. Se
necessário, edite as propriedades de zona geral: servidor DNS, categoria zona e
tipo de zona e clique em Aplicar ou, se as edições estiverem concluídas, OK.
7. Na caixa de diálogo Editar Zona DNS , clique em Avançado. A página

propriedades de zona avançada é aberta. Se necessário, edite as propriedades que
você deseja alterar e clique em Aplicar ou, se suas edições estiverem concluídas,
OK.
8. Se necessário, selecione os nomes de página de propriedades de zona adicionais
(Servidores de Nomes, SOA, Transferências de Zona), faça suas edições e clique em
Aplicar ou OK. Para examinar todas as edições de zona, clique em Resumo e clique
em OK.
Consulte Também
Exibir registros de recurso de DNS para
uma zona DNS
Você pode usar este tópico para exibir registros de recursos DNS para uma zona DNS
no console do cliente IPAM.

este procedimento.
Para exibir registros de recursos DNS para uma zona


3. No painel de navegação inferior, clique em Avançar Pesquisa e expanda a lista de

domínios e zonas para localizar e selecionar a zona que você deseja exibir. Por
exemplo, se você tiver uma zona chamada dublin, clique em Dublin.
4. No painel de exibição, a exibição padrão é dos servidores DNS para a zona. Para
alterar o modo de exibição, clique no modo de exibição Atual e clique em
Registros de Recursos.
5. Os registros de recurso DNS para a zona são exibidos. Para filtrar os registros,
digite o texto que você deseja encontrar no Filtro.
6. Para filtrar os registros de recursos por tipo de registro, escopo de acesso ou

outros critérios, clique em Adicionar critérios e, em seguida, faça seleções na lista
de critérios e clique em Adicionar.
Consulte Também
Exibir zonas DNS
Você pode usar este tópico para exibir zonas DNS no console IPAM cliente.

este procedimento.
Para exibir zonas DNS no console IPAM cliente

1. No Gerenciador do Servidor, clique em IPAM. O IPAM do cliente é exibido.
2. No painel de navegação, em MONITORAR E GERENCIAR, clique em Zonas DNS. O

painel de navegação se divide em um painel de navegação superior e em um
3. No painel de navegação inferior, faça uma das seguintes seleções:
Forward Lookup
IPv4 Reverse Lookup
IPv6 Reverse Lookup
Encaminhador Condicional
Consulte Também
Gerenciamento de ZonaDNSManage IPAM
Gerenciar recursos em várias florestas
do Active Directory
Você pode usar este tópico para aprender a usar IPAM para gerenciar controladores de
domínio, servidores DHCP e servidores DNS em várias florestas do Active Directory.
Para usar IPAM para gerenciar recursos em florestas remotas do Active Directory, cada
floresta que você deseja gerenciar deve ter uma relação de confiança bidirecional com a
floresta em que o IPAM está instalado.
Para iniciar o processo de descoberta para diferentes florestas do Active Directory, abra
Gerenciador do Servidor e clique em IPAM. No console do cliente IPAM, clique em
Configurar Descoberta de Servidor e clique em Obter florestas. Isso inicia uma tarefa
em segundo plano que descobre florestas confiáveis e seus domínios. Após a conclusão
do processo de descoberta, clique em Configurar Descoberta de Servidor, que abre a
caixa de diálogo a seguir.
７ Observação
Para o provisionamento baseado em Política de Grupo para um cenário de Floresta

Cruzada do Active Directory, execute o seguinte cmdlet Windows PowerShell no
servidor IPAM e não nos DCs de domínio confiável. Por exemplo, se o servidor
IPAM estiver ingressado na floresta corp.contoso.com e a floresta confiável for
fabrikam.com, você poderá executar o seguinte cmdlet Windows PowerShell no
servidor IPAM em corp.contoso.com para provisionamento baseado em Política de
Grupo na floresta fabrikam.com. Para executar esse cmdlet, você deve ser membro
do grupo Administradores de Domínio na floresta fabrikam.com.
PowerShell
Invoke-IpamGpoProvisioning -Domain fabrikam.COM -GpoPrefixName

IPAMSERVER -IpamServerFqdn IPAM.CORP.CONTOSO.COM
Na caixa de diálogo Configurar Descoberta de Servidor, clique em Selecionar a floresta

e escolha a floresta que você deseja gerenciar com IPAM. Selecione também os
domínios que você deseja gerenciar e clique em Adicionar.
Em Selecionar as funções de servidor a serem descobertas, para cada domínio que

você deseja gerenciar, especifique o tipo de servidor a ser descoberto. As opções são
controlador de domínio, servidor DHCP e servidor DNS.
Por padrão, os controladores de domínio, os servidores DHCP e os servidores DNS são

descobertos– portanto, se você não quiser descobrir um desses tipos de servidores,
certifique-se de desmarcar a caixa de seleção para essa opção.
Na ilustração de exemplo acima, o servidor IPAM é instalado na floresta contoso.com e

o domínio raiz da floresta fabrikam.com é adicionado para gerenciamento de IPAM. As
funções de servidor selecionadas permitem que IPAM descubra e gerencie
controladores de domínio, servidores DHCP e servidores DNS no domínio raiz
fabrikam.com e no domínio raiz contoso.com.
Depois de especificar florestas, domínios e funções de servidor, clique em OK. IPAM

executa a descoberta e, quando a descoberta for concluída, você poderá gerenciar
recursos na floresta local e remota.
você pode usar este tópico para saber como excluir dados de utilização do banco de
IPAM.
você deve ser membro de IPAM administradores, o grupo administradores do

computador local ou equivalente, para executar esse procedimento.
para limpar o banco de dados IPAM

1. abra Gerenciador do Servidor e, em seguida, navegue até a interface de cliente do
IPAM.
2. Navegue até um dos seguintes locais: blocos de endereço IP, inventário de
endereço IPou grupos de intervalos de endereços IP.
3. Clique em tarefase, em seguida, clique em limpar dados de utilização. A caixa de
diálogo limpar dados de utilização é aberta.
4. Em limpar todos os dados de utilização em ou antes, clique em selecionar uma
data.
5. Escolha a data para a qual você deseja excluir todos os registros de banco de
dados e antes dessa data.
6. Clique em OK. IPAM exclui todos os registros que você especificou.
Controle de acesso baseado em função
Este tópico fornece informações sobre como usar o controle de acesso baseado em
função no IPAM.
７ Observação
além deste tópico, a seguinte documentação de controle de acesso do IPAM está

disponível nesta seção.
Gerenciar controle de acesso baseado em função com o Gerenciador do

Servidor
Gerenciar controle de acesso baseado em função com o Windows
PowerShell
O controle de acesso baseado em função permite que você especifique privilégios de

acesso em vários níveis, incluindo o servidor DNS, a zona DNS e os níveis de registro de
recurso DNS.
Usando o controle de acesso baseado em função, você pode especificar
quem tem controle granular sobre as operações para criar, editar e excluir diferentes
tipos de registros de recursos de DNS.
Você pode configurar o controle de acesso para que os usuários sejam restritos às
permissões a seguir.
Os usuários podem editar somente registros de recursos DNS específicos
Os usuários podem editar registros de recursos de DNS de um tipo específico,

como PTR ou MX
Os usuários podem editar registros de recursos de DNS para zonas específicas
Consulte Também
gerenciar o controle de acesso baseado em função com Gerenciador do
Servidorgerenciar o controle de acesso baseado em função com Windows
PowerShellgerenciar IPAM
Gerenciar controle de acesso baseado
em função com o Gerenciador do
Servidor
Você pode usar os tópicos a seguir para gerenciar o controle de acesso baseado em
função usando Gerenciador do Servidor, que tem uma interface gráfica do usuário.
Criar uma função de usuário para controle de acesso
Criar uma política de acesso
Definir escopo de acesso para uma zona DNS
Definir escopo de acesso para registros de recursos DNS
Exibir funções e permissões de função
Como alternativa, você pode usar o Windows PowerShell para gerenciar IPAM controle
de acesso baseado em função. Para obter mais informações, consulte Gerenciar o
controle de acesso baseado em função com Windows PowerShell.
Consulte Também
Gerenciar IPAM
Criar uma função de usuário para
controle de acesso
Você pode usar este tópico para criar uma nova função de usuário Controle de Acesso
no console do cliente IPAM.

este procedimento.
７ Observação
Depois de criar uma função, você pode criar uma política de acesso para atribuir a
função a um usuário específico ou grupo do Active Directory. Para obter mais
informações, consulte Criar uma Política de Acesso.
Para criar uma função

2. No painel de navegação, clique em CONTROLE DE ACESSO e, no painel de

navegação inferior, clique em Funções.
3. Clique com o botão direito do mouse em Funções e clique em Adicionar Função
de Usuário.
4. A caixa de diálogo Adicionar ou Editar Função é aberta. Em Nome, digite um

nome para a função que torna a função de função clara. Por exemplo, se você
quiser criar uma função que permita que os administradores gerenciem registros
de recursos srv DNS, você poderá nomear a função IPAMSrv. Se necessário, role
para baixo em Operações para localizar o tipo de operações que você deseja
definir para a função. Para este exemplo, role para baixo até as operações de
gerenciamento de registro de recurso DNS.
5. Expanda as operações de gerenciamento de registro de recurso DNS e localize
operações de registro SRV.
6. Expanda e selecione operações de registro SRV e clique em OK.
7. No console do cliente IPAM, clique na função que você acabou de criar. No Modo
de Exibição de Detalhes, as operações permitidas para a função são exibidas.
Consulte Também
Controle de Acesso Manage baseadoem função IPAM
Criar uma política de acesso
Você pode usar este tópico para criar uma política de acesso no console do cliente
IPAM.

este procedimento.
７ Observação
Você pode criar uma política de acesso para um usuário específico ou para um
grupo de usuários no Active Directory. Ao criar uma política de acesso, você deve
selecionar uma função de IPAM interna ou uma função personalizada que você
criou. Para obter mais informações sobre funções personalizadas, consulte Criar
uma função de usuário para Controle de Acesso.
Para criar uma política de acesso

2. No painel de navegação, clique em CONTROLE DE ACESSO. No painel de

navegação inferior, clique com o botão direito do mouse em Políticas de Acesso e
clique em Adicionar Política de Acesso.
3. A caixa de diálogo Adicionar Política de Acesso é aberta. No User Configurações,
clique em Adicionar.
4. A caixa de diálogo Selecionar Usuário ou Grupo é aberta. Clique em Locais.
5. A caixa de diálogo Locais é aberta. Navegue até o local que contém a conta de
usuário, selecione o local e clique em OK. A caixa de diálogo Locais fecha.
6. Na caixa de diálogo Selecionar Usuário ou Grupo , insira o nome do objeto a ser

selecionado, digite o nome da conta de usuário para o qual você deseja criar uma
política de acesso. Clique em OK.
7. Em Adicionar Política de Acesso, no Configurações de Usuário, o alias do usuário

agora contém a conta de usuário à qual a política se aplica. No Access
Configurações, clique em Novo.
8. Em Adicionar Política de Acesso, o Access Configurações alterações na Nova
Configuração.
9. Clique em Selecionar função para expandir a lista de funções. Selecione uma das
funções internas ou, se você tiver criado novas funções, selecione uma das funções
criadas. Por exemplo, se você criou a função IPAMSrv para aplicar ao usuário,
clique em IPAMSrv.
10. Clique em Adicionar configuração.
11. A função é adicionada à política de acesso. Para criar políticas de acesso adicionais,
clique em Aplicar e repita estas etapas para cada política que você deseja criar. Se
você não quiser criar políticas adicionais, clique em OK.
12. No painel de exibição do console do cliente IPAM, verifique se a nova política de
acesso foi criada.
Consulte Também
Definir escopo de acesso para uma zona
DNS
Você pode usar este tópico para definir o escopo de acesso para uma zona DNS usando
o console do cliente IPAM.

este procedimento.
Para definir o escopo de acesso para uma zona DNS

2. No painel de navegação, clique em Zonas DNS. No painel de exibição, clique com

o botão direito do mouse na zona DNS para a qual você deseja alterar o escopo
de acesso.e clique em Definir Escopo de Acesso.
3. A caixa de diálogo Definir Escopo de Acesso é aberta. Se necessário para sua

implantação, clique para desmarcar Herdar o escopo de acesso do pai. Em
Selecionar o escopo de acesso, selecione um item e clique em OK.
4. No painel de exibição do console do cliente IPAM, verifique se o escopo de acesso
da zona foi alterado.
Consulte Também
Controle de Acesso Managebaseado em função IPAM
Definir escopo de acesso para registros
de recurso DNS
Você pode usar este tópico para definir o escopo de acesso para um registro de recurso
DNS usando o console do cliente IPAM.

este procedimento.
Para definir o escopo de acesso para registros de recursos

DNS
2. No painel de navegação, clique em Zonas DNS. No painel de navegação inferior,

expanda a Pesquisa Avançada e navegue até a zona que contém os registros de
recurso cujo escopo de acesso você deseja alterar.
3. No painel de exibição, localize e selecione os registros de recurso cujo escopo de

acesso você deseja alterar.
4. Clique com o botão direito do mouse nos registros de recursos DNS selecionados
e clique em Definir Escopo de Acesso.
5. A caixa de diálogo Definir Escopo de Acesso é aberta. Se necessário para sua
implantação, clique para desmarcar o escopo de acesso Herdado do pai. Em
Selecionar o escopo de acesso, selecione um item e clique em OK.
Consulte Também
Exibir funções e permissões de função
Você pode usar este tópico para exibir Controle de Acesso funções de usuário no

este procedimento.
Para exibir Controle de Acesso funções

2. No painel de navegação, clique em CONTROLE DE ACESSO.
3. No painel de navegação inferior, clique em Funções. No painel de exibição, as

funções são listadas.
4. Selecione a função cujas permissões você deseja exibir. No painel de detalhes

inferior, as operações permitidas para a função são exibidas.
Consulte Também
Controle de Acesso Managebaseado em função IPAM
Gerenciar controle de acesso baseado
em função com o Windows PowerShell
Você pode usar este tópico para aprender a usar o IPAM gerenciar o controle de acesso
baseado em função com Windows PowerShell.
７ Observação
Para a IPAM Windows PowerShell de comando, consulte os cmdlets IpamServer no

Windows PowerShell.
Os novos Windows PowerShell IPAM comandos fornecem a capacidade de recuperar e

alterar os escopos de acesso de objetos DNS e DHCP. A tabela a seguir ilustra o
comando correto a ser usado para cada IPAM objeto.
IPAM objeto Comando Descrição
Servidor DNS Get-IpamDnsServer Esse cmdlet retorna o objeto do servidor

DNS no IPAM
Zona do DNS Get-IpamDnsZone Esse cmdlet retorna o objeto de zona

DNS IPAM
Registro de recurso Get-IpamResourceRecord Esse cmdlet retorna o objeto de registro

DNS de recurso DNS IPAM
Encaminhador Get- Esse cmdlet retorna o objeto de

Condicional dns IpamDnsConditionalForwarder encaminhador condicional DNS IPAM
Servidor DHCP Get-IpamDhcpServer Esse cmdlet retorna o objeto do servidor

DHCP IPAM
Superescopo do Get-IpamDhcpSuperscope Esse cmdlet retorna o objeto de

DHCP superescopo DHCP IPAM
Escopo do DHCP Get-IpamDhcpScope Esse cmdlet retorna o objeto de escopo

DHCP IPAM
No exemplo a seguir de saída de comando, o Get-IpamDnsZone cmdlet recupera a Get-

IpamDnsZone DNS.
PS C:\Users\Administrator.CONTOSO> Get-IpamDnsZone -ZoneType Forward -
ZoneName dublin.contoso.com
ZoneName : dublin.contoso.com
ZoneType : Forward
AccessScopePath : \Global\Dublin
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False
Definindo escopos de acesso IPAM objetos

Você pode definir escopos de acesso IPAM objetos usando o Set-IpamAccessScope
comando . Você pode usar esse comando para definir o escopo de acesso para um valor
específico para um objeto ou fazer com que os objetos herdem o escopo de acesso de
objetos pai. A seguir estão os objetos que você pode configurar com este comando.
Escopo do DHCP
Servidor DHCP
Superescopo do DHCP
Encaminhador Condicional dns
Registros de recursos DNS
Servidor DNS
Zona do DNS
Bloco de endereço IP
Intervalo de endereços IP
Espaço de Endereço IP
Sub-rede de endereço IP
A seguir está a sintaxe do Set-IpamAccessScope comando.
NAME
Set-IpamAccessScope
SYNTAX
Set-IpamAccessScope [-IpamRange] -InputObject <ciminstance[]> [-

AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession
<CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-Confirm]
[<CommonParameters>]
Set-IpamAccessScope [-IpamDnsServer] -InputObject <ciminstance[]> [-

Set-IpamAccessScope [-IpamDhcpServer] -InputObject <ciminstance[]> [-

Set-IpamAccessScope [-IpamDhcpSuperscope] -InputObject <ciminstance[]>

[-AccessScopePath <string>] [-IsInheritedAccessScope] [-PassThru] [-
CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf] [-
Confirm]
Set-IpamAccessScope [-IpamDhcpScope] -InputObject <ciminstance[]> [-

Set-IpamAccessScope [-IpamDnsConditionalForwarder] -InputObject

<ciminstance[]> [-AccessScopePath <string>] [-IsInheritedAccessScope] [-
PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-
WhatIf] [-Confirm]
Set-IpamAccessScope [-IpamDnsResourceRecord] -InputObject

<ciminstance[]> [-AccessScopePath <string>] [-IsInheritedAccessScope] [-
PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-
WhatIf] [-Confirm]
Set-IpamAccessScope [-IpamDnsZone] -InputObject <ciminstance[]> [-

Set-IpamAccessScope [-IpamAddressSpace] -InputObject <ciminstance[]> [-

Set-IpamAccessScope [-IpamSubnet] -InputObject <ciminstance[]> [-

Set-IpamAccessScope [-IpamBlock] -InputObject <ciminstance[]> [-

No exemplo a seguir, o escopo de acesso da zona DNS dublin.contoso.com é alterado

de Dublin para Europa.
PS C:\Users\Administrator.CONTOSO> Get-IpamDnsZone -ZoneType Forward -

ZoneType : Forward
AccessScopePath : \Global\Dublin
IsSigned : False
PS C:\Users\Administrator.CONTOSO> $a = Get-IpamDnsZone -ZoneType Forward -

PS C:\Users\Administrator.CONTOSO> Set-IpamAccessScope -IpamDnsZone -

InputObject $a -AccessScopePath \Global\Europe -PassThru
ZoneType : Forward
AccessScopePath : \Global\Europe
IsSigned : False
Network Load Balancing

Neste tópico, fornecemos uma visão geral do recurso NLB (Balanceamento de Carga de
Rede) no Windows Server 2016. Você pode usar o NLB para gerenciar dois ou mais
servidores como um único cluster virtual. O NLB aprimora a disponibilidade e a
escalabilidade de aplicativos de servidor da Internet, como os usados na Web, FTP,
firewall, proxy, VPN (rede virtual privada) e outros servidores críticos.
７ Observação
Windows Server 2016 inclui um novo SLB (Software Load Balancer) inspirado no
Azure como um componente da infraestrutura de SDN (Rede Definida pelo
Software). Use o SLB em vez de NLB se você estiver usando o SDN, estiver usando
cargas de trabalho não Windows, precisar de NAT (conversão de endereço de rede
de saída) ou precisar de L3 (Camada 3) ou balanceamento de carga não baseado
em TCP. Você pode continuar a usar o NLB com Windows Server 2016 para
implantações não SDN. Para obter mais informações sobre o SLB, consulte SLB
(Balanceamento de Carga de Software) para SDN.
O recurso NLB (Balanceamento de Carga de Rede) distribui o tráfego por diversos

servidores usando o protocolo de rede TCP/IP. Combinando dois ou mais computadores
que executam aplicativos em um único cluster virtual, o NLB proporciona confiabilidade
e desempenho para servidores Web e outros servidores críticos.
Os servidores em um cluster NLB se chamam hosts, e cada host executa uma cópia
separada dos aplicativos de servidor. O NLB distribui as solicitações de entrada dos
clientes pelos hosts do cluster. É possível configurar a carga que será tratada por cada
host. Você também pode adicionar hosts dinamicamente ao cluster para tratar
aumentos de carga. Além disso, o NLB pode direcionar todo o tráfego para um único
host designado, chamado de host padrão.
O NLB permite que todos os computadores no cluster sejam abordados pelo mesmo
conjunto de endereços IP, e mantém um conjunto de endereços IP exclusivos e
dedicados para cada host. Para aplicativos com balanceamento de carga, quando um
host falha ou fica offline, a carga é automaticamente redistribuída entre os
computadores que permanecem em operação. Quando estiver pronto, o computador
offline poderá reintegrar-se ao cluster de forma transparente e retomar sua parcela da
carga de trabalho, o que permite que os outros computadores do cluster lidem com
menos tráfego.
Aplicações práticas
O NLB é útil para garantir que os aplicativos sem monitoração de estado, como
servidores Web que usam o IIS (Serviços de Informações da Internet), fiquem
disponíveis com inatividade mínima e que eles sejam dimensionáveis(por meio da
adição de servidores à medida que a carga aumenta). As seções a seguir descrevem
como o NLB suporta alta disponibilidade, escalabilidade e gerenciamento dos servidores
em cluster que executam esses aplicativos.
Alta disponibilidade
Um sistema altamente disponível oferece, de forma confiável, um nível aceitável de
serviço com tempo de inatividade mínimo. Para oferecer alta disponibilidade, o NLB
inclui recursos internos que podem automaticamente:
Detectar um host de cluster que falha ou fica offline, e depois recuperar.
Equilibrar a carga da rede quando hosts são adicionados ou removidos.
Recuperar e redistribuir carga de trabalho no prazo de dez segundos.
Escalabilidade
Escalabilidade é a medida que determina como um computador, serviço ou aplicativo
pode atender melhor às necessidades crescentes de desempenho. No caso de clusters
NLB , a escalabilidade é a capacidade de adicionar paulatinamente um ou mais sistemas
a um cluster existente quando a carga total sobre o cluster excede seus recursos. Para
dar suporte à escalabilidade, o NLB pode fazer o seguinte:
Equilibrar solicitações de carga no cluster NLB para serviços TCP/IP individuais.
Dar suporte para até 32 computadores em um único cluster.
Executar o balanceamento de várias solicitações de carga (do mesmo cliente ou de

vários) em vários hosts do cluster.
Adicionar hosts ao cluster do NLB à medida que a carga aumenta, sem fazer o
cluster falhar.
Remover os hosts do cluster quando a carga diminui.

Permitir alto desempenho e baixa sobrecarga através de implementação com
pipelining integral. O pipelining permite que as solicitações sejam enviadas ao
cluster NLB sem aguardar resposta da solicitação enviada anteriormente.
Capacidade de gerenciamento
Para dar suporte à escalabilidade, o NLB pode fazer o seguinte:
Gerencie e configure vários clusters NLB e os hosts de cluster de um único

computador usando o NLB Manager ou os cmdlets NLB (Balanceamento de Carga
de Rede) em Windows PowerShell.
Especificar o comportamento do balanceamento de carga para uma única porta ou

para um grupo de portas IP usando regras de gerenciamento de portas.
Definir regras de porta diferentes para cada site. Se você usar o mesmo conjunto
de servidores com balanceamento de carga para vários aplicativos ou sites, as
regras de porta baseiam-se no endereço IP de destino virtual (usando clusters
virtuais).
Direcionar todas as solicitações de clientes para um único host utilizando regras

opcionais de host único. O NLB roteia solicitações de clientes para um host
específico que esteja executando aplicativos específicos.
Bloquear o acesso indesejado à rede para determinadas portas IP.
Permitir suporte do IGMP (Internet Group Management Protocol) em hosts de

cluster para controlar inundações porta do comutador (onde os pacotes de rede
de entrada são enviados para todas as portas do comutador) ao operar em modo
multicast.
Iniciar, parar e controlar as ações NLB remotamente usando comandos do

Windows PowerShell ou scripts.
Exibir o log de eventos do Windows para verificar eventos do NLB. O NLB registra
todas as ações e alterações de cluster no log de eventos.
Funcionalidade importante
O NLB é instalado como um componente padrão do driver de rede do servidor
Windows. Suas operações são transparentes para a pilha de rede TCP/IP. A figura a
seguir mostra a relação entre nlb e outros componentes de software em uma
configuração típica.
A seguir estão os principais recursos do NLB.
Não requer alterações de hardware para funcionar.
Oferece Ferramentas de Balanceamento de Carga de Rede para configurar e

gerenciar vários clusters e todos os hosts do cluster em um único computador
remoto ou local.
Permite que os clientes acessem o cluster usando um só nome lógico de Internet e

endereço IP virtual, que é conhecido como endereço IP de cluster (mantém os
nomes individuais de cada computador). O NLB permite vários endereços IP
virtuais para servidores multihomed.
７ Observação
Quando você implanta VMs como clusters virtuais, o NLB não exige que os
servidores sejam multihomed para ter vários endereços IP virtuais.
Permite que o NLB seja vinculado a vários adaptadores de rede, o que permite
configurar vários clusters independentes em cada host. O suporte a vários
adaptadores de rede difere dos clusters virtuais, pois os clusters virtuais permitem
configurar vários clusters em um único adaptador de rede.
Não requer modificações de aplicativos de servidor para que eles possam ser
executados em um cluster NLB.
Pode ser configurado para adicionar automaticamente um host ao cluster se esse

host de cluster falhar e voltar ao modo online posteriormente. O host adicionado
pode começar a manipular os pedidos de novos servidores clientes.
Permite que você coloque computadores offline para manutenção preventiva sem
perturbar as operações de cluster nos outros hosts.
Requisitos de hardware
A seguir estão os requisitos de hardware para executar um cluster NLB.
Todos os hosts do cluster devem residir na mesma sub-rede.
Não há restrição ao número de adaptadores de rede em cada host, e hosts

diferentes podem ter um número diferente de adaptadores.
Dentro de cada cluster, todos os adaptadores de rede devem ser multicast ou

unicast. O NLB não dá suporte a ambientes mistos unicast e multicast em um
único cluster.
Se você usar o modo unicast, o adaptador de rede que é usado para lidar com
tráfego cliente para cluster deve apoiar a mudança do seu endereço de MAC
(Controle de Acesso de Mídia).
Requisitos de software
A seguir estão os requisitos de software para executar um cluster NLB.
Apenas TCP/IP podem ser usados no adaptador para que o NLB seja habilitado em
cada host. Não adicione outros protocolos (por exemplo, IPX) a esse adaptador.
Os endereços IP dos servidores no cluster devem ser estáticos.
７ Observação
O NLB não oferece suporte ao protocolo DHCP. O NLB desabilita o DHCP em cada
interface que ele configura.
Informações de instalação
Você pode instalar o NLB usando Gerenciador do Servidor ou os comandos Windows
PowerShell para NLB.
Opcionalmente, você pode instalar as Ferramentas de Balanceamento de Carga de Rede

para gerenciar um cluster NLB local ou remoto. As ferramentas incluem o Gerenciador
de Balanceamento de Carga de Rede e os comandos de Windows PowerShell NLB.
Instalação com Gerenciador do Servidor
Em Gerenciador do Servidor, você pode usar o Assistente para Adicionar Funções e
Recursos para adicionar o recurso balanceamento de carga de rede. Quando você
conclui o assistente, o NLB é instalado e você não precisa reiniciar o computador.
Instalação com Windows PowerShell

Para instalar o NLB usando Windows PowerShell, execute o comando a seguir em um
prompt de Windows PowerShell com privilégios elevados no computador em que você
deseja instalar o NLB.
PowerShell
Install-WindowsFeature NLB -IncludeManagementTools
Após a conclusão da instalação, nenhuma reinicialização do computador é necessária.
Para obter mais informações, consulte Install-WindowsFeature.
Gerenciador de Balanceamento de Carga de Rede

Para abrir o Gerenciador de Balanceamento de Carga de Rede em um Gerenciador do
Servidor, clique em Ferramentas e depois clique em Gerenciador de Balanceamento de
Carga de Rede.
Recursos adicionais
A tabela a seguir fornece links para informações adicionais sobre o recurso NLB.
Tipo de Referências
conteúdo
Implantação Guia | de implantação de balanceamento de carga de redeConfigurando o

balanceamento de carga de rede com os Serviços de Terminal
Operations Gerenciando clusters de balanceamento de carga de rede | Definindo parâmetros

de balanceamento de carga de rede | Controlando hosts em clusters de
balanceamento de carga de rede
Solução de Solução de problemas de clusters de balanceamento de carga de rede | Eventos

problemas e erros do cluster NLB
conteúdo
Ferramentas Cmdlets do Windows PowerShell para Balanceamento de Carga de Rede

e
configurações
Recursos da Fórum sobre alta disponibilidade (clustering)

comunidade
NPS (Servidor de Políticas de Rede)
Você pode usar este tópico para uma visão geral do Servidor de Política de Rede no
Windows Server 2016 e Windows Server 2019. O NPS é instalado quando você instala o
recurso NPAS (Política de Rede e Serviços do Access) no Windows Server 2016 e no
Server 2019.
７ Observação
Além deste tópico, a documentação do NPS a seguir está disponível.
Práticas recomendadas do Servidor de Políticas de Rede

Introdução ao Servidor de Políticas de Rede
Planejar Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede
Gerenciar o Servidor de Políticas de Rede
Cmdlets do NPS (Servidor de Política de Rede) no Windows PowerShell para
Windows Server 2016 e Windows 10
Cmdlets do NPS (Servidor de Política de Rede) no Windows PowerShell para
Windows Server 2012 R2 e Windows 8.1
Cmdlets NPS em Windows PowerShell para Windows Server 2012 e Windows
8
O Servidor de Políticas de Rede (NPS) permite que você crie e aplique políticas de
acesso de rede em toda a organização para autenticação e autorização de solicitações
de conexão.
Você também pode configurar o NPS como um proxy RADIUS (Serviço de Usuário de
Autenticação Remota) para encaminhar solicitações de conexão para um NPS remoto
ou outro servidor RADIUS para que você possa balancear a carga das solicitações de
conexão e encaminhá-las para o domínio correto para autenticação e autorização.
O NPS permite que você configure e gerencie centralmente a autenticação, a

autorização e a contabilidade de acesso à rede com os seguintes recursos:
Servidor RADIUS. O NPS executa autenticação centralizada, autorização e
contabilização para conexões VPN (conexões VPN) sem fio, comutador de
autenticação, discagem de acesso remoto e vpn ( rede virtual privada). Ao usar o
NPS como servidor RADIUS, você configura servidores de acesso à rede (como
pontos de acesso sem fio e servidores VPN) como clientes RADIUS no NPS. Você
também configura as políticas de rede que o NPS usa para autorizar solicitações
de conexão. Você pode configurar a contabilização RADIUS para que o NPS
registre as informações de contabilização em arquivos de log no disco rígido local
ou em um banco de dados do Microsoft SQL Server. Para obter mais informações,
consulte o servidor RADIUS.
Proxy RADIUS. Ao usar o NPS como um proxy RADIUS, você configura políticas de
solicitação de conexão que informam ao NPS quais solicitações de conexão
encaminhar para outros servidores RADIUS e para quais servidores RADIUS você
deseja encaminhar solicitações de conexão. Também é possível configurar o NPS
para que encaminhe dados contábeis a serem registrados por um ou mais
computadores de um grupo de servidores RADIUS remotos. Para configurar o NPS
como um servidor proxy RADIUS, consulte os tópicos a seguir. Para obter mais
informações, consulte o proxy RADIUS.
Configurar políticas de solicitação de conexão
Contabilidade RADIUS. Você pode configurar o NPS para registrar eventos em um
arquivo de log local ou em uma instância local ou remota do Microsoft SQL Server.
Para obter mais informações, consulte o registro em log do NPS.
） Importante
A Proteção de Acesso à Rede (NAP), a HRA (Autoridade de Registro de Integridade)

e o HCAP (Protocolo de Autorização de Credenciais de Host) foram preteridos no
Windows Server 2012 R2 e não estão disponíveis no Windows Server 2016. Se você
tiver uma implantação NAP usando sistemas operacionais anteriores a Windows
Server 2016, não poderá migrar sua implantação nap para Windows Server 2016.
Você pode configurar o NPS com qualquer combinação desses recursos. Por exemplo,
você pode configurar um NPS como um servidor RADIUS para conexões VPN e também
como um proxy RADIUS para encaminhar algumas solicitações de conexão para
membros de um grupo remoto de servidores RADIUS para autenticação e autorização
em outro domínio.
Windows Server Editions e NPS

O NPS fornece funcionalidades diferentes dependendo da edição do servidor Windows
que você instala.
Windows Server 2016 ou Windows Server 2019

Standard/Datacenter Edition
Com o NPS em Windows Server 2016 Standard ou Datacenter, você pode configurar um
número ilimitado de clientes RADIUS e grupos de servidores RADIUS remotos. Além
disso, você pode configurar clientes RADIUS especificando um intervalo de endereços
IP.
７ Observação
A Política de Rede do WIndows e o recurso Serviços do Access não estão

disponíveis em sistemas instalados com uma opção de instalação do Server Core.
As seções a seguir fornecem informações mais detalhadas sobre o NPS como um

servidor RADIUS e um proxy.
Servidor RADIUS e proxy

Você pode usar o NPS como um servidor RADIUS, um proxy RADIUS ou ambos.
Servidor RADIUS
O NPS é a implementação da Microsoft do padrão RADIUS especificado pela IETF
(Internet Engineering Task Force) nas RFCs 2865 e 2866. Como um servidor RADIUS, o
NPS executa a autenticação de conexão centralizada, a autorização e a contabilidade
para muitos tipos de acesso à rede, incluindo conexões sem fio, comutador de
autenticação, acesso remoto vpn (rede virtual privada) e conexões de roteador para
roteador.
７ Observação
Para obter informações sobre como implantar o NPS como um servidor RADIUS,
consulte Implantar o Servidor de Política de Rede.
O NPS permite o uso de um conjunto heterogêneo de rede sem fio, comutador, acesso
remoto ou equipamento VPN. Você pode usar o NPS com o serviço de Acesso Remoto,
que está disponível em Windows Server 2016.
O NPS usa um domínio de Active Directory Domain Services (AD DS) ou o banco de
dados de contas de usuário do SAM (Gerenciador de Contas de Segurança) local para
autenticar as credenciais do usuário para tentativas de conexão. Quando um servidor
que executa o NPS é membro de um domínio do AD DS, o NPS usa o serviço de
diretório como seu banco de dados de conta de usuário e faz parte de uma solução de
logon único. O mesmo conjunto de credenciais é usado para o controle de acesso à
rede (autenticando e autorizando o acesso a uma rede) e para fazer logon em um
domínio do AD DS.
７ Observação
O NPS usa as propriedades de discagem da conta de usuário e das políticas de

rede para autorizar uma conexão.
Provedores de serviços de Internet (ISPs) e organizações que mantêm o acesso à rede

têm o desafio maior de gerenciar todos os tipos de acesso à rede de um único ponto de
administração, independentemente do tipo de equipamento de acesso à rede usado. O
padrão RADIUS dá suporte a essa funcionalidade em ambientes homogêneos e
heterogêneos. RADIUS é um protocolo cliente-servidor que permite que o equipamento
de acesso à rede (usado como clientes RADIUS) envie solicitações de autenticação e
contabilidade para um servidor RADIUS.
Um servidor RADIUS tem acesso às informações da conta de usuário e pode verificar as

credenciais de autenticação de acesso à rede. Se as credenciais do usuário forem
autenticadas e a tentativa de conexão for autorizada, o servidor RADIUS autorizará o
acesso do usuário com base nas condições especificadas e registrará a conexão de
acesso à rede em um log de contabilidade. O uso do RADIUS permite que os dados de
autenticação, autorização e contabilidade do usuário de acesso à rede sejam coletados
e mantidos em um local central, em vez de em cada servidor de acesso.
Usando o NPS como um servidor RADIUS
Você pode usar o NPS como um servidor RADIUS quando:
Você está usando um domínio do AD DS ou o banco de dados de contas de

usuário sam local como seu banco de dados de conta de usuário para acessar
clientes.
Você está usando o Acesso Remoto em vários servidores de discagem, servidores
VPN ou roteadores de discagem de demanda e deseja centralizar a configuração
de políticas de rede e registro em log e contabilidade de conexões.
Você está terceirizando seu acesso discado, VPN ou sem fio a um provedor de
serviços. Os servidores de acesso usam RADIUS para autenticar e autorizar
conexões feitas por membros da sua organização.
Você deseja centralizar a autenticação, a autorização e a contabilidade de um
conjunto heterogêneo de servidores de acesso.
A ilustração a seguir mostra o NPS como um servidor RADIUS para uma variedade de
clientes de acesso.
Proxy RADIUS
Como proxy RADIUS, o NPS encaminha mensagens de autenticação e contabilidade
para NPS e outros servidores RADIUS. Você pode usar o NPS como um proxy RADIUS
para fornecer o roteamento de mensagens RADIUS entre clientes RADIUS (também
chamados de servidores de acesso à rede) e servidores RADIUS que executam
autenticação, autorização e contabilidade do usuário para a tentativa de conexão.
Quando usado como um proxy RADIUS, o NPS é um ponto central de alternância ou

roteamento por meio do qual o acesso RADIUS e as mensagens contábeis fluem. O NPS
registra informações em um log de contabilidade sobre as mensagens encaminhadas.
Usando o NPS como um proxy RADIUS

Você pode usar o NPS como um proxy RADIUS quando:
Você é um provedor de serviços que oferece serviços terceirizados de discagem,

VPN ou acesso à rede sem fio para vários clientes. Seus NASs enviam solicitações
de conexão para o proxy NPS RADIUS. Com base na parte realm do nome de
usuário na solicitação de conexão, o proxy NPS RADIUS encaminha a solicitação de
conexão para um servidor RADIUS que é mantido pelo cliente e pode autenticar e
autorizar a tentativa de conexão.
Você deseja fornecer autenticação e autorização para contas de usuário que não
são membros do domínio no qual o NPS é um membro ou outro domínio que
tenha uma confiança bidirecional com o domínio no qual o NPS é membro. Isso
inclui contas em domínios não confiáveis, domínios confiáveis unidirecionais e
outras florestas. Em vez de configurar seus servidores de acesso para enviar suas
solicitações de conexão para um servidor RADIUS do NPS, você pode configurá-los
para enviar suas solicitações de conexão para um proxy RADIUS NPS. O proxy NPS
RADIUS usa a parte do nome de realm do nome de usuário e encaminha a
solicitação para um NPS no domínio ou floresta correto. Tentativas de conexão
para contas de usuário em um domínio ou floresta podem ser autenticadas para
NASs em outro domínio ou floresta.
Você deseja executar a autenticação e a autorização usando um banco de dados
que não seja um banco de dados de conta Windows. Nesse caso, as solicitações de
conexão que correspondem a um nome de realm especificado são encaminhadas
para um servidor RADIUS, que tem acesso a um banco de dados diferente de
contas de usuário e dados de autorização. Exemplos de outros bancos de dados
de usuário incluem bancos de dados NDS (Novell Directory Services) e linguagem
SQL (SQL).
Você deseja processar um grande número de solicitações de conexão. Nesse caso,
em vez de configurar seus clientes RADIUS para tentar equilibrar suas solicitações
de conexão e contabilidade em vários servidores RADIUS, você pode configurá-los
para enviar suas solicitações de conexão e contabilidade para um proxy NPS
RADIUS. O proxy NPS RADIUS equilibra dinamicamente a carga de solicitações de
conexão e contabilidade em vários servidores RADIUS e aumenta o processamento
de um grande número de clientes RADIUS e autenticações por segundo.
Você deseja fornecer autenticação e autorização RADIUS para provedores de
serviços terceirizados e minimizar a configuração de firewall da intranet. Um
firewall de intranet está entre a rede de perímetro (a rede entre a intranet e a
Internet) e a intranet. Ao colocar um NPS em sua rede de perímetro, o firewall
entre a rede de perímetro e a intranet deve permitir que o tráfego flua entre o NPS
e vários controladores de domínio. Ao substituir o NPS por um proxy NPS, o
firewall deve permitir que apenas o tráfego RADIUS flua entre o proxy NPS e um
ou vários NPSs em sua intranet.
A ilustração a seguir mostra o NPS como um proxy RADIUS entre clientes RADIUS e
servidores RADIUS.
Com o NPS, as organizações também podem terceirizar a infraestrutura de acesso
remoto a um provedor de serviços, mantendo o controle sobre autenticação,
autorização e contabilidade do usuário.
As configurações de NPS podem ser criadas para os seguintes cenários:
Acesso sem fio

Conexão discada da organização ou acesso remoto de VPN (rede virtual privada)
Discagem terceirizada ou acesso sem fio
Acesso à Internet
Acesso autenticado a recursos de extranet para parceiros comerciais
Exemplos de configuração de proxy RADIUS e

servidor RADIUS
Os exemplos de configuração a seguir demonstram como você pode configurar o NPS
como um servidor RADIUS e um proxy RADIUS.
NPS como um servidor RADIUS. Neste exemplo, o NPS é configurado como um

servidor RADIUS, a política de solicitação de conexão padrão é a única política
configurada e todas as solicitações de conexão são processadas pelo NPS local. O NPS
pode autenticar e autorizar usuários cujas contas estão no domínio do NPS e em
domínios confiáveis.
NPS como um proxy RADIUS. Neste exemplo, o NPS é configurado como um proxy
RADIUS que encaminha solicitações de conexão para grupos de servidores RADIUS
remotos em dois domínios não confiáveis. A política de solicitação de conexão padrão é
excluída e duas novas políticas de solicitação de conexão são criadas para encaminhar
solicitações para cada um dos dois domínios não confiáveis. Neste exemplo, o NPS não
processa nenhuma solicitação de conexão no servidor local.
NPS como servidor RADIUS e proxy RADIUS. Além da política de solicitação de

conexão padrão, que designa que as solicitações de conexão são processadas
localmente, uma nova política de solicitação de conexão é criada que encaminha
solicitações de conexão para um NPS ou outro servidor RADIUS em um domínio não
confiável. Essa segunda política é chamada de política proxy. Neste exemplo, a política
proxy aparece primeiro na lista ordenada de políticas. Se a solicitação de conexão
corresponder à política proxy, a solicitação de conexão será encaminhada para o
servidor RADIUS no grupo de servidores RADIUS remoto. Se a solicitação de conexão
não corresponder à política de Proxy, mas corresponder à política de solicitação de
conexão padrão, o NPS processará a solicitação de conexão no servidor local. Se a
solicitação de conexão não corresponder a nenhuma das políticas, ela será descartada.
NPS como um servidor RADIUS com servidores de contabilidade remota. Neste

exemplo, o NPS local não está configurado para executar a contabilidade e a política de
solicitação de conexão padrão é revisada para que as mensagens contábeis RADIUS
sejam encaminhadas para um NPS ou outro servidor RADIUS em um grupo remoto de
servidores RADIUS. Embora as mensagens contábeis sejam encaminhadas, as
mensagens de autenticação e autorização não são encaminhadas e o NPS local executa
essas funções para o domínio local e todos os domínios confiáveis.
NPS com RADIUS remoto para Windows mapeamento de usuário. Neste exemplo, o
NPS atua como um servidor RADIUS e como um proxy RADIUS para cada solicitação de
conexão individual encaminhando a solicitação de autenticação para um servidor
RADIUS remoto usando uma conta de usuário local Windows para autorização. Essa
configuração é implementada configurando o RADIUS Remoto para Windows atributo
de Mapeamento de Usuário como uma condição da política de solicitação de conexão.
(Além disso, uma conta de usuário deve ser criada localmente no servidor RADIUS que
tenha o mesmo nome que a conta de usuário remoto na qual a autenticação é
executada pelo servidor RADIUS remoto.)
Configuração
Para configurar o NPS como um servidor RADIUS, você pode usar a configuração
padrão ou a configuração avançada no console do NPS ou no Gerenciador do Servidor.
Para configurar o NPS como um proxy RADIUS, você deve usar a configuração
avançada.
Configuração padrão
Com a configuração padrão, os assistentes são fornecidos para ajudá-lo a configurar o
NPS para os seguintes cenários:
Servidor RADIUS para conexões de discagem ou VPN

Servidor RADIUS para conexões 802.1X com ou sem fio
Para configurar o NPS usando um assistente, abra o console do NPS, selecione um dos
cenários anteriores e clique no link que abre o assistente.
Configuração avançada
Ao usar a configuração avançada, você configura manualmente o NPS como um
servidor RADIUS ou proxy RADIUS.
Para configurar o NPS usando a configuração avançada, abra o console do NPS e clique
na seta ao lado da Configuração Avançada para expandir esta seção.
Os seguintes itens de configuração avançada são fornecidos.
Configurar servidor RADIUS

Para configurar o NPS como um servidor RADIUS, você deve configurar clientes RADIUS,
política de rede e contabilidade RADIUS.
Para obter instruções sobre como fazer essas configurações, consulte os tópicos a
seguir.
Configurar clientes RADIUS

Configurar políticas de rede
Configurar a contabilização do Servidor de Políticas de Rede
Configurar o proxy RADIUS
Para configurar o NPS como um proxy RADIUS, você deve configurar clientes RADIUS,
grupos de servidores RADIUS remotos e políticas de solicitação de conexão.
Para obter instruções sobre como fazer essas configurações, consulte os tópicos a
seguir.

Configurar grupos de servidores RADIUS remotos
Registro em log do NPS

O registro em log NPS também é chamado de contabilidade RADIUS. Configure o
registro em log do NPS para seus requisitos se o NPS for usado como um servidor
RADIUS, proxy ou qualquer combinação dessas configurações.
Para configurar o registro em log do NPS, você deve configurar quais eventos deseja
registrar e visualizar com Visualizador de Eventos e determinar quais outras informações
deseja registrar. Além disso, você deve decidir se deseja registrar informações de
autenticação e contabilidade do usuário em arquivos de log de texto armazenados no
computador local ou em um banco de dados SQL Server no computador local ou em
um computador remoto.
Para obter mais informações, consulte Configurar a Contabilidade do Servidor de

Política de Rede.
Práticas recomendadas do Servidor de
Políticas de Rede
Você pode usar este tópico para saber mais sobre as práticas recomendadas para
implantar e gerenciar o NPS (Servidor de Políticas de Rede).
As seções a seguir fornecem práticas recomendadas para diferentes aspectos da

implantação do NPS.
Contabilidade
A seguir estão as práticas recomendadas para registro em log do NPS.
Há dois tipos de contabilidade ou registro em log no NPS:
Log de eventos para NPS. Você pode usar o log de eventos para registrar eventos
NPS nos logs de eventos do sistema e de segurança. Isso é usado principalmente
para auditar e solucionar problemas de tentativas de conexão.
Registro em log de solicitações de contabilidade e autenticação de usuário. Você

pode registrar solicitações de autenticação e contabilidade de usuário para
registrar arquivos no formato de texto ou no formato de banco de dados ou fazer
logoff em um procedimento armazenado em um banco de dados SQL Server 2000.
O log de solicitações é usado principalmente para fins de análise de conexão e
cobrança e também é útil como uma ferramenta de investigação de segurança,
fornecendo um método de acompanhamento da atividade de um invasor.
Para fazer o uso mais eficaz do registro em log do NPS:
Ativar o registro em log (inicialmente) para registros de autenticação e

contabilidade. Modifique essas seleções depois de determinar o que é apropriado
para seu ambiente.
Verifique se o log de eventos está configurado com uma capacidade suficiente

para manter os logs.
Faça o back-up de todos os arquivos de log regularmente porque eles não podem
ser recriados quando estão danificados ou excluídos.
Use o atributo classe RADIUS para acompanhar o uso e simplificar a identificação
de qual departamento ou usuário cobrar pelo uso. Embora o atributo Class gerado
automaticamente seja exclusivo para cada solicitação, registros duplicados podem
existir em casos em que a resposta ao servidor de acesso é perdida e a solicitação
é reposta. Talvez seja necessário excluir solicitações duplicadas de seus logs para
acompanhar com precisão o uso.
Se os servidores de acesso à rede e servidores proxy RADIUS enviarem

periodicamente mensagens de solicitação de conexão fictícia ao NPS para verificar
se o NPS está online, use a configuração de registro ping de nome de usuário. Essa
configuração define o NPS para rejeitar automaticamente essas solicitações de
conexão falsas sem processá-las. Além disso, o NPS não registra transações que
envolvem o nome de usuário fictício em nenhum arquivo de log, o que facilita a
interpretação do log de eventos.
Desabilite o encaminhamento de notificação do NAS. Você pode desabilitar o

encaminhamento de mensagens de início e parada de NASs (servidores de acesso
à rede) para membros de um grupo de servidores RADIUS remoto configurado no
NPS. Para obter mais informações, consulte Desabilitar o encaminhamento de
notificação do NAS.
Para obter mais informações, consulte Configurar a contabilidade do servidor de

políticas de rede.
Para fornecer failover e redundância com SQL Server registro em log, coloque dois
computadores executando SQL Server em sub-redes diferentes. Use o assistente
SQL Server Criar Publicação para configurar a replicação de banco de dados entre
os dois servidores. Para obter mais informações, consulte SQL Server
documentação técnicae Replicação do SQL Server.
Autenticação
A seguir estão as práticas recomendadas para autenticação.
Use métodos de autenticação baseados em certificado, como PEAP (Protocolo de

Autenticação Extensível Protegido) e EAP (Protocolo de Autenticação Extensível)
para autenticação forte. Não use métodos de autenticação somente senha porque
eles são vulneráveis a uma variedade de ataques e não são seguros. Para
autenticação sem fio segura, é recomendável usar PEAP-MS-CHAP v2, pois o NPS
prova sua identidade para clientes sem fio usando um certificado do servidor,
enquanto os usuários provam sua identidade com seu nome de usuário e senha.
Para obter mais informações sobre como usar o NPS em sua implantação sem fio,
consulte Implantar Password-Based acesso sem fio autenticado 802.1X.
Implante sua própria AC (autoridade de certificação) com os Serviços de
Certificados do Active Directory® (AD CS) ao usar métodos de autenticação forte
baseados em certificado, como PEAP e EAP, que exigem o uso de um certificado
de servidor no NPSs. Você também pode usar sua AC para registrar certificados de
computador e certificados de usuário. Para obter mais informações sobre como
implantar certificados de servidor em servidores NPS e acesso remoto, consulte
Deploy Server Certificates for 802.1X Wired and Wireless Deployments.802.1X
Wired and Wireless Deployments(Implantar certificados de servidor para
implantações com fio e sem fio 802.1X).
） Importante
O NPS (Servidor de Políticas de Rede) não dá suporte ao uso dos caracteres ASCII
estendidos em senhas.
Configuração do computador cliente

A seguir estão as práticas recomendadas para a configuração do computador cliente.
Configure automaticamente todos os computadores cliente do membro do

domínio 802.1X usando Política de Grupo. Para obter mais informações, consulte a
seção "Configurar políticas de rede sem fio (IEEE 802.11)" no tópico Implantação
de acesso sem fio.
Sugestões de instalação
A seguir estão as práticas recomendadas para instalar o NPS.
Antes de instalar o NPS, instale e teste cada um dos servidores de acesso à rede
usando métodos de autenticação local antes de configurá-los como clientes
RADIUS no NPS.
Depois de instalar e configurar o NPS, salve a configuração usando o comando

Windows PowerShell Export-NpsConfiguration. Salve a configuração do NPS com
esse comando sempre que reconfigurar o NPS.
Ｕ Cuidado
O arquivo de configuração NPS exportado contém segredos compartilhados
não criptografados para clientes RADIUS e membros de grupos de servidores
RADIUS remotos. Por isso, certifique-se de salvar o arquivo em um local
seguro.
O processo de exportação não inclui configurações de registro em log
Microsoft SQL Server no arquivo exportado. Se você importar o arquivo
exportado para outro NPS, deverá configurar manualmente SQL Server Log
no novo servidor.
NPS de ajuste de desempenho

A seguir estão as práticas recomendadas para o NPS de ajuste de desempenho.
Para otimizar os tempos de resposta de autenticação e autorização do NPS e

minimizar o tráfego de rede, instale o NPS em um controlador de domínio.
Quando os domínios UPNs (nomes de entidade de entidade universal) ou

Windows Server 2008 e Windows Server 2003 são usados, o NPS usa o catálogo
global para autenticar usuários. Para minimizar o tempo necessário para fazer isso,
instale o NPS em um servidor de catálogo global ou em um servidor que está na
mesma sub-rede que o servidor de catálogo global.
Quando você tiver grupos de servidores RADIUS remotos configurados e, em

Políticas de Solicitação de Conexão NPS, desempurar a caixa de seleção Registrar
informações de contabilidade nos servidores no grupo de servidores RADIUS
remoto a seguir, esses grupos ainda receberão mensagens de notificação de início
e parada do NAS (servidor de acesso à rede). Isso cria tráfego de rede
desnecessário. Para eliminar esse tráfego, desabilite o encaminhamento de
notificação nas para servidores individuais em cada grupo de servidores RADIUS
remoto desinfeçando a caixa de seleção Encaminhar início da rede e parar
notificações para esse servidor.
Usando o NPS em grandes organizações

A seguir estão as práticas recomendadas para usar o NPS em grandes organizações.
Se você estiver usando políticas de rede para restringir o acesso a todos, menos
para determinados grupos, crie um grupo universal para todos os usuários para os
quais você deseja permitir o acesso e crie uma política de rede que conceda
acesso a esse grupo universal. Não coloque todos os usuários diretamente no
grupo universal, especialmente se você tiver um grande número deles em sua
rede. Em vez disso, crie grupos separados que são membros do grupo universal e
adicione usuários a esses grupos.
Use um nome de entidade de usuário para se referir aos usuários sempre que
possível. Um usuário pode ter o mesmo nome de entidade de usuário,
independentemente da associação de domínio. Essa prática fornece escalabilidade
que pode ser necessária em organizações com um grande número de domínios.
Se você instalou o NPS (Servidor de Políticas de Rede) em um computador

diferente de um controlador de domínio e o NPS está recebendo um grande
número de solicitações de autenticação por segundo, você pode melhorar o
desempenho do NPS aumentando o número de autenticações simultâneas
permitidas entre o NPS e o controlador de domínio. Para obter mais informações,
consulte Aumentar autenticações simultâneas processadas pelo NPS.
Problemas de segurança
A seguir estão as práticas recomendadas para reduzir problemas de segurança.
Quando você estiver administrando um NPS remotamente, não envie dados

confidenciais ou confidenciais (por exemplo, segredos compartilhados ou senhas) pela
rede em texto não criptografado. Há dois métodos recomendados para administração
remota de NPSs:
Use Serviços de Área de Trabalho Remota para acessar o NPS. Quando você usa
Serviços de Área de Trabalho Remota, os dados não são enviados entre o cliente e
o servidor. Somente a interface do usuário do servidor (por exemplo, a área de
trabalho do sistema operacional e a imagem do console NPS) é enviada ao cliente
do Serviços de Área de Trabalho Remota, que é chamado Conexão de Área de
Trabalho Remota no Windows ® 10. O cliente envia a entrada do teclado e do
mouse, que é processada localmente pelo servidor que Serviços de Área de
Trabalho Remota habilitado. Quando Serviços de Área de Trabalho Remota
usuários fazem logon, eles podem exibir apenas suas sessões de cliente
individuais, que são gerenciadas pelo servidor e são independentes umas das
outras. Além disso, Conexão de Área de Trabalho Remota fornece criptografia de
128 bits entre cliente e servidor.
Use a IPsec (segurança do protocolo IPsec) para criptografar dados confidenciais.

Você pode usar o IPsec para criptografar a comunicação entre o NPS e o
computador cliente remoto que você está usando para administrar o NPS. Para
administrar o servidor remotamente, você pode instalar o Ferramentas de
Administração de Servidor Remoto para Windows 10 no computador cliente.
Após a instalação, use o Console de Gerenciamento Microsoft (MMC) para
adicionar o snap-in nps ao console.
） Importante
Você pode instalar Ferramentas de Administração de Servidor Remoto para

Windows 10 somente na versão completa do Windows 10 Professional ou
Windows 10 Enterprise.
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede (NPS).
Introdução ao Servidor de Políticas de
Rede
Você pode usar os tópicos nesta seção para saber mais sobre recursos e funcionalidades
do Servidor de Políticas de Rede.
７ Observação
Para obter documentação adicional do Servidor de Políticas de Rede, você pode

usar as seções de biblioteca a seguir.

Processamento de solicitação de conexão

Políticas de rede
Modelos NPS
Clientes RADIUS
Processamento de solicitações de
conexão
Você pode usar este tópico para saber mais sobre o processamento de solicitação de
conexão no Servidor de Política de Rede no Windows Server 2016.
７ Observação
Além deste tópico, a documentação de processamento de solicitação de conexão a

seguir está disponível.
Políticas de Solicitação de Conexão

Nomes de realm
Grupos remotos de servidor radius
Você pode usar o processamento de solicitação de conexão para especificar onde a

autenticação de solicitações de conexão é executada - no computador local ou em um
servidor RADIUS remoto que é membro de um grupo remoto de servidores RADIUS.
Se você quiser que o servidor local que executa o NPS (Servidor de Política de Rede)
execute a autenticação para solicitações de conexão, poderá usar a política de
solicitação de conexão padrão sem configuração adicional. Com base na política padrão,
o NPS autentica usuários e computadores que têm uma conta no domínio local e em
domínios confiáveis.
Se você quiser encaminhar solicitações de conexão para um NPS remoto ou outro

servidor RADIUS, crie um grupo de servidor radius remoto e configure uma política de
solicitação de conexão que encaminhe solicitações para esse grupo remoto de
servidores RADIUS. Com essa configuração, o NPS pode encaminhar solicitações de
autenticação para qualquer servidor RADIUS, e os usuários com contas em domínios
não confiáveis podem ser autenticados.
A ilustração a seguir mostra o caminho de uma mensagem Access-Request de um

servidor de acesso à rede para um proxy RADIUS e, em seguida, para um servidor
RADIUS em um grupo de servidor radius remoto. No proxy RADIUS, o servidor de
acesso à rede é configurado como um cliente RADIUS; e em cada servidor RADIUS, o
proxy RADIUS é configurado como um cliente RADIUS.
７ Observação
Os servidores de acesso à rede que você usa com o NPS podem ser dispositivos de
gateway compatíveis com o protocolo RADIUS, como pontos de acesso sem fio
802.1X e comutadores de autenticação, servidores que executam o Acesso Remoto
configurados como servidores VPN ou discagem ou outros dispositivos
compatíveis com RADIUS.
Se você quiser que o NPS processe algumas solicitações de autenticação localmente

enquanto encaminha outras solicitações para um grupo de servidor radius remoto,
configure mais de uma política de solicitação de conexão.
Para configurar uma política de solicitação de conexão que especifica quais NPS ou
grupo de servidores RADIUS processam solicitações de autenticação, consulte Políticas
de Solicitação de Conexão.
Para especificar NPS ou outros servidores RADIUS para os quais as solicitações de

autenticação são encaminhadas, consulte Grupos de Servidores RADIUS Remotos.
NPS como um processamento de solicitação de

conexão do servidor RADIUS
Quando você usa o NPS como um servidor RADIUS, as mensagens RADIUS fornecem
autenticação, autorização e contabilidade para conexões de acesso à rede da seguinte
maneira:
1. Servidores de acesso, como servidores de acesso à rede discada, servidores VPN e

pontos de acesso sem fio, recebem solicitações de conexão de clientes de acesso.
2. O servidor de acesso, configurado para usar RADIUS como o protocolo de

autenticação, autorização e contabilidade, cria uma mensagem Access-Request e a
envia para o NPS.
3. O NPS avalia a mensagem Access-Request.
4. Se necessário, o NPS envia uma mensagem Access-Challenge para o servidor de

acesso. O servidor de acesso processa o desafio e envia uma Access-Request
atualizada para o NPS.
5. As credenciais do usuário são verificadas e as propriedades de discagem da conta

de usuário são obtidas usando uma conexão segura com um controlador de
domínio.
6. A tentativa de conexão é autorizada com as propriedades de discagem da conta

de usuário e as políticas de rede.
7. Se a tentativa de conexão for autenticada e autorizada, o NPS enviará uma

mensagem Access-Accept para o servidor de acesso. Se a tentativa de conexão
não for autenticada ou não estiver autorizada, o NPS enviará uma mensagem
Access-Reject ao servidor de acesso.
8. O servidor de acesso conclui o processo de conexão com o cliente de acesso e

envia uma mensagem Accounting-Request para o NPS, em que a mensagem é
registrada.
9. O NPS envia um Accounting-Response para o servidor de acesso.
７ Observação
O servidor de acesso também envia Accounting-Request mensagens durante o

tempo em que a conexão é estabelecida, quando a conexão do cliente de acesso é
fechada e quando o servidor de acesso é iniciado e parado.
NPS como um processamento de solicitação de

conexão de proxy RADIUS
Quando o NPS é usado como um proxy RADIUS entre um cliente RADIUS e um servidor
RADIUS, as mensagens RADIUS para tentativas de conexão de acesso à rede são
encaminhadas da seguinte maneira:
1. Servidores de acesso, como servidores de acesso à rede discada, servidores VPN

(rede virtual privada) e pontos de acesso sem fio, recebem solicitações de conexão
de clientes de acesso.
2. O servidor de acesso, configurado para usar RADIUS como o protocolo de
autenticação, autorização e contabilidade, cria uma mensagem Access-Request e a
envia para o NPS que está sendo usado como proxy NPS RADIUS.
3. O proxy RADIUS do NPS recebe a mensagem Access-Request e, com base nas

políticas de solicitação de conexão configuradas localmente, determina para onde
encaminhar a mensagem Access-Request.
4. O proxy NPS RADIUS encaminha a mensagem Access-Request para o servidor

RADIUS apropriado.
5. O servidor RADIUS avalia a mensagem Access-Request.
6. Se necessário, o servidor RADIUS envia uma mensagem Access-Challenge para o

proxy NPS RADIUS, em que ele é encaminhado para o servidor de acesso. O
servidor de acesso processa o desafio com o cliente de acesso e envia um Access-
Request atualizado para o proxy NPS RADIUS, em que ele é encaminhado para o
servidor RADIUS.
7. O servidor RADIUS autentica e autoriza a tentativa de conexão.
8. Se a tentativa de conexão for autenticada e autorizada, o servidor RADIUS enviará

uma mensagem Access-Accept para o proxy NPS RADIUS, em que ele é
encaminhado para o servidor de acesso. Se a tentativa de conexão não for
autenticada ou não estiver autorizada, o servidor RADIUS enviará uma mensagem
Access-Reject para o proxy NPS RADIUS, em que ele é encaminhado para o
servidor de acesso.
9. O servidor de acesso conclui o processo de conexão com o cliente de acesso e

envia uma mensagem Accounting-Request para o proxy RADIUS do NPS. O proxy
NPS RADIUS registra os dados contábeis e encaminha a mensagem para o servidor
RADIUS.
10. O servidor RADIUS envia um Accounting-Response para o proxy NPS RADIUS, em

que ele é encaminhado para o servidor de acesso.
Para obter mais informações sobre o NPS, consulte O NPS (Servidor de Política de
Rede).
Políticas de solicitação de conexão
Você pode usar este tópico para aprender a usar políticas de solicitação de conexão NPS
para configurar o NPS como um servidor RADIUS, um proxy RADIUS ou ambos.
７ Observação
Além deste tópico, a documentação da política de solicitação de conexão a seguir

está disponível.

As políticas de solicitação de conexão são conjuntos de condições e configurações que

permitem que os administradores de rede designem quais servidores radius (Remote
Authentication Dial-In User Service) executam a autenticação e a autorização de
solicitações de conexão que o servidor que executa o NPS (Servidor de Políticas de
Rede) recebe de clientes RADIUS. As políticas de solicitação de conexão podem ser
configuradas para designar quais servidores RADIUS são usados para contabilidade
RADIUS.
Você pode criar políticas de solicitação de conexão para que algumas mensagens de
solicitação RADIUS enviadas de clientes RADIUS sejam processadas localmente (o NPS é
usado como um servidor RADIUS) e outros tipos de mensagens sejam encaminhados
para outro servidor RADIUS (NPS é usado como um proxy RADIUS).
Com políticas de solicitação de conexão, você pode usar o NPS como um servidor
RADIUS ou como um proxy RADIUS, com base em fatores como o seguinte:
A hora do dia e o dia da semana

O nome do realm na solicitação de conexão
O tipo de conexão que está sendo solicitada
O endereço IP do cliente RADIUS
AS Access-Request RADIUS são processadas ou encaminhadas pelo NPS somente se as

configurações da mensagem de entrada corresponderem a pelo menos uma das
políticas de solicitação de conexão configuradas no NPS.
Se as configurações de política corresponderem e a política exigir que o NPS processe a
mensagem, o NPS atuará como um servidor RADIUS, autenticando e autorizando a
solicitação de conexão. Se as configurações de política corresponderem e a política
exigir que o NPS encaminhe a mensagem, o NPS atuará como um proxy RADIUS e
encaminhará a solicitação de conexão para um servidor RADIUS remoto para
processamento.
Se as configurações de uma mensagem radius Access-Request de entrada não

corresponderem a pelo menos uma das políticas de solicitação de conexão, uma
mensagem Access-Reject será enviada ao cliente RADIUS e o usuário ou computador
que está tentando se conectar à rede terá o acesso negado.
Exemplos de configuração
Os exemplos de configuração a seguir demonstram como você pode usar políticas de
solicitação de conexão.
NPS como um servidor RADIUS

A política de solicitação de conexão padrão é a única política configurada. Neste
exemplo, o NPS é configurado como um servidor RADIUS e todas as solicitações de
conexão são processadas pelo NPS local. O NPS pode autenticar e autorizar usuários
cujas contas estão no domínio do domínio NPS e em domínios confiáveis.
NPS como um proxy RADIUS

A política de solicitação de conexão padrão é excluída e duas novas políticas de
solicitação de conexão são criadas para encaminhar solicitações para dois domínios
diferentes. Neste exemplo, o NPS é configurado como um proxy RADIUS. O NPS não
processa nenhuma solicitação de conexão no servidor local. Em vez disso, ele
encaminha solicitações de conexão para NPS ou outros servidores RADIUS configurados
como membros de grupos de servidores RADIUS remotos.
NPS como servidor RADIUS e proxy RADIUS

Além da política de solicitação de conexão padrão, é criada uma nova política de
solicitação de conexão que encaminha solicitações de conexão para um NPS ou outro
servidor RADIUS em um domínio não seguro. Neste exemplo, a política de proxy
aparece primeiro na lista ordenada de políticas. Se a solicitação de conexão
corresponde à política de proxy, a solicitação de conexão é encaminhada para o
servidor RADIUS no grupo de servidores RADIUS remoto. Se a solicitação de conexão
não corresponder à política de proxy, mas corresponder à política de solicitação de
conexão padrão, o NPS processa a solicitação de conexão no servidor local. Se a
solicitação de conexão não corresponder a nenhuma das políticas, ela será descartada.
NPS como servidor RADIUS com servidores de

contabilidade remota
Neste exemplo, o NPS local não está configurado para executar a contabilidade e a
política de solicitação de conexão padrão é revisada para que as mensagens de
contabilidade RADIUS sejam encaminhadas para um NPS ou outro servidor RADIUS em
um grupo de servidores RADIUS remoto. Embora as mensagens de contabilidade sejam
encaminhadas, as mensagens de autenticação e autorização não são encaminhadas e o
NPS local executa essas funções para o domínio local e todos os domínios confiáveis.
NPS com RADIUS remoto para Windows mapeamento de

usuário
Neste exemplo, o NPS atua como um servidor RADIUS e como um proxy RADIUS para
cada solicitação de conexão individual encaminhando a solicitação de autenticação para
um servidor RADIUS remoto ao usar uma conta de usuário local Windows para
autorização. Essa configuração é implementada configurando o RADIUS Remoto para
Windows mapeamento de usuário como uma condição da política de solicitação de
conexão. (Além disso, uma conta de usuário deve ser criada localmente com o mesmo
nome que a conta de usuário remoto na qual a autenticação é executada pelo servidor
RADIUS remoto.)
Condições da política de solicitação de

conexão
As condições da política de solicitação de conexão são um ou mais atributos RADIUS
que são comparados aos atributos da mensagem RADIUS Access-Request entrada. Se
houver várias condições, todas as condições na mensagem de solicitação de conexão e
na política de solicitação de conexão deverão corresponder para que a política seja
imposta pelo NPS.
A seguir estão os atributos de condição disponíveis que você pode configurar nas
políticas de solicitação de conexão.
Grupo de atributos Propriedades da Conexão
O grupo de atributos Propriedades da Conexão contém os seguintes atributos.
Protocolo em quadro. Usado para designar o tipo de enquadramento para

pacotes de entrada. Exemplos são protocolo PPP (PPP), PROTOCOLO SLL,
Retransmissão de Quadro e X.25.
Tipo de Serviço. Usado para designar o tipo de serviço que está sendo solicitado.
Exemplos incluem quadros (por exemplo, conexões PPP) e logon (por exemplo,
conexões Telnet). Para obter mais informações sobre tipos de serviço RADIUS,
consulte RFC 2865, "Radius (Remote Authentication Dial-in User Service)."
Tipo de Encapsulamento. Usado para designar o tipo de túnel que está sendo
criado pelo cliente solicitante. Tunnel tipos incluem o PPTP (Protocolo de Túnel
Ponto a Ponto) e o protocolo L2TP.
Grupo de atributos Restrições de Dia e Hora

O grupo de atributos Restrições de Dia e Hora contém o atributo Restrições de Dia e
Hora. Com esse atributo, você pode designar o dia da semana e a hora do dia da
tentativa de conexão. O dia e a hora são relativos ao dia e à hora do NPS.
Grupo de atributos de gateway

O grupo de atributos gateway contém os atributos a seguir.
Chamado ID da Estação. Usado para designar o número de telefone do servidor

de acesso à rede. Esse atributo é uma cadeia de caracteres. Você pode usar a
sintaxe de correspondência de padrões para especificar códigos de área.
Identificador de NAS. Usado para designar o nome do servidor de acesso à rede.
Esse atributo é uma cadeia de caracteres. Você pode usar a sintaxe de
correspondência de padrões para especificar identificadores NAS.
Endereço IPv4 do NAS. Usado para designar o endereço protocolo IP versão 4
(IPv4) do servidor de acesso à rede (o cliente RADIUS). Esse atributo é uma cadeia
de caracteres. Você pode usar a sintaxe de correspondência de padrões para
especificar redes IP.
Endereço IPv6 do NAS. Usado para designar o endereço IPv6 (Internet Protocol
versão 6) do servidor de acesso à rede (o cliente RADIUS). Esse atributo é uma
cadeia de caracteres. Você pode usar a sintaxe de correspondência de padrões
para especificar redes IP.
Tipo de porta NAS. Usado para designar o tipo de mídia usado pelo cliente de
acesso. Exemplos são linhas de telefone análogas (conhecidas como assíncronas),
ISDN (Rede Digital de Serviços Integrados), túneis ou VPNs (redes virtuais
privadas), IEEE 802.11 sem fio e comutadores Ethernet.
Grupo de atributos do Machine Identity

O grupo de atributos do Machine Identity contém o atributo De identidade do
computador. Usando esse atributo, você pode especificar o método com o qual os
clientes são identificados na política.
Grupo de atributos Propriedades do Cliente RADIUS

O grupo de atributos Propriedades do Cliente RADIUS contém os seguintes atributos.
Chamando a ID da Estação. Usado para designar o número de telefone usado

pelo chamador (o cliente de acesso). Esse atributo é uma cadeia de caracteres.
Você pode usar a sintaxe de correspondência de padrões para especificar códigos
de área. Em autenticações 802.1x, o endereço MAC normalmente é populado e
pode ser corresponder do cliente. Esse campo normalmente é usado para cenários
de Bypass de Endereço Mac quando a política de solicitação de conexão é
configurada para "Aceitar usuários sem validar credenciais".
Nome Amigável do Cliente. Usado para designar o nome do computador cliente
RADIUS que está solicitando autenticação. Esse atributo é uma cadeia de
caracteres. Você pode usar a sintaxe de correspondência de padrões para
especificar nomes de cliente.
Endereço IPv4 do cliente. Usado para designar o endereço IPv4 do servidor de
acesso à rede (o cliente RADIUS). Esse atributo é uma cadeia de caracteres. Você
pode usar a sintaxe de correspondência de padrões para especificar redes IP.
Endereço IPv6 do cliente. Usado para designar o endereço IPv6 do servidor de
acesso à rede (o cliente RADIUS). Esse atributo é uma cadeia de caracteres. Você
pode usar a sintaxe de correspondência de padrões para especificar redes IP.
Fornecedor do cliente. Usado para designar o fornecedor do servidor de acesso à
rede que está solicitando autenticação. Um computador que executa o serviço de
Roteamento e Acesso Remoto é o fabricante do Microsoft NAS. Você pode usar
esse atributo para configurar políticas separadas para diferentes fabricantes de
NAS. Esse atributo é uma cadeia de caracteres. Você pode usar a sintaxe de
correspondência de padrões.
Grupo de atributos nome de usuário

O grupo de atributos Nome de Usuário contém o atributo Nome de Usuário. Usando
esse atributo, você pode designar o nome de usuário ou uma parte do nome de usuário
que deve corresponder ao nome de usuário fornecido pelo cliente de acesso na
mensagem RADIUS. Esse atributo é uma cadeia de caracteres que normalmente contém
um nome de realm e um nome de conta de usuário. Você pode usar a sintaxe de
correspondência de padrões para especificar nomes de usuário.
Configurações da política de solicitação de

conexão
As configurações de política de solicitação de conexão são um conjunto de
propriedades que são aplicadas a uma mensagem RADIUS de entrada. Configurações
consistem nos seguintes grupos de propriedades.
Autenticação
Contabilidade
Manipulação de atributo
Solicitação de encaminhamento
Avançado
As seções a seguir fornecem detalhes adicionais sobre essas configurações.
Autenticação
Usando essa configuração, você pode substituir as configurações de autenticação
configuradas em todas as políticas de rede e designar os métodos de autenticação e os
tipos necessários para se conectar à sua rede.
） Importante
Se você configurar um método de autenticação na política de solicitação de

conexão menos seguro do que o método de autenticação que você configura na
política de rede, o método de autenticação mais seguro que você configurar na
política de rede será substituído. Por exemplo, se você tiver uma política de rede
que exija o uso da Autenticação Extensível Protegida Protocol-Microsoft Challenge
Handshake Authentication Protocol versão 2 (PEAP-MS-CHAP v2), que é um
método de autenticação baseada em senha para sem fio seguro e você também
configurar uma política de solicitação de conexão para permitir acesso não
autenticado, o resultado é que nenhum cliente é necessário autenticar usando
PEAP-MS-CHAP v2. Neste exemplo, todos os clientes que se conectam à sua rede
têm acesso não autenticado.
Contabilidade
Usando essa configuração, você pode configurar a política de solicitação de conexão
para encaminhar informações de contabilidade para um NPS ou outro servidor RADIUS
em um grupo de servidores RADIUS remoto para que o grupo de servidores RADIUS
remoto execute a contabilidade.
７ Observação
Se você tiver vários servidores RADIUS e quiser informações de contabilidade para

todos os servidores armazenados em um banco de dados de contabilidade RADIUS
central, poderá usar a configuração de contabilidade da política de solicitação de
conexão em uma política em cada servidor RADIUS para encaminhar dados de
contabilidade de todos os servidores para um NPS ou outro servidor RADIUS
designado como um servidor de contabilidade.
As configurações de contabilidade da política de solicitação de conexão funcionam

independentemente da configuração de contabilidade do NPS local. Em outras palavras,
se você configurar o NPS local para registrar informações de contabilidade RADIUS em
um arquivo local ou em um banco de dados Microsoft SQL Server, ele fará isso
independentemente de você configurar uma política de solicitação de conexão para
encaminhar mensagens de contabilidade para um grupo de servidores RADIUS remoto.
Se você quiser que as informações de contabilidade registradas remotamente, mas não

localmente, configure o NPS local para não executar a contabilidade, ao mesmo tempo
que configura a contabilidade em uma política de solicitação de conexão para
encaminhar dados de contabilidade para um grupo de servidores RADIUS remoto.
Manipulação de atributo
Você pode configurar um conjunto de regras de encontrar e substituir que manipulam
as cadeias de caracteres de texto de um dos atributos a seguir.
Nome do Usuário
Chamado ID da Estação
ID da estação de chamada
O processamento de regras de local e substituição ocorre para um dos atributos

anteriores antes que a mensagem RADIUS seja sujeita a configurações de autenticação e
contabilidade. As regras de manipulação de atributo se aplicam somente a um único
atributo. Não é possível configurar regras de manipulação de atributo para cada
atributo. Além disso, a lista de atributos que você pode manipular é uma lista estática;
não é possível adicionar à lista de atributos disponíveis para manipulação.
７ Observação
Se você estiver usando o protocolo de autenticação MS-CHAP v2, não poderá

manipular o atributo Nome de Usuário se a política de solicitação de conexão for
usada para encaminhar a mensagem RADIUS. A única exceção ocorre quando um
caractere de invertida () é usado e a manipulação afeta apenas as informações à
esquerda dele. Um caractere de faixa invertida normalmente é usado para indicar
um nome de domínio (as informações à esquerda do caractere de faixa invertida) e
um nome de conta de usuário dentro do domínio (as informações à direita do
caractere de faixa invertida). Nesse caso, somente as regras de manipulação de
atributo que modificam ou substituem o nome de domínio são permitidas.
Para exemplos de como manipular o nome de realm no atributo Nome de Usuário,

consulte a seção "Exemplos para manipulação do nome de realm no atributo Nome de
Usuário" no tópico Usar expressões regulares no NPS.
Solicitação de encaminhamento
Você pode definir as seguintes opções de solicitação de encaminhamento que são
usadas para mensagens radius Access-Request:
Autenticar solicitações neste servidor. Usando essa configuração, o NPS usa um

domínio Windows NT 4.0, o Active Directory ou o banco de dados de contas de
usuário SAM (Gerenciador de Contas de Segurança) local para autenticar a
solicitação de conexão. Essa configuração também especifica que a política de
rede correspondente configurada no NPS, juntamente com as propriedades
discadas da conta de usuário, são usadas pelo NPS para autorizar a solicitação de
conexão. Nesse caso, o NPS está configurado para executar como um servidor
RADIUS.
Encaminhe solicitações para o grupo de servidores RADIUS remoto a seguir.

Usando essa configuração, o NPS encaminha solicitações de conexão para o grupo
de servidores RADIUS remoto que você especificar. Se o NPS receber uma
mensagem Access-Accept válida que corresponda à mensagem Access-Request, a
tentativa de conexão será considerada autenticada e autorizada. Nesse caso, o NPS
atua como um proxy RADIUS.
Aceite usuários sem validar credenciais. Usando essa configuração, o NPS não
verifica a identidade do usuário que está tentando se conectar à rede e o NPS não
tenta verificar se o usuário ou o computador tem o direito de se conectar à rede.
Quando o NPS é configurado para permitir acesso não autenticado e recebe uma
solicitação de conexão, o NPS envia imediatamente uma mensagem Access-Accept
ao cliente RADIUS e o usuário ou computador recebe acesso à rede. Essa
configuração é usada para alguns tipos de túnel escuro em que o cliente de acesso
é túnel antes que as credenciais do usuário sejam autenticadas.
７ Observação
Essa opção de autenticação não pode ser usada quando o protocolo de

autenticação do cliente de acesso é MS-CHAP v2 ou EAP-TLS (Extensible
Authentication Protocol-Transport Layer Security), que fornecem autenticação
mútua. Na autenticação mútua, o cliente de acesso prova que ele é um cliente de
acesso válido para o servidor de autenticação (o NPS) e o servidor de autenticação
prova que ele é um servidor de autenticação válido para o cliente de acesso.
Quando essa opção de autenticação é usada, Access-Accept mensagem é
retornada. No entanto, o servidor de autenticação não fornece validação para o
cliente de acesso e a autenticação mútua falha.
Para exemplos de como usar expressões regulares para criar regras de roteamento que
encaminham mensagens RADIUS com um nome de realm especificado para um grupo
de servidores RADIUS remoto, consulte a seção "Exemplo de encaminhamento de
mensagens RADIUS por um servidor proxy" no tópico Usar expressões regulares no
NPS.
Avançado
Você pode definir propriedades avançadas para especificar a série de atributos RADIUS
que são:
Adicionado à mensagem de resposta RADIUS quando o NPS está sendo usado

como um servidor de contabilidade ou autenticação RADIUS. Quando há atributos
especificados em uma política de rede e na política de solicitação de conexão, os
atributos enviados na mensagem de resposta RADIUS são a combinação dos dois
conjuntos de atributos.
Adicionado à mensagem RADIUS quando o NPS está sendo usado como uma
autenticação RADIUS ou proxy de contabilidade. Se o atributo já existir na
mensagem encaminhada, ele será substituído pelo valor do atributo especificado
na política de solicitação de conexão.
Além disso, alguns atributos que estão disponíveis para configuração na guia
Configurações política de solicitação de conexão na categoria Avançado fornecem
funcionalidade especializada. Por exemplo, você pode configurar o RADIUS Remoto
para Windows de Mapeamento de Usuário quando quiser dividir a autenticação e a
autorização de uma solicitação de conexão entre dois bancos de dados de contas de
usuário.
O radius remoto para Windows mapeamento de usuário especifica que Windows

autorização ocorre para usuários autenticados por um servidor RADIUS remoto. Em
outras palavras, um servidor RADIUS remoto executa a autenticação em uma conta de
usuário em um banco de dados de contas de usuário remoto, mas o NPS local autoriza
a solicitação de conexão em uma conta de usuário em um banco de dados de contas de
usuário local. Isso é útil quando você deseja permitir que os visitantes acessem sua rede.
Por exemplo, os visitantes de organizações parceiras podem ser autenticados por seu
próprio servidor RADIUS da organização parceira e, em seguida, usar uma conta de
usuário do Windows em sua organização para acessar uma LAN (rede local) convidada
em sua rede.
Outros atributos que fornecem funcionalidade especializada são:
MS-Quarantine-IPFilter e MS-Quarantine-Session-Timeout. Esses atributos são

usados quando você implanta o NAQC (Controle de Quarentena de Acesso à
Rede) com sua implantação de VPN de Roteamento e Acesso Remoto.
Passport-User-Mapping-UPN-Suffix. Esse atributo permite autenticar solicitações
de conexão com Windows de conta de usuário do Live™ ID.
Tunnel-Tag. Esse atributo designa o número da ID da VLAN ao qual a conexão
deve ser atribuída pelo NAS quando você implanta VLANs (redes locais virtuais).
Política de solicitação de conexão padrão

Uma política de solicitação de conexão padrão é criada quando você instala o NPS. Essa
política tem a configuração a seguir.
A autenticação não está configurada.

A contabilidade não está configurada para encaminhar informações de
contabilidade para um grupo de servidores RADIUS remoto.
O atributo não está configurado com regras de manipulação de atributo que
encaminham solicitações de conexão para grupos de servidores RADIUS remotos.
A Solicitação de Encaminhamento é configurada para que as solicitações de
conexão sejam autenticadas e autorizadas no NPS local.
Atributos avançados não estão configurados.
A política de solicitação de conexão padrão usa NPS como um servidor RADIUS. Para
configurar um servidor que executa o NPS para atuar como um proxy RADIUS, você
também deve configurar um grupo de servidores RADIUS remoto. Você pode criar um
novo grupo de servidores RADIUS remoto ao criar uma nova política de solicitação de
conexão usando o Assistente para Nova Política de Solicitação de Conexão. Você pode
excluir a política de solicitação de conexão padrão ou verificar se a política de
solicitação de conexão padrão é a última política processada pelo NPS colocando-a por
último na lista ordenada de políticas.
７ Observação
Se o NPS e o serviço de Acesso Remoto estão instalados no mesmo computador e

o serviço de Acesso Remoto está configurado para autenticação e contabilidade do
Windows, é possível que a autenticação de Acesso Remoto e as solicitações de
contabilidade sejam encaminhadas para um servidor RADIUS. Isso pode ocorrer
quando solicitações de contabilidade e autenticação de Acesso Remoto
corresponderem a uma política de solicitação de conexão configurada para
encaminhá-las para um grupo de servidores RADIUS remoto.
Nomes de realm
Você pode usar este tópico para obter uma visão geral do uso de nomes de realm no
processamento de solicitação de conexão do Servidor de Política de Rede.
O atributo RADIUS User-Name é uma cadeia de caracteres que normalmente contém

um local de conta de usuário e um nome de conta de usuário. O local da conta de
usuário também é chamado de nome realm ou realm e é sinônimo do conceito de
domínio, incluindo domínios DNS, domínios do Active Directory® e domínios Windows
NT 4.0. Por exemplo, se uma conta de usuário estiver localizada no banco de dados de
contas de usuário para um domínio chamado example.com, example.com será o nome
do realm.
Em outro exemplo, se o atributo RADIUS User-Name contiver o nome

user1@example.comde usuário , user1 será o nome da conta de usuário e example.com
será o nome do realm. Os nomes de realm podem ser apresentados no nome de
usuário como um prefixo ou como um sufixo:
Exemplo\user1. Neste exemplo, o nome realm Example é um prefixo; e também é

o nome de um domínio do AD DS (Active Directory® Domain Services).
user1@example.com. Neste exemplo, o nome do realm example.com é um sufixo;

e é um nome de domínio DNS ou o nome de um domínio do AD DS.
Você pode usar nomes de realm configurados em políticas de solicitação de conexão ao

projetar e implantar sua infraestrutura RADIUS para garantir que as solicitações de
conexão sejam roteadas de clientes RADIUS, também chamados de servidores de acesso
à rede, para servidores RADIUS que podem autenticar e autorizar a solicitação de
conexão.
Quando o NPS é configurado como um servidor RADIUS com a política de solicitação

de conexão padrão, o NPS processa solicitações de conexão para o domínio no qual o
NPS é membro e para domínios confiáveis.
Para configurar o NPS para atuar como um proxy RADIUS e encaminhar solicitações de
conexão para domínios não confiáveis, você deve criar uma nova política de solicitação
de conexão. Na nova política de solicitação de conexão, você deve configurar o atributo
Nome de Usuário com o nome de realm que estará contido no atributo User-Name de
solicitações de conexão que você deseja encaminhar. Você também deve configurar a
política de solicitação de conexão com um grupo de servidores RADIUS remoto. A
política de solicitação de conexão permite que o NPS calcule quais solicitações de
conexão encaminhar para o grupo de servidores RADIUS remoto com base na parte
realm do atributo User-Name.
Adquirindo o nome do realm

A parte do nome de realm do nome de usuário é fornecida quando o usuário digita
credenciais baseadas em senha durante uma tentativa de conexão ou quando um perfil
de Gerenciador de Conexões (CM) no computador do usuário é configurado para
fornecer o nome do realm automaticamente.
Você pode designar que os usuários da rede forneçam o nome do realm ao digitar suas
credenciais durante tentativas de conexão de rede.
Por exemplo, você pode exigir que os usuários digitem seu nome de usuário, incluindo
o nome da conta de usuário e o nome de realm, em Nome de usuário na caixa de
diálogo Conectar ao fazer uma conexão vpn (rede privada virtual) ou discada.
Além disso, se você criar um pacote de discagem personalizado com o CMAK (Kit de
Administração do Gerenciador de Conexões), poderá ajudar os usuários adicionando o
nome do realm automaticamente ao nome da conta de usuário em perfis cm instalados
nos computadores dos usuários. Por exemplo, você pode especificar um nome de realm
e uma sintaxe de nome de usuário no perfil cm para que o usuário só precise especificar
o nome da conta de usuário ao digitar credenciais. Nessa circunstância, o usuário não
precisa saber nem se lembrar do domínio em que sua conta de usuário está localizada.
Durante o processo de autenticação, depois que os usuários digitam suas credenciais

baseadas em senha, o nome de usuário é passado do cliente de acesso para o servidor
de acesso à rede. O servidor de acesso à rede constrói uma solicitação de conexão e
inclui o nome do realm dentro do atributo RADIUS User-Name na mensagem Access-
Request enviada ao proxy ou servidor RADIUS.
Se o servidor RADIUS for um NPS, a mensagem Access-Request será avaliada em

relação ao conjunto de políticas de solicitação de conexão configuradas. As condições
na política de solicitação de conexão podem incluir a especificação do conteúdo do
atributo User-Name.
Você pode configurar um conjunto de políticas de solicitação de conexão específicas

para o nome do realm no atributo User-Name de mensagens de entrada. Isso permite
que você crie regras de roteamento que encaminham mensagens RADIUS com um
nome de realm específico para um conjunto específico de servidores RADIUS quando o
NPS é usado como um proxy RADIUS.
Regras de manipulação de atributo

Antes que a mensagem RADIUS seja processada localmente (quando o NPS está sendo
usado como um servidor RADIUS) ou encaminhada para outro servidor RADIUS (quando
o NPS está sendo usado como um proxy RADIUS), o atributo User-Name na mensagem
pode ser modificado por regras de manipulação de atributo. Você pode configurar
regras de manipulação de atributo para o atributo User-Name selecionando Nome de
usuário na guia Condições nas propriedades de uma política de solicitação de conexão.
As regras de manipulação de atributo NPS usam sintaxe de expressão regular.
７ Observação
A manipulação de realm não funciona com PEAP.
O comportamento desejado pode ser realizado alternando para EAP-TLS ou EAP-

MSCHAPv2 para autenticação ou adicionando um sufixo UPN ao domínio para
cada nome de domínio adicional que você precisa resolver.
Você pode configurar regras de manipulação de atributo para o atributo User-Name

para alterar o seguinte:
Remova o nome do realm do nome de usuário (também conhecido como realm

stripping). Por exemplo, o nome user1@example.com de usuário é alterado para
user1.
Altere o nome do realm, mas não sua sintaxe. Por exemplo, o nome
user1@example.com de usuário é alterado para user1@wcoast.example.com.
Altere a sintaxe do nome do realm. Por exemplo, o nome de usuário

example\user1 é alterado para user1@example.com.
Depois que o atributo User-Name for modificado de acordo com as regras de

manipulação de atributo que você definir, configurações adicionais da primeira política
de solicitação de conexão correspondente serão usadas para determinar se:
O NPS processa a mensagem Access-Request localmente (quando o NPS está

sendo usado como um servidor RADIUS).
O NPS encaminha a mensagem para outro servidor RADIUS (quando o NPS está
sendo usado como um proxy RADIUS).
Configurando o nome de domínio fornecido
pelo NPS
Quando o nome de usuário não contém um nome de domínio, o NPS fornece um. Por
padrão, o nome de domínio fornecido pelo NPS é o domínio do qual o NPS é membro.
Você pode especificar o nome de domínio fornecido pelo NPS por meio da seguinte
configuração do Registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProto
cols\BuiltIn\
Name: DefaultDomain
Type: REG_SZ
Value: the FQDN for the domain, like test.contoso.com
Ｕ Cuidado
A edição incorreta do Registro pode danificar seriamente o sistema. Antes de

alterar o Registro, faça backup de todos os dados importantes do computador.
Alguns servidores de acesso à rede que não são da Microsoft excluem ou modificam o
nome de domínio conforme especificado pelo usuário. Como resultado, a solicitação de
acesso à rede é autenticada no domínio padrão, que pode não ser o domínio da conta
do usuário. Para resolver esse problema, configure seus servidores RADIUS para alterar
o nome de usuário para o formato correto com o nome de domínio preciso.
Grupos de servidores RADIUS remotos
Ao configurar o NPS (servidor de diretivas de rede) como um proxy de serviço RADIUS

(RADIUS), você usa o NPS para encaminhar solicitações de conexão a servidores RADIUS
que são capazes de processar as solicitações de conexão, pois podem executar
autenticação e autorização no domínio em que a conta de usuário ou computador está
localizada. Por exemplo, se você quiser encaminhar solicitações de conexão para um ou
mais servidores RADIUS em domínios não confiáveis, poderá configurar o NPS como um
proxy RADIUS para encaminhar as solicitações para os servidores remotos RADIUS no
domínio não confiável.
７ Observação
os grupos de servidores RADIUS remotos não estão relacionados a grupos de

Windows e separados deles.
Para configurar o NPS como um proxy RADIUS, você deve criar uma política de
solicitação de conexão que contenha todas as informações necessárias para que o NPS
avalie quais mensagens devem ser encaminhadas e para onde enviar as mensagens.
Quando você configura um grupo de servidores remotos RADIUS no NPS e configura

uma política de solicitação de conexão com o grupo, você está designando o local onde
o NPS é para encaminhar solicitações de conexão.
Configurando servidores RADIUS para um

grupo
Um grupo de servidores RADIUS remotos é um grupo nomeado que contém um ou
mais servidores RADIUS. Se você configurar mais de um servidor, poderá especificar as
configurações de balanceamento de carga para determinar a ordem na qual os
servidores são usados pelo proxy ou distribuir o fluxo de mensagens RADIUS em todos
os servidores do grupo para evitar sobrecarregar um ou mais servidores com muitas
Cada servidor do grupo tem as seguintes configurações.

Nome ou endereço. Cada membro do grupo deve ter um nome exclusivo dentro
do grupo. O nome pode ser um endereço IP ou um nome que possa ser resolvido
para seu endereço IP.
Autenticação e contabilidade. Você pode encaminhar solicitações de autenticação,

solicitações de contabilização ou ambas para cada membro do grupo de
servidores RADIUS remoto.
Balanceamento de carga. Uma configuração de prioridade é usada para indicar

qual membro do grupo é o servidor primário (a prioridade é definida como 1).
Para membros do grupo que têm a mesma prioridade, uma configuração de peso
é usada para calcular a frequência com que as mensagens RADIUS são enviadas
para cada servidor. Você pode usar configurações adicionais para configurar a
maneira como o NPS detecta quando um membro do grupo se torna indisponível
pela primeira vez e quando ele fica disponível depois de ser determinado como
indisponível.
Depois de configurar um grupo de servidores remotos RADIUS, você pode especificar o

grupo nas configurações de estatísticas e autenticação de uma política de solicitação de
conexão. Por isso, você pode configurar um grupo de servidores remotos RADIUS
primeiro. Em seguida, você pode configurar a política de solicitação de conexão para
usar o grupo de servidores RADIUS remotos recentemente configurados. Como
alternativa, você pode usar o assistente de nova política de solicitação de conexão para
criar um novo grupo de servidores remotos RADIUS enquanto estiver criando a política
de solicitação de conexão.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
Políticas de Rede
Você pode usar este tópico para uma visão geral das políticas de rede no NPS.
７ Observação
Além deste tópico, a documentação de política de rede a seguir está disponível.
Permissão de acesso
As políticas de rede são conjuntos de condições, restrições e configurações que

permitem designar quem está autorizado a se conectar à rede e as circunstâncias em
que eles podem ou não se conectar.
No processamento das solicitações de conexão como um servidor RADIUS, o NPS

executa a autenticação e a autorização da solicitação de conexão. Durante o processo
de autenticação, o NPS verifica a identidade do usuário ou computador que está se
conectando à rede. Durante o processo de autorização, o NPS determina se o usuário
ou o computador tem permissão para acessar a rede.
Para fazer essas determinações, o NPS usa políticas de rede configuradas no console do
NPS. O NPS também examina as propriedades discadas da conta de usuário no Active
Directory® Domain Services (AD DS) para executar a autorização.
Políticas de rede – um conjunto ordenado de

regras
As políticas de rede podem ser exibidas como regras. Cada regra tem um conjunto de
condições e configurações. O NPS compara as condições da regra com as propriedades
das solicitações de conexão. Se ocorrer uma combinação entre a regra e a solicitação de
conexão, as configurações definidas na regra serão aplicadas à conexão.
Quando várias políticas de rede são configuradas no NPS, elas são um conjunto
ordenado de regras. O NPS verifica cada solicitação de conexão em relação à primeira
regra na lista, depois à segunda e assim por diante, até que uma combinação seja
encontrada.
Cada política de rede tem uma configuração de Estado de Política que permite habilitar
ou desabilitar a política. Quando você desabilita uma política de rede, o NPS não avalia
a política ao autorizar solicitações de conexão.
７ Observação
Se você quiser que o NPS avalie uma política de rede ao executar a autorização
para solicitações de conexão, configure a configuração Estado da Política marcando
a caixa de seleção Política habilitada.
Propriedades da política de rede

Há quatro categorias de propriedades para cada política de rede:
Visão geral
Essas propriedades permitem que você especifique se a política está habilitada, se a
política concede ou nega acesso e se um método de conexão de rede específico ou tipo
de NAS (servidor de acesso à rede) é necessário para solicitações de conexão. As
propriedades de visão geral também permitem que você especifique se as propriedades
discadas das contas de usuário AD DS são ignoradas. Se você selecionar essa opção,
somente as configurações na política de rede serão usadas pelo NPS para determinar se
a conexão está autorizada.
Condições
Essas propriedades permitem que você especifique as condições que a solicitação de
conexão deve ter para corresponder à política de rede; se as condições configuradas na
política corresponderem à solicitação de conexão, o NPS aplicará as configurações
designadas na política de rede à conexão. Por exemplo, se você especificar o endereço
NAS IPv4 como uma condição da política de rede e o NPS receber uma solicitação de
conexão de um NAS que tenha o endereço IP especificado, a condição na política
corresponde à solicitação de conexão.
Restrições
Restrições são parâmetros adicionais da política de rede necessários para corresponder
à solicitação de conexão. Se uma restrição não for corresponder à solicitação de
conexão, o NPS rejeitará automaticamente a solicitação. Ao contrário da resposta NPS a
condições incomparáveis na política de rede, se uma restrição não for corresponder, o
NPS negará a solicitação de conexão sem avaliar políticas de rede adicionais.
Configurações
Essas propriedades permitem que você especifique as configurações que o NPS aplica à
solicitação de conexão se todas as condições de política de rede para a política
corresponderem.
Ao adicionar uma nova política de rede usando o console do NPS, você deve usar o
Assistente para Nova Política de Rede. Depois de criar uma política de rede usando o
assistente, você pode personalizar a política clicando duas vezes na política no console
do NPS para obter as propriedades da política.
Para exemplos de sintaxe de correspondência de padrões para especificar atributos de

política de rede, consulte Usar expressões regulares no NPS.
Permissões de acesso
A permissão de acesso é configurada na guia Visão geral de cada política de rede no

NPS (Servidor de Políticas de Rede).
Essa configuração permite que você configure a política para conceder ou negar acesso
aos usuários se as condições e restrições da política de rede corresponderem à
As configurações de permissão de acesso têm o seguinte efeito:
Conceder acesso. O acesso será concedido se a solicitação de conexão

corresponde às condições e restrições configuradas na política.
Negar acesso. O acesso será negado se a solicitação de conexão corresponde às
condições e restrições configuradas na política.
A permissão de acesso também é concedida ou negada com base na configuração das

propriedades discadas de cada conta de usuário.
７ Observação
As contas de usuário e suas propriedades, como propriedades discadas, são

configuradas no snap-in Usuários e Computadores do Active Directory Console de
Gerenciamento Microsoft ou no snap-in MMC (Usuários e Grupos Locais),
dependendo se você tem o Active Directory® Domain Services (AD DS) instalado.
A configuração de Permissão de Acesso à Rede da conta de usuário, que está

configurada nas propriedades discadas de contas de usuário, substitui a configuração
de permissão de acesso à política de rede. Quando a permissão de acesso à rede em
uma conta de usuário é definida como a opção Controlar o acesso por meio da Política
de Rede NPS , a configuração de permissão de acesso à política de rede determina se o
usuário tem acesso concedido ou negado.
７ Observação
No Windows Server 2016, o valor padrão de Permissão de Acesso à Rede AD DS

propriedades discadas da conta de usuário é Controlar o acesso por meio da
Política de Rede NPS.
Quando o NPS avalia as solicitações de conexão em relação às políticas de rede
configuradas, ele executa as seguintes ações:
Se as condições da primeira política não corresponderem, o NPS avaliará a

próxima política e continuará esse processo até que uma combinação seja
encontrada ou todas as políticas tenham sido avaliadas quanto a uma combinação.
Se as condições e restrições de uma política corresponderem, o NPS concederá ou
negará acesso, dependendo do valor da configuração de Permissão de Acesso na
política.
Se as condições de uma política corresponderem, mas as restrições na política não
corresponderem, o NPS rejeitará a solicitação de conexão.
Se as condições de todas as políticas não corresponderem, o NPS rejeitará a
Ignorar propriedades discadas da conta de

usuário
Você pode configurar a política de rede NPS para ignorar as propriedades discadas de
contas de usuário selecionando ou des marcando a caixa de seleção Ignorar
propriedades discadas da conta de usuário na guia Visão geral de uma política de rede.
Normalmente, quando o NPS executa a autorização de uma solicitação de conexão, ele

verifica as propriedades discadas da conta de usuário, em que o valor da configuração
de permissão de acesso à rede pode afetar se o usuário está autorizado a se conectar à
rede. Quando você configura o NPS para ignorar as propriedades discadas das contas
de usuário durante a autorização, as configurações de política de rede determinam se o
usuário recebe acesso à rede.
As propriedades discadas de contas de usuário contêm o seguinte:
Permissão de acesso à rede

Caller-ID
Opções de retorno de chamada
Endereço IP estático
Rotas estáticas
Para dar suporte a vários tipos de conexões para as quais o NPS fornece autenticação e
autorização, pode ser necessário desabilitar o processamento de propriedades discadas
da conta de usuário. Isso pode ser feito para dar suporte a cenários em que
propriedades discadas específicas não são necessárias.
Por exemplo, as propriedades caller-ID, retorno de chamada, endereço IP estático e
rotas estáticas são projetadas para um cliente que está discando em um NAS (servidor
de acesso à rede), não para clientes que estão se conectando a pontos de acesso sem
fio. Um ponto de acesso sem fio que recebe essas configurações em uma mensagem
RADIUS do NPS pode não ser capaz de processá-las, o que pode fazer com que o
cliente sem fio seja desconectado.
Quando o NPS fornece autenticação e autorização para usuários que estão discando e
acessando a rede da sua organização por meio de pontos de acesso sem fio, você deve
configurar as propriedades discadas para dar suporte a conexões discadas (definindo
propriedades discadas) ou conexões sem fio (sem definir propriedades discadas).
Você pode usar o NPS para habilitar o processamento de propriedades discadas para a
conta de usuário em alguns cenários (como discagem) e desabilitar o processamento de
propriedades discadas em outros cenários (como 802.1X sem fio e comutamento de
autenticação).
Você também pode usar Ignorar propriedades discadas da conta de usuário para
gerenciar o controle de acesso à rede por meio de grupos e a configuração de
permissão de acesso na política de rede. Quando você marca a caixa de seleção Ignorar
propriedades discadas da conta de usuário, a permissão de acesso à rede na conta de
usuário é ignorada.
A única desvantagem dessa configuração é que você não pode usar as propriedades de
discagem de conta de usuário adicionais de caller-ID, retorno de chamada, endereço IP
estático e rotas estáticas.
Modelos NPS
Os modelos de NPS (servidor de políticas de rede) permitem que você crie elementos
de configuração, como clientes serviço RADIUS (RADIUS) ou segredos compartilhados,
que você pode reutilizar no NPS local e exportar para uso em outros NPSs.
Os modelos de NPS são projetados para reduzir a quantidade de tempo e o custo

necessário para configurar o NPS em um ou mais servidores. Os seguintes tipos de
modelo de NPS estão disponíveis para configuração no gerenciamento de modelos:
Segredos compartilhados
Clientes RADIUS
Servidores RADIUS remotos
Filtros de IP
Grupos de servidores de atualizações
Configurar um modelo é diferente de configurar diretamente o NPS. A criação de um

modelo não afeta a funcionalidade do NPS. Somente quando você seleciona o modelo
no local apropriado no console do NPS, o modelo afeta a funcionalidade do NPS.
Por exemplo, se você configurar um cliente RADIUS no console do NPS em clientes e

servidores RADIUS, você alterou a configuração do NPS e fez uma etapa na
configuração do NPS para se comunicar com um dos seus servidores de acesso à rede
(NAS). (A próxima etapa seria configurar o NAS para se comunicar com o NPS). No
entanto, se você configurar um novo modelo de clientes RADIUS no console do NPS em
Gerenciamento de modelos , em vez de criar um novo cliente RADIUS em clientes e
servidores RADIUS, você criou um modelo, mas ainda não alterou a funcionalidade do
NPS. Para alterar a funcionalidade do NPS, você deve selecionar o modelo do local
correto no console do NPS.
Como criar modelos

Para criar um modelo, abra o console do NPS, clique com o botão direito do mouse em
um tipo de modelo, como filtros de IPe clique em novo. Uma nova caixa de diálogo
Propriedades do modelo é aberta e permite que você configure seu modelo.
Usando modelos localmente

Você pode usar um modelo que você criou no Gerenciamento de modelos navegando
até um local no console do NPS onde o modelo pode ser aplicado. Por exemplo, se você
criar um novo modelo de segredos compartilhados que deseja aplicar a uma
configuração de cliente RADIUS, em clientes RADIUS e servidores e clientes RADIUS,
abra as propriedades do cliente RADIUS. Em selecionar um modelo de segredos
compartilhados existente, selecione o modelo que você criou anteriormente na lista de
modelos disponíveis.
Clientes RADIUS
Um NAS (servidor de acesso à rede) é um dispositivo que fornece algum nível de acesso
a uma rede maior. Um NAS que usa uma infraestrutura RADIUS também é um cliente
RADIUS, enviando solicitações de conexão e mensagens de contabilidade para um
servidor RADIUS para autenticação, autorização e contabilidade.
７ Observação
Computadores cliente, como computadores laptop e outros computadores que

executam sistemas operacionais cliente, não são clientes RADIUS. Os clientes
RADIUS são servidores de acesso à rede , como pontos de acesso sem fio,
comutadores de autenticação 802,1X, servidores VPN (rede virtual privada) e
servidores discados, porque usam o protocolo RADIUS para se comunicar com
servidores RADIUS, como servidores NPS (Servidor de Políticas de Rede).
Para implantar o NPS como um servidor RADIUS ou um proxy RADIUS, você deve
configurar clientes RADIUS no NPS.
Exemplos de cliente RADIUS

Exemplos de servidores de acesso à rede são:
Servidores de acesso à rede que fornecem conectividade de acesso remoto a uma

rede da organização ou à Internet. Um exemplo é um computador que executa o
sistema operacional Windows Server 2016 e o serviço de Acesso Remoto que
fornece serviços tradicionais de acesso remoto de VPN (rede privada virtual) ou
discagem para uma intranet da organização.
Pontos de acesso sem fio que fornecem acesso de camada física a uma rede da
organização usando tecnologias de transmissão e recepção baseadas em sem fio.
Comutadores que fornecem acesso de camada física à rede de uma organização,
usando tecnologias de LAN tradicionais, como Ethernet.
Proxies RADIUS que encaminham solicitações de conexão para servidores RADIUS
que são membros de um grupo de servidores RADIUS remoto configurado no
proxy RADIUS.
MENSAGENS Access-Request RADIUS
Os clientes RADIUS criam mensagens radius Access-Request e as encaminham para um
proxy RADIUS ou servidor RADIUS ou encaminham mensagens Access-Request para um
servidor RADIUS que receberam de outro cliente RADIUS, mas que não foram criadas
por conta própria.
Os clientes RADIUS não processam mensagens Access-Request executando

autenticação, autorização e contabilidade. Somente os servidores RADIUS executam
essas funções.
O NPS, no entanto, pode ser configurado como um proxy RADIUS e um servidor

RADIUS simultaneamente, para que ele processe algumas Access-Request mensagens e
encaminhe outras mensagens.
NPS como um cliente RADIUS

O NPS atua como um cliente RADIUS quando você o configura como um proxy RADIUS
para encaminhar Access-Request mensagens para outros servidores RADIUS para
processamento. Quando você usa o NPS como um proxy RADIUS, as seguintes etapas
de configuração geral são necessárias:
1. Os servidores de acesso à rede, como pontos de acesso sem fio e servidores VPN,
são configurados com o endereço IP do proxy NPS como o servidor RADIUS
designado ou o servidor de autenticação. Isso permite que os servidores de acesso
à rede, que criam Access-Request com base nas informações recebidas dos
clientes de acesso, encaminhem mensagens para o proxy NPS.
2. O proxy NPS é configurado adicionando cada servidor de acesso à rede como um

cliente RADIUS. Essa etapa de configuração permite que o proxy NPS receba
mensagens dos servidores de acesso à rede e se comunique com eles durante a
autenticação. Além disso, as políticas de solicitação de conexão no proxy NPS são
configuradas para especificar quais Access-Request mensagens para encaminhar
para um ou mais servidores RADIUS. Essas políticas também são configuradas com
um grupo de servidores RADIUS remoto, que informa ao NPS para onde enviar as
mensagens recebidas dos servidores de acesso à rede.
3. O NPS ou outros servidores RADIUS que são membros do grupo de servidores

RADIUS remoto no proxy NPS são configurados para receber mensagens do proxy
NPS. Isso é feito configurando o proxy NPS como um cliente RADIUS.
Propriedades do cliente RADIUS
Ao adicionar um cliente RADIUS à configuração do NPS por meio do console NPS ou
por meio do uso dos comandos netsh para comandos NPS ou Windows PowerShell,
você está configurando o NPS para receber mensagens RADIUS Access-Request de um
servidor de acesso à rede ou de um proxy RADIUS.
Ao configurar um cliente RADIUS no NPS, você pode designar as seguintes

propriedades:
Nome do cliente
Um nome amigável para o cliente RADIUS, que facilita a identificação ao usar os
comandos nps snap-in ou netsh para NPS.
Endereço IP
O protocolo IP versão 4 (IPv4) ou o nome DNS (Sistema de Nomes de Domínio) do
cliente RADIUS.
Client-Vendor
O fornecedor do cliente RADIUS. Caso contrário, você pode usar o valor padrão RADIUS
para Client-Vendor.
Segredo compartilhado
Uma cadeia de caracteres de texto usada como uma senha entre clientes RADIUS,
servidores RADIUS e proxies RADIUS. Quando o atributo Message Authenticator é
usado, o segredo compartilhado também é usado como a chave para criptografar
mensagens RADIUS. Essa cadeia de caracteres deve ser configurada no cliente RADIUS e
no snap-in NPS.
Atributo Authenticator mensagem

Descrito em RFC 2869, "Extensões RADIUS", um hash MD5 (Message Digest 5) de toda a
mensagem RADIUS. Se o atributo radius message Authenticator estiver presente, ele
será verificado. Se a verificação falhar, a mensagem RADIUS será descartada. Se as
configurações do cliente exigirem Authenticator atributo Message e ele não estiver
presente, a mensagem RADIUS será descartada. O uso do atributo Authenticator
mensagem é recomendado.
７ Observação
O atributo Message Authenticator é necessário e habilitado por padrão quando

você usa a autenticação EAP (Extensible Authentication Protocol).
Este tópico fornece links para informações sobre o planejamento de implantações de

NPS e proxy.
７ Observação
Para obter a documentação adicional do servidor de políticas de rede, você pode


Esta seção inclui os seguintes tópicos.
Planejar NPS como um servidor RADIUS

Planejar NPS como um proxy RADIUS
Planejar NPS como um servidor RADIUS
Quando você implanta o NPS (Servidor de Políticas de Rede) como um servidor RADIUS
(Remote Authentication Dial-In User Service), o NPS executa autenticação, autorização e
contabilização de solicitações de conexão para o domínio local e para domínios que
confiam no domínio local. Você pode usar essas diretrizes de planejamento para
simplificar sua implantação radius.
Essas diretrizes de planejamento não incluem circunstâncias nas quais você deseja
implantar o NPS como um proxy RADIUS. Quando você implanta o NPS como um proxy
RADIUS, o NPS encaminha solicitações de conexão para um servidor que executa o NPS
ou outros servidores RADIUS em domínios remotos, domínios não confiáveis ou ambos.
Antes de implantar o NPS como um servidor RADIUS em sua rede, use as diretrizes a
seguir para planejar sua implantação.
Planejar a configuração do NPS.
Planejar clientes RADIUS.
Planeje o uso de métodos de autenticação.
Planejar políticas de rede.
Planejar a contabilidade do NPS.
Planejar a configuração do NPS

Você deve decidir em qual domínio o NPS é membro. Para ambientes de vários
domínios, um NPS pode autenticar credenciais para contas de usuário no domínio do
qual ele é membro e para todos os domínios que confiam no domínio local do NPS.
Para permitir que o NPS leia as propriedades discadas de contas de usuário durante o
processo de autorização, você deve adicionar a conta de computador do NPS ao grupo
RAS e NPSs para cada domínio.
Depois de determinar a associação de domínio do NPS, o servidor deve ser configurado

para se comunicar com clientes RADIUS, também chamados de servidores de acesso à
rede, usando o protocolo RADIUS. Além disso, você pode configurar os tipos de eventos
que o NPS registra no log de eventos e pode inserir uma descrição para o servidor.
Etapas principais
Durante o planejamento da configuração do NPS, você pode usar as etapas a seguir.
Determine as portas RADIUS que o NPS usa para receber mensagens RADIUS de
clientes RADIUS. As portas padrão são as portas UDP 1812 e 1645 para mensagens
de autenticação RADIUS e as portas 1813 e 1646 para mensagens de contabilidade
RADIUS.
Se o NPS estiver configurado com vários adaptadores de rede, determine os

adaptadores sobre os quais você deseja que o tráfego RADIUS seja permitido.
Determine os tipos de eventos que você deseja que o NPS registre no Log de
Eventos. Você pode registrar solicitações de autenticação rejeitadas, solicitações de
autenticação bem-sucedidas ou ambos os tipos de solicitações.
Determine se você está implantando mais de um NPS. Para fornecer tolerância a

falhas para autenticação e contabilidade baseadas em RADIUS, use pelo menos
dois NPSs. Um NPS é usado como o servidor RADIUS primário e o outro é usado
como backup. Cada cliente RADIUS é configurado em ambos os NPSs. Se o NPS
primário ficar indisponível, os clientes RADIUS Access-Request mensagens para o
NPS alternativo.
Planeje o script usado para copiar uma configuração do NPS para outros NPSs
para economizar na sobrecarga administrativa e evitar a cofiguração incorreta de
um servidor. O NPS fornece os comandos Netsh que permitem copiar toda ou
parte de uma configuração do NPS para importação para outro NPS. Você pode
executar os comandos manualmente no prompt do Netsh. No entanto, se você
salvar a sequência de comandos como um script, poderá executar o script em uma
data posterior se decidir alterar as configurações do servidor.
Planejar clientes RADIUS

Os clientes RADIUS são servidores de acesso à rede, como pontos de acesso sem fio,
servidores VPN (rede virtual privada), comutadores com capacidade para 802.1X e
servidores discados. Os proxies RADIUS, que encaminham mensagens de solicitação de
conexão para servidores RADIUS, também são clientes RADIUS. O NPS dá suporte a
todos os servidores de acesso à rede e proxies RADIUS que estão em conformidade
com o protocolo RADIUS, conforme descrito em RFC 2865, "RADIUS (Serviço de Usuário
Discado de Autenticação Remota) e RFC 2866, "Contabilidade RADIUS".
） Importante
Os clientes de acesso, como computadores cliente, não são clientes RADIUS.
Somente servidores de acesso à rede e servidores proxy que suportam o protocolo
RADIUS são clientes RADIUS.
Além disso, os pontos de acesso sem fio e as opções devem ser capazes de
autenticação 802.1X. Se você quiser implantar o Protocolo de Autenticação Extensível
(EAP) ou o PEAP (Protocolo de Autenticação Extensível Protegido), os pontos de acesso
e as opções deverão dar suporte ao uso do EAP.
Para testar a interoperabilidade básica para conexões PPP para pontos de acesso sem
fio, configure o ponto de acesso e o cliente de acesso para usar o PROTOCOLO DE
AUTENTICAÇÃO de Senha (PAP). Use protocolos de autenticação adicionais baseados
em PPP, como PEAP, até que você teste aqueles que pretende usar para acesso à rede.
Etapas principais
Durante o planejamento de clientes RADIUS, você pode usar as etapas a seguir.
Documente os VSAs (atributos específicos do fornecedor) que você deve

configurar no NPS. Se os servidores de acesso à rede exigirem VSAs, registre as
informações do VSA para uso posterior ao configurar suas políticas de rede no
NPS.
Documente os endereços IP de clientes RADIUS e o NPS para simplificar a

configuração de todos os dispositivos. Ao implantar seus clientes RADIUS, você
deve configurá-los para usar o protocolo RADIUS, com o endereço IP NPS inserido
como o servidor de autenticação. E ao configurar o NPS para se comunicar com
seus clientes RADIUS, você deve inserir os endereços IP do cliente RADIUS no
snap-in do NPS.
Crie segredos compartilhados para configuração nos clientes RADIUS e no snap-in

do NPS. Você deve configurar clientes RADIUS com um segredo compartilhado ou
senha, que você também inserirá no snap-in nps ao configurar clientes RADIUS no
NPS.
Planejar o uso de métodos de autenticação

O NPS dá suporte a métodos de autenticação baseados em senha e de certificado. No
entanto, nem todos os servidores de acesso à rede são suportados pelos mesmos
métodos de autenticação. Em alguns casos, talvez você queira implantar um método de
autenticação diferente com base no tipo de acesso à rede.
Por exemplo, talvez você queira implantar o acesso sem fio e VPN para sua organização,
mas use um método de autenticação diferente para cada tipo de acesso: EAP-TLS para
conexões VPN, devido à segurança forte que o EAP com o EAP-TLS (Transport Layer
Security) fornece e PEAP-MS-CHAP v2 para conexões sem fio 802.1X.
O PEAP com o Protocolo de Autenticação de Handshake de Desafio da Microsoft versão

2 (PEAP-MS-CHAP v2) fornece um recurso chamado reconexão rápida, projetado
especificamente para uso com computadores portáteis e outros dispositivos sem fio. A
reconexão rápida permite que os clientes sem fio se movam entre pontos de acesso
sem fio na mesma rede sem serem autenticados novamente sempre que se associam a
um novo ponto de acesso. Isso fornece uma experiência melhor para usuários sem fio e
permite que eles se movam entre os pontos de acesso sem a necessidade de retipo de
suas credenciais.
Devido à reconexão rápida e à segurança que o PEAP-MS-CHAP v2
fornece, o PEAP-MS-CHAP v2 é uma opção lógica como um método de autenticação
para conexões sem fio.
Para conexões VPN, o EAP-TLS é um método de autenticação baseado em certificado

que fornece segurança forte que protege o tráfego de rede, mesmo quando ele é
transmitido pela Internet de computadores móveis ou de casa para os servidores VPN
da sua organização.
Métodos de autenticação baseados em certificado

Os métodos de autenticação baseados em certificado têm a vantagem de fornecer
segurança forte; e têm a desvantagem de serem mais difíceis de implantar do que os
métodos de autenticação baseados em senha.
PEAP-MS-CHAP v2 e EAP-TLS são métodos de autenticação baseados em certificado,

mas há muitas diferenças entre eles e a maneira como eles são implantados.
EAP-TLS
O EAP-TLS usa certificados para autenticação de cliente e servidor e requer que você
implante uma PKI (infraestrutura de chave pública) em sua organização. A implantação
de uma PKI pode ser complexa e requer uma fase de planejamento que seja
independente do planejamento para o uso do NPS como um servidor RADIUS.
Com o EAP-TLS, o NPS registra um certificado do servidor de uma AC (autoridade de

certificação) e o certificado é salvo no computador local no armazenamento de
certificados. Durante o processo de autenticação, a autenticação do servidor ocorre
quando o NPS envia seu certificado de servidor para o cliente de acesso para provar sua
identidade para o cliente de acesso. O cliente de acesso examina várias propriedades de
certificado para determinar se o certificado é válido e apropriado para uso durante a
autenticação do servidor. Se o certificado do servidor atender aos requisitos mínimos de
certificado do servidor e for emitido por uma AC em que o cliente de acesso confia, o
NPS será autenticado com êxito pelo cliente.
Da mesma forma, a autenticação do cliente ocorre durante o processo de autenticação

quando o cliente envia seu certificado de cliente para o NPS para provar sua identidade
para o NPS. O NPS examina o certificado e, se o certificado do cliente atende aos
requisitos mínimos de certificado do cliente e é emitido por uma AC em que o NPS
confia, o cliente de acesso é autenticado com êxito pelo NPS.
Embora seja necessário que o certificado do servidor seja armazenado no

armazenamento de certificados no NPS, o certificado do cliente ou do usuário pode ser
armazenado no armazenamento de certificados no cliente ou em um cartão inteligente.
Para que esse processo de autenticação seja bem-sucedido, é necessário que todos os
computadores tenham o certificado de autoridade de certificação da sua organização
no armazenamento de certificados autoridades de certificação raiz confiáveis para o
computador local e o usuário atual.
PEAP-MS-CHAP v2
PEAP-MS-CHAP v2 usa um certificado para autenticação de servidor e credenciais
baseadas em senha para autenticação de usuário. Como os certificados são usados
apenas para autenticação de servidor, você não precisa implantar uma PKI para usar
PEAP-MS-CHAP v2. Ao implantar o PEAP-MS-CHAP v2, você pode obter um certificado
do servidor para o NPS de uma das duas maneiras a seguir:
Você pode instalar Serviços de Certificados do Active Directory (AD CS) e, em

seguida, o registro automático de certificados no NPSs. Se você usar esse método,
também deverá registrar o certificado de AC em computadores cliente que se
conectam à sua rede para que eles confiem no certificado emitido para o NPS.
Você pode comprar um certificado do servidor de uma AC pública, como VeriSign.

Se você usar esse método, selecione uma AC que já seja confiável para
computadores cliente. Para determinar se os computadores cliente confiam em
uma AC, abra o snap-in MMC (Certificados Console de Gerenciamento Microsoft)
em um computador cliente e, em seguida, veja o armazenamento autoridades de
certificação raiz confiáveis para o computador local e para o usuário atual. Se
houver um certificado da AC nesses armazenamentos de certificados, o
computador cliente confiará na AC e, portanto, confiará em qualquer certificado
emitido pela AC.
Durante o processo de autenticação com PEAP-MS-CHAP v2, a autenticação do servidor
ocorre quando o NPS envia seu certificado do servidor para o computador cliente. O
cliente de acesso examina várias propriedades de certificado para determinar se o
certificado é válido e apropriado para uso durante a autenticação do servidor. Se o
certificado do servidor atender aos requisitos mínimos de certificado do servidor e for
emitido por uma AC em que o cliente de acesso confia, o NPS será autenticado com
êxito pelo cliente.
A autenticação do usuário ocorre quando um usuário tenta se conectar aos tipos de

rede com credenciais baseadas em senha e tenta fazer logoff. O NPS recebe as
credenciais e executa autenticação e autorização. Se o usuário for autenticado e
autorizado com êxito e se o computador cliente tiver autenticado com êxito o NPS, a
solicitação de conexão será concedida.
Etapas principais
Durante o planejamento do uso de métodos de autenticação, você pode usar as etapas
a seguir.
Identifique os tipos de acesso à rede que você planeja oferecer, como sem fio,
VPN, com opção 802.1X e acesso discado.
Determine o método de autenticação ou os métodos que você deseja usar para

cada tipo de acesso. É recomendável que você use os métodos de autenticação
baseados em certificado que fornecem segurança forte; no entanto, pode não ser
prático implantar uma PKI, portanto, outros métodos de autenticação podem
fornecer um melhor equilíbrio do que você precisa para sua rede.
Se você estiver implantando o EAP-TLS, planeje sua implantação de PKI. Isso inclui
o planejamento dos modelos de certificado que você usará para certificados de
servidor e certificados de computador cliente. Ele também inclui determinar como
registrar certificados em computadores membros do domínio e não membros do
domínio e determinar se você deseja usar cartões inteligentes.
Se você estiver implantando PEAP-MS-CHAP v2, determine se deseja instalar o AD

CS para emitir certificados de servidor para seus NPSs ou se deseja comprar
certificados de servidor de uma AC pública, como VeriSign.
Planejar políticas de rede

As políticas de rede são usadas pelo NPS para determinar se as solicitações de conexão
recebidas de clientes RADIUS estão autorizadas. O NPS também usa as propriedades
discadas da conta de usuário para fazer uma determinação de autorização.
Como as políticas de rede são processadas na ordem em que aparecem no snap-in nps,
planeje colocar suas políticas mais restritivas primeiro na lista de políticas. Para cada
solicitação de conexão, o NPS tenta corresponder as condições da política com as
propriedades da solicitação de conexão. O NPS examina cada política de rede na ordem
até encontrar uma combinação. Se ele não encontrar uma combinação, a solicitação de
conexão será rejeitada.
Etapas principais
Durante o planejamento de políticas de rede, você pode usar as etapas a seguir.
Determine a ordem de processamento do NPS preferencial das políticas de rede,

da mais restritiva à menos restritiva.
Determine o estado da política. O estado da política pode ter o valor de habilitado

ou desabilitado. Se a política estiver habilitada, o NPS avaliará a política durante a
execução da autorização. Se a política não estiver habilitada, ela não será avaliada.
Determine o tipo de política. Você deve determinar se a política foi projetada para
conceder acesso quando as condições da política são corresponderes pela
solicitação de conexão ou se a política foi projetada para negar acesso quando as
condições da política são corresponderem pela solicitação de conexão. Por
exemplo, se você quiser negar explicitamente o acesso sem fio aos membros de
um grupo Windows, poderá criar uma política de rede que especifique o grupo, o
método de conexão sem fio e que tenha uma configuração de tipo de política
negar acesso.
Determine se você deseja que o NPS ignore as propriedades discadas das contas
de usuário que são membros do grupo no qual a política se baseia. Quando essa
configuração não está habilitada, as propriedades discadas das contas de usuário
substituem as configurações configuradas nas políticas de rede. Por exemplo, se
uma política de rede estiver configurada que concede acesso a um usuário, mas as
propriedades discadas da conta de usuário para esse usuário estão definidas para
negar o acesso, o usuário terá o acesso negado. Mas se você habilitar a
configuração de tipo de política Ignorar propriedades discadas da conta de
usuário, o mesmo usuário terá acesso à rede.
Determine se a política usa a configuração de origem da política. Essa

configuração permite que você especifique facilmente uma origem para todas as
solicitações de acesso. As fontes possíveis são um Gateway de Serviços de Terminal
(Gateway de TS), um servidor de acesso remoto (VPN ou discagem), um servidor
DHCP, um ponto de acesso sem fio e um servidor da Autoridade de Registro de
Saúde. Como alternativa, você pode especificar uma fonte específica do
fornecedor.
Determine as condições que devem ser corresponder para que a política de rede
seja aplicada.
Determine as configurações aplicadas se as condições da política de rede

corresponderem à solicitação de conexão.
Determine se você deseja usar, modificar ou excluir as políticas de rede padrão.
Planejar a contabilidade do NPS

O NPS fornece a capacidade de registrar dados de contabilidade RADIUS, como
solicitações de contabilidade e autenticação de usuário, em três formatos: formato IAS,
formato compatível com banco de dados e registro Microsoft SQL Server registro em
log.
Formato IAS e formato compatível com banco de dados criam arquivos de log no NPS
local no formato de arquivo de texto.
O log SQL Server fornece a capacidade de fazer logoff em um banco de dados em

conformidade com XML do SQL Server 2000 ou SQL Server 2005, estendendo a
contabilidade RADIUS para aproveitar as vantagens do registro em log para um banco
de dados relacional.
Etapas principais
Durante o planejamento da contabilidade do NPS, você pode usar as etapas a seguir.
Determine se você deseja armazenar dados de contabilidade NPS em arquivos de

log ou em um banco SQL Server dados.
Contabilidade do NPS usando arquivos de log locais

A gravação de solicitações de contabilidade e autenticação de usuário em arquivos de
log é usada principalmente para fins de análise de conexão e cobrança e também é útil
como uma ferramenta de investigação de segurança, fornecendo um método para
acompanhar a atividade de um usuário mal-intencionado após um ataque.
Etapas principais
Durante o planejamento da contabilidade do NPS usando arquivos de log locais, você
pode usar as etapas a seguir.
Determine o formato de arquivo de texto que você deseja usar para seus arquivos
de log NPS.
Escolha o tipo de informação que você deseja registrar em log. Você pode registrar
solicitações de contabilidade, solicitações de autenticação e status periódico.
Determine o local do disco rígido em que você deseja armazenar os arquivos de

log.
Projete sua solução de backup de arquivo de log. O local do disco rígido em que
você armazena os arquivos de log deve ser um local que permite que você faça
backup facilmente de seus dados. Além disso, o local do disco rígido deve ser
protegido configurando a ACL (lista de controle de acesso) para a pasta em que os
arquivos de log estão armazenados.
Determine a frequência na qual você deseja que novos arquivos de log sejam
criados. Se você quiser que os arquivos de log sejam criados com base no
tamanho do arquivo, determine o tamanho máximo permitido do arquivo antes
que um novo arquivo de log seja criado pelo NPS.
Determine se você deseja que o NPS exclua arquivos de log mais antigos se o
disco rígido ficar sem espaço de armazenamento.
Determine o aplicativo ou os aplicativos que você deseja usar para exibir dados de
contabilidade e produzir relatórios.
Registro em log SQL Server NPS

O log SQL Server NPS é usado quando você precisa de informações de estado de
sessão, para fins de criação de relatório e análise de dados, e para centralizar e
simplificar o gerenciamento de seus dados de contabilidade.
O NPS fornece a capacidade de usar o log do SQL Server para registrar solicitações de
autenticação e contabilidade de usuário recebidas de um ou mais servidores de acesso
à rede para uma fonte de dados em um computador que executa o Mecanismo de Área
de Trabalho do Microsoft SQL Server (MSDE 2000) ou qualquer versão do SQL Server
posterior ao SQL Server 2000.
Os dados de contabilidade são passados do NPS no formato XML para um

procedimento armazenado no banco de dados, que dá suporte a linguagem de consulta
estruturada (SQL) e XML (SQLXML). A gravação de solicitações de autenticação e
contabilidade de usuário em um banco de dados em conformidade com XML SQL
Server permite que vários NPSs tenham uma fonte de dados.
Etapas principais
Durante o planejamento da contabilidade do NPS usando o nps SQL Server log, você
pode usar as etapas a seguir.
Determine se você ou outro membro da sua organização tem uma experiência de

desenvolvimento de banco de dados relacional do SQL Server 2000 ou SQL Server
2005 e você entende como usar esses produtos para criar, modificar, administrar e
gerenciar bancos de dados SQL Server.
Determine se SQL Server está instalado no NPS ou em um computador remoto.
Projete o procedimento armazenado que você usará em seu banco de dados SQL
Server para processar arquivos XML de entrada que contêm dados de
contabilidade NPS.
Projete a estrutura SQL Server e o fluxo de replicação de banco de dados.
Determine o aplicativo ou os aplicativos que você deseja usar para exibir dados de
contabilidade e produzir relatórios.
Planeje usar servidores de acesso à rede que enviam o atributo Class em todas as
solicitações de contabilidade. O atributo Class é enviado ao cliente RADIUS em
uma mensagem Access-Accept e é útil para correlacionar mensagens Accounting-
Request com sessões de autenticação. Se o atributo Class for enviado pelo servidor
de acesso à rede nas mensagens de solicitação de contabilidade, ele poderá ser
usado para corresponder aos registros de contabilidade e autenticação. A
combinação dos atributos Unique-Serial-Number, Service-Reboot-Time e Server-
Address deve ser uma identificação exclusiva para cada autenticação que o
servidor aceita.
Planeje usar servidores de acesso à rede que deem suporte à contabilidade

provisória.
Planeje usar servidores de acesso à rede que enviam mensagens de contabilidade

e contabilidade.
Planeje usar servidores de acesso à rede que deem suporte ao armazenamento e

encaminhamento de dados de contabilidade. Os servidores de acesso à rede que
suportam esse recurso podem armazenar dados de contabilidade quando o
servidor de acesso à rede não pode se comunicar com o NPS. Quando o NPS está
disponível, o servidor de acesso à rede encaminha os registros armazenados para
o NPS, fornecendo maior confiabilidade na contabilidade em servidores de acesso
à rede que não fornecem esse recurso.
Planeje sempre configurar o atributo Acct-Interim-Interval em políticas de rede. O

atributo Acct-Interim-Interval define o intervalo (em segundos) entre cada
atualização provisória que o servidor de acesso à rede envia. De acordo com o RFC
2869, o valor do atributo Acct-Interim-Interval não deve ser menor que 60
segundos ou um minuto e não deve ser menor que 600 segundos ou 10 minutos.
Para obter mais informações, consulte RFC 2869, "Extensões RADIUS".
Verifique se o registro em log do status periódico está habilitado em seus NPSs.

Planejar NPS como um proxy RADIUS
Quando você implanta o NPS (Servidor de Políticas de Rede) como um proxy radius
(Remote Authentication Dial-In User Service), o NPS recebe solicitações de conexão de
clientes RADIUS, como servidores de acesso à rede ou outros proxies RADIUS, e, em
seguida, encaminha essas solicitações de conexão para servidores que executam NPS ou
outros servidores RADIUS. Você pode usar essas diretrizes de planejamento para
simplificar sua implantação radius.
Essas diretrizes de planejamento não incluem circunstâncias nas quais você deseja
implantar o NPS como um servidor RADIUS. Quando você implanta o NPS como um
servidor RADIUS, o NPS executa autenticação, autorização e contabilização para
solicitações de conexão para o domínio local e para domínios que confiam no domínio
local.
Antes de implantar o NPS como um proxy RADIUS em sua rede, use as diretrizes a
seguir para planejar sua implantação.
Planejar a configuração do NPS.
Planejar clientes RADIUS.
Planejar grupos de servidores RADIUS remotos.
Planejar regras de manipulação de atributo para encaminhamento de mensagens.
Planejar políticas de solicitação de conexão.
Planejar a contabilidade do NPS.
Planejar a configuração do NPS

Quando você usa o NPS como um proxy RADIUS, o NPS encaminha solicitações de
conexão para um NPS ou outros servidores RADIUS para processamento. Por isso, a
associação de domínio do proxy NPS é irrelevante. O proxy não precisa ser registrado
no Active Directory Domain Services (AD DS) porque ele não precisa de acesso às
propriedades discadas das contas de usuário. Além disso, você não precisa configurar
políticas de rede em um proxy NPS porque o proxy não executa autorização para
solicitações de conexão. O proxy NPS pode ser um membro de domínio ou pode ser um
servidor autônomo sem associação de domínio.
O NPS deve ser configurado para se comunicar com clientes RADIUS, também
chamados de servidores de acesso à rede, usando o protocolo RADIUS. Além disso,
você pode configurar os tipos de eventos que o NPS registra no log de eventos e pode
inserir uma descrição para o servidor.
Etapas principais
Durante o planejamento da configuração de proxy NPS, você pode usar as etapas a
seguir.
Determine as portas RADIUS que o proxy NPS usa para receber mensagens
RADIUS de clientes RADIUS e enviar mensagens RADIUS para membros de grupos
de servidores RADIUS remotos. As portas padrão do protocolo UDP são 1812 e
1645 para mensagens de autenticação RADIUS e portas UDP 1813 e 1646 para
mensagens de contabilidade RADIUS.
Se o proxy NPS estiver configurado com vários adaptadores de rede, determine os

adaptadores sobre os quais você deseja que o tráfego RADIUS seja permitido.
Determine os tipos de eventos que você deseja que o NPS registre no Log de
Eventos. Você pode registrar solicitações de conexão rejeitadas, solicitações de
conexão bem-sucedidas ou ambas.
Determine se você está implantando mais de um proxy NPS. Para fornecer

tolerância a falhas, use pelo menos dois proxies NPS. Um proxy NPS é usado como
o proxy RADIUS primário e o outro é usado como backup. Cada cliente RADIUS é
configurado em ambos os proxies NPS. Se o proxy NPS primário ficar indisponível,
os clientes RADIUS Access-Request mensagens para o proxy NPS alternativo.
Planeje o script usado para copiar uma configuração de proxy NPS para outros
proxies NPS para economizar na sobrecarga administrativa e evitar a configuração
incorreta de um servidor. O NPS fornece os comandos Netsh que permitem copiar
toda ou parte de uma configuração de proxy NPS para importação para outro
proxy NPS. Você pode executar os comandos manualmente no prompt do Netsh.
No entanto, se você salvar a sequência de comandos como um script, poderá
executar o script em uma data posterior se decidir alterar suas configurações de
proxy.
Planejar clientes RADIUS

Os clientes RADIUS são servidores de acesso à rede, como pontos de acesso sem fio,
servidores VPN (rede virtual privada), comutadores com capacidade para 802.1X e
servidores discados. Os proxies RADIUS, que encaminham mensagens de solicitação de
conexão para servidores RADIUS, também são clientes RADIUS. O NPS dá suporte a
todos os servidores de acesso à rede e proxies RADIUS que estão em conformidade
com o protocolo RADIUS, conforme descrito em RFC 2865, "RADIUS (Serviço de Usuário
Discado de Autenticação Remota)" e RFC 2866, "Contabilidade RADIUS".
Além disso, os pontos de acesso sem fio e as opções devem ser capazes de
autenticação 802.1X. Se você quiser implantar o Protocolo de Autenticação Extensível
(EAP) ou o PEAP (Protocolo de Autenticação Extensível Protegido), os pontos de acesso
e as opções deverão dar suporte ao uso do EAP.
Para testar a interoperabilidade básica para conexões PPP para pontos de acesso sem
fio, configure o ponto de acesso e o cliente de acesso para usar o PROTOCOLO DE
AUTENTICAÇÃO de Senha (PAP). Use protocolos de autenticação adicionais baseados
em PPP, como PEAP, até que você teste aqueles que pretende usar para acesso à rede.
Etapas principais
Durante o planejamento de clientes RADIUS, você pode usar as etapas a seguir.
Documente os VSAs (atributos específicos do fornecedor) que você deve

configurar no NPS. Se o NASS exigir VSAs, registre as informações do VSA para
uso posterior ao configurar suas políticas de rede no NPS.
Documente os endereços IP de clientes RADIUS e o proxy NPS para simplificar a

configuração de todos os dispositivos. Ao implantar seus clientes RADIUS, você
deve configurá-los para usar o protocolo RADIUS, com o endereço IP do proxy
NPS inserido como o servidor de autenticação. E ao configurar o NPS para se
comunicar com seus clientes RADIUS, você deve inserir os endereços IP do cliente
RADIUS no snap-in do NPS.
Crie segredos compartilhados para configuração nos clientes RADIUS e no snap-in

do NPS. Você deve configurar clientes RADIUS com um segredo compartilhado ou
senha, que você também inserirá no snap-in nps ao configurar clientes RADIUS no
NPS.
Planejar grupos de servidores RADIUS remotos

Ao configurar um grupo de servidores RADIUS remoto em um proxy NPS, você está
dizendo ao proxy NPS para onde enviar algumas ou todas as mensagens de solicitação
de conexão que ele recebe de servidores de acesso à rede e proxies NPS ou outros
proxies RADIUS.
Você pode usar o NPS como um proxy RADIUS para encaminhar solicitações de
conexão para um ou mais grupos de servidores RADIUS remotos, e cada grupo pode
conter um ou mais servidores RADIUS. Quando você quiser que o proxy NPS encaminhe
mensagens para vários grupos, configure uma política de solicitação de conexão por
grupo. A política de solicitação de conexão contém informações adicionais, como regras
de manipulação de atributo, que informam ao proxy NPS quais mensagens enviar ao
grupo de servidores RADIUS remoto especificado na política.
Você pode configurar grupos de servidores RADIUS remotos usando os comandos

Netsh para NPS, configurando grupos diretamente no snap-in NPS em Grupos de
Servidores RADIUS Remotos ou executando o assistente Nova Política de Solicitação de
Conexão.
Etapas principais
Durante o planejamento de grupos de servidores RADIUS remotos, você pode usar as
etapas a seguir.
Determine os domínios que contêm os servidores RADIUS para os quais você

deseja que o proxy NPS encaminhe solicitações de conexão. Esses domínios
contêm as contas de usuário para usuários que se conectam à rede por meio dos
clientes RADIUS implantados.
Determine se você precisa adicionar novos servidores RADIUS em domínios em

que RADIUS ainda não está implantado.
Documente os endereços IP dos servidores RADIUS que você deseja adicionar aos
grupos de servidores RADIUS remotos.
Determine quantos grupos de servidores RADIUS remotos você precisa criar. Em

alguns casos, é melhor criar um grupo de servidores RADIUS remoto por domínio
e, em seguida, adicionar os servidores RADIUS para o domínio ao grupo. No
entanto, pode haver casos em que você tenha uma grande quantidade de recursos
em um domínio, incluindo um grande número de usuários com contas de usuário
no domínio, um grande número de controladores de domínio e um grande
número de servidores RADIUS. Ou seu domínio pode abranger uma grande área
geográfica, fazendo com que você tenha servidores de acesso à rede e servidores
RADIUS em locais distantes uns dos outros. Nesses e possivelmente em outros
casos, você pode criar vários grupos de servidores RADIUS remotos por domínio.
Crie segredos compartilhados para configuração no proxy NPS e nos servidores
RADIUS remotos.
Planejar regras de manipulação de atributo

para encaminhamento de mensagens
As regras de manipulação de atributo, que são configuradas em políticas de solicitação
de conexão, permitem identificar as Access-Request que você deseja encaminhar para
um grupo de servidores RADIUS remoto específico.
Você pode configurar o NPS para encaminhar todas as solicitações de conexão para um
grupo de servidores RADIUS remoto sem usar regras de manipulação de atributo.
Se você tiver mais de um local para o qual deseja encaminhar solicitações de conexão,
no entanto, deverá criar uma política de solicitação de conexão para cada local e, em
seguida, configurar a política com o grupo de servidores RADIUS remoto para o qual
deseja encaminhar mensagens, bem como com as regras de manipulação de atributo
que dizem ao NPS quais mensagens encaminhar.
Você pode criar regras para os atributos a seguir.
Called-Station-ID. O número de telefone do NAS (servidor de acesso à rede). O

valor desse atributo é uma cadeia de caracteres. Você pode usar a sintaxe de
correspondência de padrões para especificar códigos de área.
Calling-Station-ID. O número de telefone usado pelo chamador. O valor desse

atributo é uma cadeia de caracteres. Você pode usar a sintaxe de correspondência
de padrões para especificar códigos de área.
Nome de usuário. O nome de usuário fornecido pelo cliente de acesso e incluído

pelo NAS na mensagem RADIUS Access-Request. O valor desse atributo é uma
cadeia de caracteres que normalmente contém um nome de realm e um nome de
conta de usuário.
Para substituir ou converter corretamente nomes de realm no nome de usuário de uma

solicitação de conexão, você deve configurar regras de manipulação de atributo para o
atributo User-Name na política de solicitação de conexão apropriada.
Etapas principais
Durante o planejamento de regras de manipulação de atributo, você pode usar as
etapas a seguir.
Planeje o roteamento de mensagens do NAS por meio do proxy para os servidores
RADIUS remotos para verificar se você tem um caminho lógico com o qual
encaminhar mensagens para os servidores RADIUS.
Determine um ou mais atributos que você deseja usar para cada política de
Documente as regras de manipulação de atributo que você planeja usar para cada
política de solicitação de conexão e corresponder as regras ao grupo de servidores
RADIUS remoto ao qual as mensagens são encaminhadas.
Planejar políticas de solicitação de conexão

A política de solicitação de conexão padrão é configurada para NPS quando é usada
como um servidor RADIUS. Políticas de solicitação de conexão adicionais podem ser
usadas para definir condições mais específicas, criar regras de manipulação de atributo
que dizem ao NPS quais mensagens encaminhar para grupos de servidores RADIUS
remotos e especificar atributos avançados. Use o Assistente para Nova Política de
Solicitação de Conexão para criar políticas de solicitação de conexão comuns ou
personalizadas.
Etapas principais
Durante o planejamento de políticas de solicitação de conexão, você pode usar as
etapas a seguir.
Exclua a política de solicitação de conexão padrão em cada servidor que executa o

NPS que funciona exclusivamente como um proxy RADIUS.
Planeje as condições e as configurações adicionais necessárias para cada política,

combinando essas informações com o grupo de servidores RADIUS remoto e as
regras de manipulação de atributo planejadas para a política.
Projete o plano para distribuir políticas comuns de solicitação de conexão para

todos os proxies NPS. Crie políticas comuns a vários proxies NPS em um NPS e, em
seguida, use os comandos Netsh para NPS para importar as políticas de solicitação
de conexão e a configuração do servidor em todos os outros proxies.
Planejar a contabilidade do NPS

Ao configurar o NPS como um proxy RADIUS, você pode configurá-lo para executar a
contabilização RADIUS usando arquivos de log de formato NPS, arquivos de log de
formato compatíveis com o banco de dados ou nps SQL Server log.
Você também pode encaminhar mensagens de contabilidade para um grupo de

servidores RADIUS remoto que executa a contabilidade usando um desses formatos de
log.
Etapas principais
Durante o planejamento da contabilidade do NPS, você pode usar as etapas a seguir.
Determine se você deseja que o proxy NPS execute serviços de contabilidade ou

encaminhe mensagens de contabilidade para um grupo de servidores RADIUS
remoto para contabilidade.
Planeje desabilitar a contabilização de proxy NPS local se você planeja encaminhar

mensagens de contabilidade para outros servidores.
Planeje as etapas de configuração da política de solicitação de conexão se você

planeja encaminhar mensagens de contabilidade para outros servidores. Se você
desabilitar a contabilidade local para o proxy NPS, cada política de solicitação de
conexão configurada nesse proxy deverá ter o encaminhamento de mensagens de
contabilidade habilitado e configurado corretamente.
Determine o formato de log que você deseja usar: arquivos de log de formato IAS,
arquivos de log de formato compatíveis com o banco de dados ou nps SQL Server
log.
Para configurar o balanceamento de carga para NPS como um proxy RADIUS, consulte
Balanceamento de carga do servidor proxy NPS.
Implantar o Servidor de Políticas de
Rede
Você pode usar este tópico para obter informações sobre como implantar o Servidor de
Política de Rede.
７ Observação
Para documentação adicional do Servidor de Política de Rede, você pode usar as

seções de biblioteca a seguir.

O guia de rede do Windows Server 2016 Core inclui uma seção sobre planejamento e
instalação do NPS (Servidor de Política de Rede) e as tecnologias apresentadas no guia
servem como pré-requisitos para implantar o NPS em um domínio do Active Directory.
Para obter mais informações, consulte a seção "Implantar NPS1" no guia de rede do
Implantar certificados NPS para VPN e acesso

802.1X
Se você quiser implantar métodos de autenticação como o Protocolo de Autenticação
Extensível (EAP) e o EAP Protegido que exigem o uso de certificados de servidor em seu
NPS, você pode implantar certificados NPS com o guia Implantar Certificados de
Servidor para Implantações Com Fio e Sem Fio 802.1X.
Implantar o NPS para acesso sem fio 802.1X

Para implantar o NPS para acesso sem fio, você pode usar o guia Implantar Password-
Based Acesso Sem Fio Autenticado 802.1X 802.1X.
Implantar o NPS para Windows 10 Acesso VPN
Você pode usar o NPS para processar solicitações de conexão para conexões Always On
VPN (Rede Virtual Privada) para funcionários remotos que estão usando computadores
e dispositivos em execução Windows 10.
Para obter mais informações, consulte o Tutorial de Implantação de VPN do Always On

de Acesso Remoto para Windows Server 2016 e Windows 10.
Gerenciar servidor de políticas de rede
(NPS)
Você pode usar os tópicos desta seção para gerenciar o servidor de políticas de rede.
７ Observação
Para obter a documentação adicional do servidor de políticas de rede, você pode


Gerenciamento de Servidor de Políticas de Rede com Ferramentas de

Administração
Configurar firewalls para tráfego RADIUS
Configurar a contabilização do Servidor de Políticas de Rede
Gerenciar certificados usados com o NPS
Gerenciar NPSs
Gerenciar modelos de NPS
Gerenciamento de Servidor de Políticas
de Rede com Ferramentas de
Administração
Você pode usar este tópico para saber mais sobre as ferramentas que você pode usar
para gerenciar seus NPSs.
Depois de instalar o NPS, você pode administrar NPSs:
Localmente, usando o snap-in do NPS Microsoft Management Console (MMC), o

console NPS estático em Ferramentas Administrativas, comandos Windows
PowerShell ou os comandos Do Shell de Rede (Netsh) para NPS.
Em um NPS remoto, usando o snap-in MMC do NPS, os comandos Netsh para
NPS, os comandos Windows PowerShell para NPS ou Conexão de Área de
Trabalho Remota.
Em uma estação de trabalho remota, usando a Conexão de Área de Trabalho
Remota em combinação com outras ferramentas, como o NPS MMC ou Windows
PowerShell.
７ Observação
Em Windows Server 2016, você pode gerenciar o NPS local usando o console do
NPS. Para gerenciar NPSs remotos e locais, você deve usar o snap-in MMC do NPS.
７ Observação
O Console do NPS e o snap-in do NPS MMC têm um limite de 256 caracteres para
todas as configurações que levam um valor de cadeia de caracteres. Isso inclui
todas as configurações que podem ser configuradas usando expressões regulares.
Para configurar valores de cadeia de caracteres que excedem 256 caracteres, você
pode usar os comandos NPS NETSH. Valores de cadeia de caracteres configurados
que excedem 256 caracteres não podem ser editados no Console do NPS ou no
snap-in do NPS MMC sem invalidá-los.
As seções a seguir fornecem instruções sobre como gerenciar seus NPSs locais e
remotos.
Configurar o NPS local usando o console do

NPS
Depois de instalar o NPS, você pode usar esse procedimento para gerenciar o NPS local
usando o NPS MMC.
Para configurar o NPS local usando o console do NPS

Servidor de Políticas de Rede. O console do NPS é aberto.
2. No console do NPS, clique em NPS (Local). No painel de detalhes, escolha

Configuração Padrão ou Configuração Avançada e siga um destes procedimentos
com base em sua seleção:
Se você escolher Configuração Padrão, selecione um cenário na lista e siga

as instruções para iniciar um assistente de configuração.
Se você escolher Configuração Avançada, clique na seta para expandir as
opções de Configuração Avançada e examine e configure as opções
disponíveis com base na funcionalidade NPS desejada – servidor RADIUS,
proxy RADIUS ou ambos.
Gerenciar vários NPSs usando o snap-in do

NPS MMC
Você pode usar esse procedimento para gerenciar o NPS local e vários NPSs remotos
usando o snap-in do NPS MMC.
Antes de executar o procedimento abaixo, você deve instalar o NPS no computador

local e em computadores remotos.
Dependendo das condições de rede e do número de NPSs que você gerencia usando o
snap-in do MMC do NPS, a resposta do snap-in do MMC pode ser lenta. Além disso, o
tráfego de configuração do NPS é enviado pela rede durante uma sessão de
administração remota usando o snap-in do NPS. Verifique se sua rede é fisicamente
segura e se os usuários mal-intencionados não têm acesso a esse tráfego de rede.
Para gerenciar vários NPSs usando o snap-in do NPS

1. Para abrir o MMC, execute Windows PowerShell como administrador. Em Windows
PowerShell, digite mmc e pressione ENTER. O Console de Gerenciamento
Microsoft será aberto.
3. Em Adicionar ou Remover Snap-ins, em Snap-ins disponíveis, role para baixo na
lista, clique em Servidor de Política de Rede e clique em Adicionar. A caixa de
diálogo Selecionar Computador será aberta.
4. Em Selecionar Computador, verifique se o computador local (o computador no
qual este console está em execução) está selecionado e clique em OK. O snap-in
do NPS local é adicionado à lista em Snap-ins selecionados.
5. Em Adicionar ou Remover Snap-ins, em Snap-ins disponíveis, verifique se o
Servidor de Política de Rede ainda está selecionado e clique em Adicionar. A caixa
de diálogo Selecionar Computador é aberta novamente.
6. Em Selecionar Computador, clique em Outro computador e digite o endereço IP
ou o FQDN (nome de domínio totalmente qualificado) do NPS remoto que você
deseja gerenciar usando o snap-in do NPS. Opcionalmente, você pode clicar em
Procurar para percorrer o diretório do computador que deseja adicionar. Clique
em OK.
7. Repita as etapas 5 e 6 para adicionar mais NPSs ao snap-in do NPS. Quando você
tiver adicionado todos os NPSs que deseja gerenciar, clique em OK.
8. Para salvar o snap-in do NPS para uso posterior, clique em Arquivo e clique em
Salvar. Na caixa de diálogo Salvar como, navegue até o local do disco rígido em
que deseja salvar o arquivo, digite um nome para o arquivo do Console de
Gerenciamento do Microsoft (.msc) e clique em Salvar.
Gerenciar um NPS usando a conexão de área

de trabalho remota
Você pode usar esse procedimento para gerenciar um NPS remoto usando a Conexão
de Área de Trabalho Remota.
Usando a Conexão de Área de Trabalho Remota, você pode gerenciar remotamente seus
NPSs executando Windows Server 2016. Você também pode gerenciar remotamente
NPSs de um computador que executa sistemas operacionais cliente windows Windows
10 ou anteriores.
Você pode usar a conexão de Área de Trabalho Remota para gerenciar vários NPSs
usando um dos dois métodos.
1. Crie uma conexão de Área de Trabalho Remota para cada um de seus NPSs
individualmente.
2. Use a Área de Trabalho Remota para se conectar a um NPS e, em seguida, use o
MMC do NPS nesse servidor para gerenciar outros servidores remotos. Para obter
mais informações, consulte a seção anterior Gerenciar vários NPSs usando o
snap-in do MMC do NPS.
no NPS.
Para gerenciar um NPS usando a Conexão de Área de

Trabalho Remota
1. Em cada NPS que você deseja gerenciar remotamente, em Gerenciador do
Servidor, selecione Servidor Local. No painel de detalhes do Gerenciador do
Servidor, exiba a configuração área de trabalho remota e siga um destes
procedimentos.
a. Se o valor da configuração da Área de Trabalho Remota estiver Habilitado,
você não precisará executar algumas das etapas neste procedimento. Pule para
a Etapa 4 para começar a configurar permissões de Usuário da Área de Trabalho
Remota.
b. Se a configuração da Área de Trabalho Remota estiver Desabilitada, clique na
palavra Desabilitada. A caixa de diálogo Propriedades do Sistema é aberta na
guia Remoto .
2. Na Área de Trabalho Remota, clique em Permitir conexões remotas com este
computador. A caixa de diálogo Conexão de Área de Trabalho Remota é aberta.
Execute uma delas.
a. Para personalizar as conexões de rede permitidas, clique em Firewall do
Windows com Segurança Avançada e defina as configurações que você deseja
permitir.
b. Para habilitar a Conexão de Área de Trabalho Remota para todas as conexões
de rede no computador, clique em OK.
3. Em Propriedades do Sistema, na Área de Trabalho Remota, decida se deseja
habilitar Permitir conexões somente de computadores que executam a Área de
Trabalho Remota com Autenticação de Nível de Rede e faça sua seleção.
4. Clique em Selecionar Usuários. A caixa de diálogo Usuários da Área de Trabalho
Remota é aberta.
5. Em Usuários da Área de Trabalho Remota, para conceder permissão a um usuário
para se conectar remotamente ao NPS, clique em Adicionar e digite o nome de
usuário para a conta do usuário. Clique em OK.
6. Repita a etapa 5 para cada usuário para quem você deseja conceder permissão de
acesso remoto ao NPS. Quando terminar de adicionar usuários, clique em OK para
fechar a caixa de diálogo Usuários da Área de Trabalho Remota e OK novamente
para fechar a caixa de diálogo Propriedades do Sistema .
7. Para se conectar a um NPS remoto configurado usando as etapas anteriores, clique
em Iniciar, role para baixo na lista alfabética e clique em Acessórios do Windows e
clique em Conexão de Área de Trabalho Remota. A caixa de diálogo Conexão de
Área de Trabalho Remota é aberta.
8. Na caixa de diálogo Conexão de Área de Trabalho Remota , no Computador,
digite o nome do NPS ou o endereço IP. Se preferir, clique em Opções, configure
opções de conexão adicionais e clique em Salvar para salvar a conexão para uso
repetido.
9. Clique em Conectar e, quando solicitado, forneça credenciais de conta de usuário
para uma conta que tenha permissões para fazer logon e configurar o NPS.
Usar comandos NPS do Netsh para gerenciar

um NPS
Você pode usar comandos no contexto NPS do Netsh para mostrar e definir a
configuração do banco de dados de autenticação, autorização, contabilidade e auditoria
usado pelo NPS e pelo serviço de Acesso Remoto. Use comandos no contexto NPS do
Netsh para:
Configure ou reconfigure um NPS, incluindo todos os aspectos do NPS que

também estão disponíveis para configuração usando o console NPS na interface
do Windows.
Exporte a configuração de um NPS (o servidor de origem), incluindo chaves do
Registro e o repositório de configuração do NPS, como um script Netsh.
Importe a configuração para outro NPS usando um script Netsh e o arquivo de
configuração exportado do NPS de origem.
Você pode executar esses comandos no Prompt de Comando do Windows Server 2016
ou no Windows PowerShell. Você também pode executar comandos netsh nps em
scripts e arquivos em lote.
Para executar esse procedimento, você deve ser membro do grupo Administradores no
computador local.
Para inserir o contexto do NPS do Netsh em um NPS

1. Abra o Prompt de Comando ou Windows PowerShell.
2. Digite netsh e pressione ENTER.
3. Digite nps e pressione ENTER.
4. Para exibir uma lista de comandos disponíveis, digite um ponto de interrogação (?)
e pressione ENTER.
Para obter mais informações sobre comandos Netsh NPS, consulte Comandos netsh
para servidor de política de rede no Windows Server 2008 ou baixe toda a Referência
Técnica do Netsh da Galeria do TechNet. Este download é a Referência Técnica
completa do Shell de Rede para Windows Server 2008 e Windows Server 2008 R2. O
formato é a Ajuda do Windows (*.chm) em um arquivo zip. Esses comandos ainda estão
presentes em Windows Server 2016 e Windows 10, portanto, você pode usar netsh
nesses ambientes, embora o uso de Windows PowerShell seja recomendado.
Usar Windows PowerShell para gerenciar NPSs

Você pode usar Windows PowerShell comandos para gerenciar NPSs. Para obter mais
informações, consulte os tópicos de referência de comando do Windows PowerShell a
seguir.
Cmdlets do NPS (Servidor de Políticas de Rede) no Windows PowerShell. Você

pode usar esses comandos netsh no Windows Server 2012 R2 ou em sistemas
operacionais posteriores.
Módulo NPS. Você pode usar esses comandos netsh no Windows Server 2016.
Para obter mais informações sobre a administração do NPS, consulte Gerenciar O NPS
(Servidor de Políticas de Rede).
Configurar políticas de solicitação de
conexão
Você pode usar este tópico para criar e configurar políticas de solicitação de conexão
que designam se o NPS local processa solicitações de conexão ou as encaminha para o
servidor RADIUS remoto para processamento.
As políticas de solicitação de conexão são conjuntos de condições e configurações que

permitem que os administradores de rede designem quais servidores radius (Remote
Authentication Dial-In User Service) executam a autenticação e a autorização de
solicitações de conexão que o servidor que executa o NPS (Servidor de Políticas de
Rede) recebe de clientes RADIUS.
A política de solicitação de conexão padrão usa NPS como um servidor RADIUS e

processa todas as solicitações de autenticação localmente.
Para configurar um servidor que executa o NPS para atuar como um proxy RADIUS e
encaminhar solicitações de conexão para outros servidores NPS ou RADIUS, você deve
configurar um grupo de servidores RADIUS remoto, além de adicionar uma nova política
de solicitação de conexão que especifica condições e configurações que as solicitações
de conexão devem corresponder.
Você pode criar um novo grupo de servidores RADIUS remoto enquanto cria uma nova
política de solicitação de conexão com o Assistente para Nova Política de Solicitação de
Conexão.
Se você não quiser que o NPS atue como um servidor RADIUS e processe solicitações
de conexão localmente, exclua a política de solicitação de conexão padrão.
Se você quiser que o NPS atue como um servidor RADIUS, processando solicitações de
conexão localmente e como um proxy RADIUS, encaminhando algumas solicitações de
conexão para um grupo de servidores RADIUS remoto, adicione uma nova política
usando o procedimento a seguir e verifique se a política de solicitação de conexão
padrão é a última política processada colocando-a por último na lista de políticas.
Adicionar uma política de solicitação de
conexão
Para adicionar uma nova política de solicitação de

conexão
1. No Gerenciador do Servidor, clique em Ferramentas e, em seguida, clique em
Servidor de Política de Rede para abrir o console nps.
2. Na árvore de console, clique duas vezes em Políticas.
3. Clique com o botão direito do mouse em Políticas de Solicitação de Conexão e
clique em Nova Política de Solicitação de Conexão.
4. Use o Assistente para Nova Política de Solicitação de Conexão para configurar sua
política de solicitação de conexão e, se não estiver configurado anteriormente, um
grupo de servidores RADIUS remoto.
Para obter mais informações sobre como gerenciar o NPS, consulte Gerenciar servidor
de políticas de rede.
Configurar firewalls para tráfego
RADIUS
Os firewalls podem ser configurados para permitir ou bloquear tipos de tráfego IP de e

para o computador ou dispositivo no qual o firewall está sendo executado. Se os
firewalls não estão configurados corretamente para permitir o tráfego RADIUS entre
clientes RADIUS, proxies RADIUS e servidores RADIUS, a autenticação de acesso à rede
poderá falhar, impedindo que os usuários acessem recursos de rede.
Talvez seja necessário configurar dois tipos de firewalls para permitir o tráfego RADIUS:
Windows Defender Firewall com Segurança Avançada no servidor local que

executa o NPS (Servidor de Políticas de Rede).
Firewalls em execução em outros computadores ou dispositivos de hardware.
Windows firewall no NPS local

Por padrão, o NPS envia e recebe o tráfego RADIUS usando as portas UDP (User
Datagram Protocol) 1812, 1813, 1645 e 1646. Windows Defender Firewall no NPS deve
ser configurado automaticamente com exceções, durante a instalação do NPS, para
permitir que esse tráfego RADIUS seja enviado e recebido.
Com o Server 2019, essa exceção de firewall requer uma modificação no identificador de
segurança da conta de serviço para detectar e permitir efetivamente o tráfego RADIUS.
Se essa alteração do identificador de segurança não for executada, o firewall soltará o
tráfego RADIUS. Em um prompt de comandos com privilégios elevados, execute sc
sidtype IAS unrestricted . Esse comando altera o serviço RADIUS (IAS) para usar um SID
exclusivo em vez de compartilhar com outros serviços de SERVIÇO DE REDE.
Portanto, se você estiver usando as portas UDP padrão, não precisará alterar a
configuração do Firewall Windows Defender para permitir o tráfego RADIUS de e para
NPSs.
Em alguns casos, talvez você queira alterar as portas que o NPS usa para o tráfego
RADIUS. Se você configurar o NPS e seus servidores de acesso à rede para enviar e
receber tráfego RADIUS em portas diferentes dos padrões, faça o seguinte:
Remova as exceções que permitem o tráfego RADIUS nas portas padrão.
Crie novas exceções que permitem o tráfego RADIUS nas novas portas.
Para obter mais informações, consulte Configurar informações de porta UDP do NPS.
Outros firewalls
Na configuração mais comum, o firewall está conectado à Internet e o NPS é um recurso
de intranet conectado à rede de perímetro.
Para alcançar o controlador de domínio na intranet, o NPS pode ter:
Uma interface na rede de perímetro e uma interface na intranet (o roteamento ip

não está habilitado).
Uma única interface na rede de perímetro. Nessa configuração, o NPS se comunica
com controladores de domínio por meio de outro firewall que conecta a rede de
perímetro à intranet.
Configurando o firewall da Internet

O firewall conectado à Internet deve ser configurado com filtros de entrada e saída em
sua interface de Internet (e, opcionalmente, sua interface de perímetro de rede), para
permitir o encaminhamento de mensagens RADIUS entre os clientes NPS e RADIUS ou
proxies na Internet. Filtros adicionais podem ser usados para permitir a passagem de
tráfego para servidores Web, servidores VPN e outros tipos de servidores na rede de
perímetro.
Filtros de pacote de entrada e saída separados podem ser configurados na interface da

Internet e no interface de rede de perímetro.
Configurar filtros de entrada na interface da Internet

Configure os seguintes filtros de pacote de entrada na interface de Internet do firewall
para permitir os seguintes tipos de tráfego:
Endereço IP de destino do interface de rede de perímetro e porta de destino UDP

de 1812 (0x714) do NPS. Esse filtro permite o tráfego de autenticação RADIUS de
clientes RADIUS baseados na Internet para o NPS. Essa é a porta UDP padrão
usada pelo NPS, conforme definido no RFC 2865. Se você estiver usando uma
porta diferente, substitua esse número da porta por 1812.
Endereço IP de destino da interface de rede de perímetro e porta de destino UDP
de 1813 (0x715) do NPS. Esse filtro permite o tráfego de contabilidade RADIUS de
(Opcional) Endereço IP de destino da interface de rede de perímetro e porta de
destino UDP de 1645 (0x66D) do NPS. Esse filtro permite o tráfego de autenticação
RADIUS de clientes RADIUS baseados na Internet para o NPS. Essa é a porta UDP
usada por clientes RADIUS mais antigos.
destino UDP de 1646 (0x66E) do NPS. Esse filtro permite o tráfego de
contabilidade RADIUS de clientes RADIUS baseados na Internet para o NPS. Essa é
a porta UDP usada por clientes RADIUS mais antigos.
Configurar filtros de saída na interface da Internet

Configure os seguintes filtros de saída na interface de Internet do firewall para permitir
os seguintes tipos de tráfego:
Endereço IP de origem da interface de rede de perímetro e porta de origem UDP

de 1812 (0x714) do NPS. Esse filtro permite o tráfego de autenticação RADIUS do
NPS para clientes RADIUS baseados na Internet. Essa é a porta UDP padrão usada
pelo NPS, conforme definido no RFC 2865. Se você estiver usando uma porta
diferente, substitua esse número da porta por 1812.
Endereço IP de origem do interface de rede de perímetro e porta de origem UDP
de 1813 (0x715) do NPS. Esse filtro permite o tráfego de contabilidade RADIUS do
(Opcional) Endereço IP de origem do interface de rede de perímetro e porta de
origem UDP de 1645 (0x66D) do NPS. Esse filtro permite o tráfego de autenticação
RADIUS do NPS para clientes RADIUS baseados na Internet. Essa é a porta UDP
origem UDP de 1646 (0x66E) do NPS. Esse filtro permite o tráfego de contabilidade
Configurar filtros de entrada no interface de rede de

perímetro
Configure os seguintes filtros de entrada no interface de rede de perímetro do firewall
Endereço IP de origem da interface de rede de perímetro e porta de origem UDP

de 1812 (0x714) do NPS. Esse filtro permite o tráfego de autenticação RADIUS do
Endereço IP de origem do interface de rede de perímetro e porta de origem UDP
de 1813 (0x715) do NPS. Esse filtro permite o tráfego de contabilidade RADIUS do
origem UDP de 1645 (0x66D) do NPS. Esse filtro permite o tráfego de autenticação
origem UDP de 1646 (0x66E) do NPS. Esse filtro permite o tráfego de contabilidade
Configurar filtros de saída na interface de rede de

perímetro
Configure os seguintes filtros de pacote de saída no interface de rede de perímetro do
firewall para permitir os seguintes tipos de tráfego:
Endereço IP de destino do interface de rede de perímetro e porta de destino UDP

de 1812 (0x714) do NPS. Esse filtro permite o tráfego de autenticação RADIUS de
Endereço IP de destino da interface de rede de perímetro e porta de destino UDP
de 1813 (0x715) do NPS. Esse filtro permite o tráfego de contabilidade RADIUS de
destino UDP de 1645 (0x66D) do NPS. Esse filtro permite o tráfego de autenticação
RADIUS de clientes RADIUS baseados na Internet para o NPS. Essa é a porta UDP
destino UDP de 1646 (0x66E) do NPS. Esse filtro permite o tráfego de
contabilidade RADIUS de clientes RADIUS baseados na Internet para o NPS. Essa é
a porta UDP usada por clientes RADIUS mais antigos.
Para maior segurança, você pode usar os endereços IP de cada cliente RADIUS que
envia os pacotes por meio do firewall para definir filtros de tráfego entre o cliente e o
endereço IP do NPS na rede de perímetro.
Filtros no interface de rede de perímetro

Configure os seguintes filtros de pacote de entrada no interface de rede de perímetro
do firewall da intranet para permitir os seguintes tipos de tráfego:
Endereço IP de origem do interface de rede de perímetro do NPS. Esse filtro

permite o tráfego do NPS na rede de perímetro.
Configure os seguintes filtros de saída no interface de rede de perímetro do firewall da

intranet para permitir os seguintes tipos de tráfego:
Endereço IP de destino do interface de rede de perímetro do NPS. Esse filtro

permite o tráfego para o NPS na rede de perímetro.
Filtros na interface da intranet

Configure os seguintes filtros de entrada na interface de intranet do firewall para
permitir os seguintes tipos de tráfego:
Endereço IP de destino do interface de rede de perímetro do NPS. Esse filtro

permite o tráfego para o NPS na rede de perímetro.
Configure os seguintes filtros de pacote de saída na interface de intranet do firewall

Endereço IP de origem do interface de rede de perímetro do NPS. Esse filtro

permite o tráfego do NPS na rede de perímetro.
Você pode usar este tópico para configurar políticas de rede no NPS.
Adicionar uma política de rede

O NPS (Servidor de Políticas de Rede) usa políticas de rede e as propriedades discadas
de contas de usuário para determinar se uma solicitação de conexão está autorizada a
se conectar à rede.
Você pode usar esse procedimento para configurar uma nova política de rede no
console do NPS ou no console de Acesso Remoto.
Executando autorização
Quando o NPS executa a autorização de uma solicitação de conexão, ele compara a
solicitação com cada política de rede na lista ordenada de políticas, começando com a
primeira política e, em seguida, movendo para baixo a lista de políticas configuradas. Se
o NPS encontrar uma política cujas condições corresponderem à solicitação de conexão,
o NPS usará a política de correspondência e as propriedades discadas da conta de
usuário para executar a autorização. Se as propriedades discadas da conta de usuário
estão configuradas para conceder acesso ou controle por meio da política de rede e a
solicitação de conexão estiver autorizada, o NPS aplicará as configurações que estão
configuradas na política de rede à conexão.
Se o NPS não encontrar uma política de rede que corresponde à solicitação de conexão,
a solicitação de conexão será rejeitada, a menos que as propriedades discadas na conta
de usuário sejam definidas para conceder acesso.
Se as propriedades discadas da conta de usuário estão definidas para negar o acesso, a

solicitação de conexão é rejeitada pelo NPS.
Configurações de chave
Quando você usa o assistente de Nova Política de Rede para criar uma política de rede,
o valor especificado no método de conexão de rede é usado para configurar
automaticamente a condição Tipo de Política:
Se você manter o valor padrão de Não especificado, a política de rede que você
criar será avaliada pelo NPS para todos os tipos de conexão de rede que estão
usando qualquer tipo de NAS (servidor de acesso à rede).
Se você especificar um método de conexão de rede, o NPS avaliará a política de
rede somente se a solicitação de conexão for originada do tipo de servidor de
acesso à rede que você especificar.
Na página Permissão de Acesso, você deve selecionar Acesso concedido se quiser que
a política permita que os usuários se conectem à sua rede. Se você quiser que a política
impeça que os usuários se conectem à sua rede, selecione Acesso negado.
Se você quiser que a permissão de acesso seja determinada pelas propriedades discadas
da conta de usuário no AD DS (Active Directory® Domain Services), selecione a caixa de
seleção Acesso é determinado pelas propriedades discadas pelo usuário .

Para adicionar uma política de rede

1. Abra o console do NPS e clique duas vezes em Políticas.
2. Na árvore de console, clique com o botão direito do mouse em Políticas de Rede e

clique em Novo. O assistente Nova Diretiva de Rede é exibido.
3. Use o assistente Nova Política de Rede para criar uma política.
Criar políticas de rede para discagem ou VPN

com um Assistente
Você pode usar este procedimento para criar as políticas de solicitação de conexão e as
políticas de rede necessárias para implantar servidores discados ou servidores VPN
(rede virtual privada) como clientes radius (Remote Authentication Dial-In User Service)
no servidor NPS RADIUS.
７ Observação
Computadores cliente, como computadores laptop e outros computadores que

executam sistemas operacionais cliente, não são clientes RADIUS. Os clientes
RADIUS são servidores de acesso à rede , como pontos de acesso sem fio,
comutadores de autenticação 802,1X, servidores VPN (rede virtual privada) e
servidores discados, porque esses dispositivos usam o protocolo RADIUS para se
comunicar com servidores RADIUS, como NPSs.
Este procedimento explica como abrir o assistente Novas Conexões de Rede Discadas
ou Virtuais Privadas no NPS.
Depois de executar o assistente, as seguintes políticas são criadas:

Você pode executar o assistente Novas Conexões de Rede Discadas ou Virtuais Privadas
sempre que precisar criar novas políticas para servidores discados e servidores VPN.
A execução do assistente Novas Conexões de Rede Privada Virtual ou Discada não é a

única etapa necessária para implantar servidores de discagem ou VPN como clientes
RADIUS no NPS. Ambos os métodos de acesso à rede exigem que você implante
componentes adicionais de hardware e software.

Para criar políticas para discagem ou VPN com um

assistente
1. Abra o console do NPS. Se ele ainda não estiver selecionado, clique em NPS
(Local). Se você quiser criar políticas em um NPS remoto, selecione o servidor.
2. Em Ponto de Partida e Configuração Padrão, selecione Servidor RADIUS para

Conexões Dial-Up ou VPN. O texto e os links sob o texto mudam para refletir sua
seleção.
3. Clique em Configurar VPN ou Discar com um assistente. O assistente Novas

Conexões de Rede Privada Virtual ou Discadas é aberto.
4. Siga as instruções no assistente para concluir a criação de suas novas políticas.
Criar políticas de rede para 802.1X com ou sem

fio com um Assistente
Você pode usar este procedimento para criar a política de solicitação de conexão e a
política de rede necessárias para implantar comutadores de autenticação 802.1X ou
pontos de acesso sem fio 802.1X como clientes RADIUS (Remote Authentication Dial-In
User Service) no servidor NPS RADIUS.
Este procedimento explica como iniciar o assistente Novas Conexões Seguras com Fio e
Sem Fio do IEEE 802.1X no NPS.
Depois de executar o assistente, as seguintes políticas são criadas:

Você pode executar o assistente Novas Conexões Seguras com Fio e Sem Fio do IEEE
802.1X sempre que precisar criar novas políticas para acesso 802.1X.
A execução do assistente Novas Conexões Seguras com Fio e Sem Fio do IEEE 802.1X
não é a única etapa necessária para implantar comutadores de autenticação 802.1X e
pontos de acesso sem fio como clientes RADIUS no NPS. Ambos os métodos de acesso
à rede exigem que você implante componentes adicionais de hardware e software.

Para criar políticas para 802.1X com ou sem fio com um

assistente
1. No NPS, no Gerenciador do Servidor, clique em Ferramentas e, em seguida, clique
em Servidor de Política de Rede. O console NPS é aberto.
2. Se ele ainda não estiver selecionado, clique em NPS (Local). Se você quiser criar
políticas em um NPS remoto, selecione o servidor.
3. Em Ponto de Partida e Configuração Padrão, selecione Servidor RADIUS para

conexões sem fio ou com fio 802.1X. O texto e os links sob o texto mudam para
refletir sua seleção.
4. Clique em Configurar 802.1X usando um assistente. O assistente Novas Conexões

Seguras com Fio e Sem Fio do IEEE 802.1X é aberto.
5. Siga as instruções no assistente para concluir a criação de suas novas políticas.
Configurar o NPS para ignorar propriedades

discadas da conta de usuário
Use este procedimento para configurar uma política de rede NPS para ignorar as
propriedades discadas de contas de usuário no Active Directory durante o processo de
autorização. As contas de usuário Usuários e Computadores do Active Directory têm
propriedades discadas que o NPS avalia durante o processo de autorização, a menos
que a propriedade Permissão de Acesso à Rede da conta de usuário esteja definida
como Controlar o acesso por meio da Política de Rede NPS.
Há duas circunstâncias em que talvez você queira configurar o NPS para ignorar as
propriedades discadas de contas de usuário no Active Directory:
Quando você deseja simplificar a autorização do NPS usando a política de rede,

mas nem todas as suas contas de usuário têm a propriedade Permissão de Acesso
à Rede definida como Controlar o acesso por meio da Política de Rede NPS. Por
exemplo, algumas contas de usuário podem ter a propriedade Permissão de
Acesso à Rede da conta de usuário definida como Negar acesso ou Permitir
acesso.
Quando outras propriedades discadas de contas de usuário não são aplicáveis ao

tipo de conexão configurado na política de rede. Por exemplo, propriedades
diferentes da configuração de Permissão de Acesso à Rede são aplicáveis somente
a conexões de conexão discadas ou VPN, mas a política de rede que você está
criando é para conexões de comutdores sem fio ou autenticação.
Você pode usar esse procedimento para configurar o NPS para ignorar as propriedades
discadas da conta de usuário. Se uma solicitação de conexão corresponde à política de
rede em que essa caixa de seleção está marcada, o NPS não usa as propriedades
discadas da conta de usuário para determinar se o usuário ou o computador está
autorizado a acessar a rede; somente as configurações na política de rede são usadas
para determinar a autorização.
A associação em Administradores, ou equivalente, é o mínimo necessário para concluir

este procedimento.

2. Clique duas vezes em Políticas, clique em Políticas de Redee, no painel de

detalhes, clique duas vezes na política que você deseja configurar.
3. Na caixa de diálogo Propriedades da política, na guia Visão geral, em Permissão

de Acesso, marque a caixa de seleção Ignorar propriedades discadas da conta de
usuário e clique em OK.
Para configurar o NPS para ignorar as propriedades
discadas da conta de usuário
Configurar o NPS para VLANs

Usando servidores de acesso à rede com suporte para VLAN e NPS no Windows Server
2016, você pode fornecer a grupos de usuários acesso somente aos recursos de rede
apropriados para suas permissões de segurança. Por exemplo, você pode fornecer aos
visitantes acesso sem fio à Internet sem permitir que eles acessem a rede da sua
organização.
Além disso, as VLANs permitem agrupar logicamente os recursos de rede que existem
em diferentes locais físicos ou em sub-redes físicas diferentes. Por exemplo, os
membros do departamento de vendas e seus recursos de rede, como computadores
cliente, servidores e impressoras, podem estar localizados em vários edifícios diferentes
em sua organização, mas você pode colocar todos esses recursos em uma VLAN que
usa o mesmo intervalo de endereços IP. Em seguida, a VLAN funciona, da perspectiva
do usuário final, como uma única sub-rede.
Você também pode usar VLANs quando quiser separar uma rede entre diferentes
grupos de usuários. Depois de determinar como deseja definir seus grupos, você pode
criar grupos de segurança no snap-in Usuários e Computadores do Active Directory e,
em seguida, adicionar membros aos grupos.
Configurar uma política de rede para VLANs

Você pode usar esse procedimento para configurar uma política de rede que atribui
usuários a uma VLAN. Ao usar hardware de rede com suporte para VLAN, como
roteadores, comutadores e controladores de acesso, você pode configurar a política de
rede para instruir os servidores de acesso a colocar membros de grupos específicos do
Active Directory em VLANs específicas. Essa capacidade de agrupar recursos de rede
logicamente com VLANs fornece flexibilidade ao projetar e implementar soluções de
rede.
Ao definir as configurações de uma política de rede NPS para uso com VLANs, você
deve configurar os atributos Tunnel-Medium-Type, Tunnel-Pvt-Group-ID, Tunnel-Type
e Tunnel-Tag.
Este procedimento é fornecido como uma diretriz; sua configuração de rede pode exigir
configurações diferentes das descritas abaixo.
este procedimento.
Para configurar uma política de rede para VLANs


3. Na caixa de diálogo Propriedades da política, clique na guia Configurações

política.
4. Em Propriedades da política, em Configurações, em Atributos RADIUS, verifique

se Standard está selecionado.
5. No painel de detalhes, em Atributos, o atributo Service-Type é configurado com

um valor padrão de Framed. Por padrão, para políticas com métodos de acesso de
VPN e discagem, o atributo Framed-Protocol é configurado com um valor de PPP.
Para especificar atributos de conexão adicionais necessários para VLANs, clique em
Adicionar. A caixa de diálogo Adicionar Atributo RADIUS Padrão é aberta.
6. Em Adicionar Atributo RADIUS Padrão, em Atributos, role para baixo até e

adicione os seguintes atributos:
Tunnel tipo médio-médio. Selecione um valor apropriado para as seleções

anteriores feitas para a política. Por exemplo, se a política de rede que você
está configurando for uma política sem fio, selecione Valor : 802 (Inclui todas
as 802 mídias mais o formato canônico Ethernet).
Tunnel-Pvt-Group-ID. Insira o inteiro que representa o número da VLAN ao

qual os membros do grupo serão atribuídos.
Tunnel-Type. Selecione VLAN (Virtual LANs).
7. Em Adicionar Atributo RADIUS Padrão, clique em Fechar.
8. Se o NAS (servidor de acesso à rede) exigir o uso do atributo Tunnel-Tag, use as

etapas a seguir para adicionar o atributo Tunnel-Tag à política de rede. Se a
documentação do NAS não mencionar esse atributo, não adicione-o à política. Se
necessário, adicione os atributos da seguinte forma:
Em Propriedades da Política, em Configurações, em Atributos RADIUS, clique

em Específico do Fornecedor.
No painel de detalhes, clique em Adicionar. A caixa de diálogo Adicionar
Atributo Específico do Fornecedor é aberta.
Em Atributos, role para baixo até e selecione Tunnel-Tag e clique em

Adicionar. A caixa de diálogo Informações de Atributo é aberta.
Em Valor do atributo, digite o valor obtido na documentação de hardware.
Configurar o tamanho do payload de EAP

Em alguns casos, roteadores ou firewalls descartam pacotes porque estão configurados
para descartar pacotes que exigem fragmentação.
Quando você implanta o NPS com políticas de rede que usam o protocolo EAP com TLS
(Transport Layer Security) ou EAP-TLS, como um método de autenticação, a MTU
(unidade de transmissão máxima) padrão usada pelo NPS para cargas EAP é de 1500
bytes.
Esse tamanho máximo para o conteúdo de EAP pode criar mensagens RADIUS que
exigem fragmentação por um roteador ou firewall entre o NPS e um cliente RADIUS. Se
esse for o caso, um roteador ou firewall posicionado entre o cliente RADIUS e o NPS
poderá descartar silenciosamente alguns fragmentos, resultando em falha de
autenticação e na incapacidade do cliente de acesso de se conectar à rede.
Use o procedimento a seguir para reduzir o tamanho máximo que o NPS usa para
cargas EAP ajustando o atributo Framed-MTU em uma política de rede para um valor
não maior que 1344.

este procedimento.
Para configurar o atributo Framed-MTU


3. Na caixa de diálogo Propriedades da política, clique na guia Configurações

política.
4. No Configurações, em Atributos RADIUS, clique em Padrão. No painel de
detalhes, clique em Adicionar. A caixa de diálogo Adicionar Atributo RADIUS
Padrão é aberta.
5. Em Atributos, role para baixo até e clique em Framed-MTU e clique em Adicionar.

A caixa de diálogo Informações de Atributo é aberta.
6. Em Valor do Atributo, digite um valor igual ou menor que 1344. Clique em OK,
clique em Fechare em OK.
Para obter mais informações sobre políticas de rede, consulte Políticas de rede.
Para exemplos de sintaxe de correspondência de padrões para especificar atributos de

política de rede, consulte Usar expressões regulares no NPS.
Configurar a contabilização do Servidor
de Políticas de Rede
Há três tipos de registro em log para o NPS (Servidor de Políticas de Rede):
Registro em log de eventos. Usado principalmente para auditar e solucionar

problemas de tentativas de conexão. Você pode configurar o log de eventos do
NPS obtendo as propriedades do NPS no console do NPS.
Registro em log de solicitações de contabilidade e autenticação de usuário para

um arquivo local. Usado principalmente para fins de análise de conexão e
cobrança. Também é útil como uma ferramenta de investigação de segurança
porque ela fornece um método de acompanhamento da atividade de um usuário
mal-intencionado após um ataque. Você pode configurar o log de arquivos local
usando o assistente de Configuração de Contabilidade.
Registro em log de solicitações de contabilidade e autenticação de usuário para

Microsoft SQL Server banco de dados compatível com XML. Usado para permitir
que vários servidores que executam o NPS tenham uma fonte de dados. Também
fornece as vantagens de usar um banco de dados relacional. Você pode configurar
o SQL Server log usando o assistente de Configuração de Contabilidade.
Usar o assistente de Configuração de

Contabilidade
Usando o assistente de Configuração de Contabilidade, você pode definir as quatro
configurações de contabilidade a seguir:
SQL registro em log. Usando essa configuração, você pode configurar um link de
dados para um SQL Server que permite que o NPS se conecte e envie dados de
contabilidade para o SQL servidor. Além disso, o assistente pode configurar o
banco de dados no SQL Server para garantir que o banco de dados seja
compatível com o log SQL servidor NPS.
Somente registro em log de texto. Usando essa configuração, você pode
configurar o NPS para registrar dados de contabilidade em um arquivo de texto.
Registro em log paralelo. Usando essa configuração, você pode configurar o link
de SQL Server dados e o banco de dados. Você também pode configurar o log de
arquivo de texto para que o NPS seja logs simultaneamente para o arquivo de
texto e o banco de SQL Server dados.
SQL registro em log com backup. Usando essa configuração, você pode
configurar o link de SQL Server dados e o banco de dados. Além disso, você pode
configurar o log de arquivo de texto que o NPS usa se SQL Server registro em log
falhar.
Além dessas configurações, tanto o log SQL Server quanto o log de texto permitem que
você especifique se o NPS continuará a processar solicitações de conexão se o log
falhar. Você pode especificar isso na seção Ação de falha de registro em log nas
propriedades de log de arquivo local, nas propriedades de log do SQL do servidor e
durante a execução do Assistente de Configuração de Contabilidade.
Para executar o Assistente de Configuração de

Contabilidade
Para executar o Assistente de Configuração de Contabilidade, conclua as seguintes
etapas:
1. Abra o console NPS ou o snap-in nps Console de Gerenciamento Microsoft

(MMC).
2. Na árvore de console, clique em Contabilidade.
3. No painel de detalhes, em Contabilidade, clique em Configurar Contabilidade.
Configurar propriedades do arquivo de log do

NPS
Você pode configurar o NPS (Servidor de Políticas de Rede) para executar uma
contabilização radius (Remote Authentication Dial-In User Service) para solicitações de
autenticação de usuário, mensagens Access-Accept, mensagens Access-Reject,
solicitações de contabilidade e respostas e atualizações periódicas de status. Você pode
usar esse procedimento para configurar os arquivos de log nos quais deseja armazenar
os dados de contabilidade.
Para obter mais informações sobre como interpretar arquivos de log, consulte
Interpretar arquivos de log de formato de banco de dados NPS.
Para impedir que os arquivos de log preencham o disco rígido, é altamente

recomendável mantê-los em uma partição separada da partição do sistema. O seguinte
fornece mais informações sobre como configurar a contabilidade do NPS:
Para enviar os dados do arquivo de log para coleta por outro processo, você pode
configurar o NPS para gravar em um pipe nomeado. Para usar pipes nomeados, de
definir a pasta do arquivo de log como \.\pipe ou \ComputerName\pipe. O
programa de servidor de pipe nomeado cria um pipe nomeado chamado
\.\pipe\iaslog.log para aceitar os dados. Na caixa de diálogo Propriedades do
arquivo local, em Criar um novo arquivo de log, selecione Nunca (tamanho
ilimitado do arquivo) ao usar pipes nomeados.
O diretório de arquivo de log pode ser criado usando variáveis de ambiente do

sistema (em vez de variáveis de usuário), como %systemdrive%, %systemroot%e
%windir%. Por exemplo, o caminho a seguir, usando a variável de ambiente
%windir%, localiza o arquivo de log no diretório do sistema na subpasta
\System32\Logs (ou seja, %windir%\System32\Logs).
Alternar formatos de arquivo de log não faz com que um novo log seja criado. Se
você alterar os formatos de arquivo de log, o arquivo que estiver ativo no
momento da alteração conterá uma combinação dos dois formatos (os registros
no início do log terão o formato anterior e os registros no final do log terão o
novo formato).
Se a contabilidade RADIUS falhar devido a uma unidade de disco rígido completa

ou outras causas, o NPS para de processar solicitações de conexão, impedindo que
os usuários acessem recursos de rede.
O NPS fornece a capacidade de fazer logon em um banco de dados microsoft®

SQL Server ™ além de, ou em vez disso, fazer logon em um arquivo local.
A associação ao grupo Administradores de Domínio é o mínimo necessário para

executar este procedimento.
Para configurar as propriedades do arquivo de log do

NPS
(MMC).
3. No painel de detalhes, em Propriedades do Arquivo de Log, clique em Alterar
Propriedades do Arquivo de Log. A caixa de diálogo Propriedades do Arquivo de
Log é aberta.
4. Em Propriedades do Arquivo de Log, na guia Configurações, em Registrar as
informações a seguir, certifique-se de optar por registrar informações suficientes
para atingir suas metas de contabilidade. Por exemplo, se os logs precisam realizar
a correlação de sessão, marque todas as caixas de seleção.
5. Em Ação de falha de registro em log, selecione Se o log falhar , descarte as
solicitações de conexão se você quiser que o NPS pare o processamento Access-
Request mensagens quando os arquivos de log estão completos ou não
disponíveis por algum motivo. Se você quiser que o NPS continue processando
solicitações de conexão se o registro em log falhar, não marque essa caixa de
seleção.
6. Na caixa de diálogo Propriedades do Arquivo de Log , clique na guia Arquivo de
Log .
7. Na guia Arquivo de Log, em Diretório, digite o local em que você deseja
armazenar arquivos de log NPS. O local padrão é a pasta
systemroot\System32\LogFiles.
Se você não fornecer uma instrução de caminho completo no Diretório de

Arquivos de Log, o caminho padrão será usado. Por exemplo, se você digitar
NPSLogFile no Diretório de Arquivos de Log, o arquivo será localizado em
%systemroot%\System32\NPSLogFile.
8. Em Formato, clique em Compatível com DTS. Se preferir, você poderá selecionar
um formato de arquivo herdado, como ODBC ( Herdado) ou IAS (Herdado).
Os tipos de arquivoherdados ODBC e IAS contêm um subconjunto das

informações que o NPS envia para seu banco de SQL Server dados. O formato
XML do tipo de arquivo compatível com DTS é idêntico ao formato XML que o
NPS usa para importar dados para seu banco de dados SQL Server dados.
Portanto, o formato de arquivo em conformidade com DTS fornece uma
transferência mais eficiente e completa de dados para o banco de dados SQL
Server padrão para NPS.
9. Em Criar um novo arquivo de log, para configurar o NPS para iniciar novos
arquivos de log em intervalos especificados, clique no intervalo que você deseja
usar:
Para atividade de registro em log e volume de transações intensas, clique em

Diário.
Para volumes de transações menores e atividade de registro em log, clique
em Semanalou Mensal.
Para armazenar todas as transações em um arquivo de log, clique em Nunca
(tamanho ilimitado do arquivo).
Para limitar o tamanho de cada arquivo de log, clique em Quando o arquivo
de log atingir esse tamanho e digite um tamanho de arquivo, após o qual um
novo log é criado. O tamanho padrão é 10 MB (megabytes).
10. Se você quiser que o NPS exclua arquivos de log antigos para criar espaço em
disco para novos arquivos de log quando o disco rígido estiver próximo à
capacidade, verifique se Quando o disco estiver completo, a opção Excluir arquivos
de log mais antigos está selecionada. Essa opção não estará disponível, no
entanto, se o valor de Criar um novo arquivo de log for Nunca (tamanho
ilimitado do arquivo). Além disso, se o arquivo de log mais antigo for o arquivo de
log atual, ele não será excluído.
Configurar o registro em log SQL Server NPS

Você pode usar este procedimento para registrar dados de contabilidade RADIUS em
um banco de dados local ou remoto executando Microsoft SQL Server.
７ Observação
O NPS formatará dados de contabilidade como um documento XML que ele envia
para o report_event armazenado no banco de dados SQL Server que você designa
no NPS. Para SQL Server registro em log funcione corretamente, você deve ter um
procedimento armazenado chamado report_event no banco de dados SQL Server
que possa receber e analisar os documentos XML do NPS.

Para configurar SQL Server registro em log no NPS

(MMC).
3. No painel de detalhes, em Propriedades SQL Server Registro em Log, clique em
Alterar SQL Server Propriedades de Log. A caixa de SQL Server propriedades de
registro em log é aberta.
4. Em Registrar as seguintes informações, selecione as informações que você deseja
registrar:
Para registrar todas as solicitações de contabilidade, clique em Solicitações

de contabilidade.
Para registrar solicitações de autenticação, clique em Solicitações de
autenticação.
Para registrar o status de contabilidade periódico, clique em Status de
contabilidade periódica.
Para registrar o status periódico, como solicitações de contabilidade
provisórios, clique em Status periódico.
5. Para configurar o número de sessões simultâneas permitidas entre o servidor que

executa o NPS e o SQL Server, digite um número em Número máximo de sessões
simultâneas.
6. Para configurar a fonte SQL Server de dados, em SQL Server Log, clique em
Configurar. A caixa de diálogo Propriedades do Link de Dados é aberta. Na guia
Conexão , especifique o seguinte:
Para especificar o nome do servidor no qual o banco de dados está

armazenado, digite ou selecione um nome em selecionar ou insira um nome
de servidor.
para especificar o método de autenticação com o qual fazer logon no
servidor, clique em usar Windows NT segurança integrada. Ou então, clique
em usar um nome de usuário e senha específicose, em seguida, digite
credenciais em nome de usuário e senha.
Para permitir uma senha em branco, clique em senha em branco.
Para armazenar a senha, clique em permitir salvar senha.
para especificar o banco de dados ao qual se conectar no computador que
executa o SQL Server, clique em selecionar o banco de dados no servidore
selecione um nome de banco de dados na lista.
7. para testar a conexão entre o NPS e o SQL Server, clique em testar conexão.
Clique em OK para fechar as propriedades do vínculo de dados.
8. em ação de falha de log, selecione habilitar log de arquivo de texto para failover
se você quiser que o NPS continue com o log de arquivo de texto se SQL Server
log falhar.
9. Em ação de falha no log, selecione se o log falhar, descarte as solicitações de
conexão se desejar que o NPS pare de processar Access-Request mensagens
quando os arquivos de log estiverem cheios ou indisponíveis por algum motivo. Se
você quiser que o NPS continue a processar solicitações de conexão se o log
falhar, não marque essa caixa de seleção.
Ping de nome de usuário

Alguns servidores proxy RADIUS e servidores de acesso à rede enviam periodicamente
solicitações de autenticação e contabilização (conhecidas como solicitações de ping)
para verificar se o NPS está presente na rede. Essas solicitações de ping incluem nomes
de usuário fictícios. Quando o NPS processa essas solicitações, os logs de eventos e de
contabilidade se tornam preenchidos com registros de rejeição de acesso, tornando
mais difícil manter o controle de registros válidos.
Quando você configura uma entrada de registro para ping User-Name, o NPS
corresponde ao valor de entrada do registro em relação ao valor do nome de usuário
em solicitações de ping por outros servidores. Uma entrada de registro de nome de
usuário de ping especifica o nome de usuário fictício (ou um padrão de nome de
usuário, com variáveis que corresponde ao nome de usuário fictício) enviado por
servidores proxy RADIUS e servidores de acesso à rede. Quando o NPS recebe
solicitações de ping que correspondem ao valor de entrada de registro de nome de
usuário de ping , o NPS rejeita as solicitações de autenticação sem processar a
solicitação. O NPS não registra as transações que envolvem o nome de usuário fictício
em todos os arquivos de log, o que torna o log de eventos mais fácil de interpretar.
O ping User-Name não é instalado por padrão. Você deve adicionar ping User-Name
ao registro. Você pode adicionar uma entrada ao registro usando o editor do registro.
Ｕ Cuidado
a edição incorreta do Registro pode danificar gravemente o sistema. Antes de

alterar o Registro, faça backup de todos os dados importantes do computador.
Para adicionar ping User-Name ao registro

O ping User-Name pode ser adicionado à seguinte chave do registro como um valor de
cadeia de caracteres por um membro do grupo local de administradores:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IAS\Parameters
Nome:
Tipo:
Dados: nome de usuário
 Dica
Para indicar mais de um nome de usuário para um valor de nome de usuário de

ping , insira um padrão de nome, como um nome DNS, incluindo caracteres
curinga, em dados.
Você pode usar este tópico para configurar servidores de acesso à rede como clientes
RADIUS no NPS.
Ao adicionar um novo servidor de acesso à rede (servidor VPN, ponto de acesso sem fio,
opção de autenticação ou servidor discado) à sua rede, você deve adicionar o servidor
como um cliente RADIUS no NPS e, em seguida, configurar o cliente RADIUS para se
comunicar com o NPS.
） Importante
Computadores e dispositivos cliente, como laptops, tablets, telefones e outros

computadores que executam sistemas operacionais cliente, não são clientes
RADIUS. Os clientes RADIUS são servidores de acesso à rede , como pontos de
acesso sem fio, comutadores com capacidade para 802.1X, servidores VPN (rede
virtual privada) e servidores discados, porque usam o protocolo RADIUS para se
comunicar com servidores RADIUS, como servidores NPS (Servidor de Políticas de
Rede).
Essa etapa também é necessária quando o NPS é membro de um grupo de servidores

RADIUS remoto configurado em um proxy NPS. Nessa circunstância, além de executar
as etapas nesta tarefa no proxy NPS, você deve fazer o seguinte:
No proxy NPS, configure um grupo de servidores RADIUS remoto que contém o

NPS.
No NPS remoto, configure o proxy NPS como um cliente RADIUS.
Para executar os procedimentos neste tópico, você deve ter pelo menos um servidor de
acesso à rede (servidor VPN, ponto de acesso sem fio, comutador de autenticação ou
servidor discado) ou proxy NPS fisicamente instalado em sua rede.
Configurar o servidor de acesso à rede

Use este procedimento para configurar servidores de acesso à rede para uso com o
NPS. Ao implantar naSs (servidores de acesso à rede) como clientes RADIUS, você deve
configurar os clientes para se comunicarem com o NPSs em que os NASs estão
configurados como clientes.
Este procedimento fornece diretrizes gerais sobre as configurações que você deve usar
para configurar seus NASs; Para obter instruções específicas sobre como configurar o
dispositivo que você está implantando em sua rede, consulte a documentação do
produto NAS.
Para configurar o servidor de acesso à rede

1. No NAS, nas configurações radius, selecione Autenticação RADIUS na porta UDP
(User Datagram Protocol) 1812 e contabilidade RADIUS na porta UDP 1813.
2. Em Servidor de autenticaçãoou servidor RADIUS, especifique o NPS por endereço
IP ou FQDN (nome de domínio totalmente qualificado), dependendo dos
requisitos do NAS.
3. Em Segredo ou Segredo compartilhado, digite uma senha forte. Ao configurar o
NAS como um cliente RADIUS no NPS, você usará a mesma senha, portanto, não
se esqueça dela.
4. Se você estiver usando PEAP ou EAP como um método de autenticação, configure
o NAS para usar a autenticação EAP.
5. Se você estiver configurando um ponto de acesso sem fio, em SSID, especifique
um SSID (Identificador de Conjunto de Serviços), que é uma cadeia de caracteres
alfanumérico que serve como o nome da rede. Esse nome é transmitido por
pontos de acesso para clientes sem fio e é visível para os usuários em seus pontos
de acesso de fidelidade sem fio (Wi-Fi).
6. Se você estiver configurando um ponto de acesso sem fio, em 802.1X e WPA,
habilita a autenticação IEEE 802.1X se quiser implantar PEAP-MS-CHAP v2, PEAP-
TLS ou EAP-TLS.
Adicionar o servidor de acesso à rede como um

cliente RADIUS no NPS
Use este procedimento para adicionar um servidor de acesso à rede como um cliente
RADIUS no NPS. Você pode usar esse procedimento para configurar um NAS como um
cliente RADIUS usando o console do NPS.
Para adicionar um servidor de acesso à rede como um

cliente RADIUS no NPS
2. No console do NPS, clique duas vezes em Clientes e Servidores RADIUS. Clique
com o botão direito do mouse em Clientes RADIUS e clique em Novo Cliente
RADIUS.
3. Em Novo Cliente RADIUS, verifique se a caixa de seleção Habilitar este cliente
RADIUS está marcada.
4. Em Novo Cliente RADIUS, em Nome amigável, digite um nome de exibição para o
NAS. Em Endereço (IP ou DNS), digite o endereço IP do NAS ou o FQDN (nome de
domínio totalmente qualificado). Se você inserir o FQDN, clique em Verificar se
deseja verificar se o nome está correto e mapeia para um endereço IP válido.
5. Em Novo Cliente RADIUS, em Fornecedor, especifique o nome do fabricante do
NAS. Se você não tiver certeza do nome do fabricante do NAS, selecione Padrão
RADIUS.
6. Em Novo Cliente RADIUS, em Segredo compartilhado, faça um dos seguintes:
Verifique se Manual está selecionado e, em Segredo compartilhado, digite a

senha forte que também é inserida no NAS. Reescreva o segredo
compartilhado em Confirmar segredo compartilhado.
Selecione Gerar e clique em Gerar para gerar automaticamente um segredo
compartilhado. Salve o segredo compartilhado gerado para configuração no
NAS para que ele possa se comunicar com o NPS.
7. Em Novo Cliente RADIUS, em Opções Adicionais, se você estiver usando métodos

de autenticação diferentes de EAP e PEAP e se o NAS for compatível com o uso do
atributo de autenticador de mensagem, selecione Mensagens de solicitação de
acesso devem conter o atributo Authenticator mensagem.
8. Clique em OK. O NAS aparece na lista de clientes RADIUS configurados no NPS.
Configurar clientes RADIUS por intervalo de

endereços IP no Windows Server 2016
Datacenter
Se você estiver executando Windows Server 2016 Datacenter, poderá configurar clientes
RADIUS no NPS por intervalo de endereços IP. Isso permite adicionar um grande
número de clientes RADIUS (como pontos de acesso sem fio) ao console NPS ao mesmo
tempo, em vez de adicionar cada cliente RADIUS individualmente.
Você não poderá configurar clientes RADIUS por intervalo de endereços IP se estiver
executando o NPS Windows Server 2016 Standard.
Use este procedimento para adicionar um grupo de NASs (servidores de acesso à rede)
como clientes RADIUS configurados com endereços IP do mesmo intervalo de
endereços IP.
Todos os clientes RADIUS no intervalo devem usar a mesma configuração e o mesmo

segredo compartilhado.
Para configurar clientes RADIUS por intervalo de

endereços IP
2. No console do NPS, clique duas vezes em Clientes e Servidores RADIUS. Clique
com o botão direito do mouse em Clientes RADIUS e clique em Novo Cliente
RADIUS.
3. Em Novo Cliente RADIUS, em Nome amigável, digite um nome de exibição para a
coleção de NASs.
4. Em Endereço (IP ou DNS), digite o intervalo de endereços IP para os clientes
RADIUS usando a notação CIDR (roteamento de Inter-Domain classe). Por
exemplo, se o intervalo de endereços IP para o NASs for 10.10.0.0, digite
10.10.0.0/16.
5. Em Novo Cliente RADIUS, em Fornecedor, especifique o nome do fabricante do
NAS. Se você não tiver certeza do nome do fabricante do NAS, selecione Padrão
RADIUS.
6. Em Novo Cliente RADIUS, em Segredo compartilhado, faça um dos seguintes:
Verifique se Manual está selecionado e, em Segredo compartilhado, digite a

senha forte que também é inserida no NAS. Reescreva o segredo
compartilhado em Confirmar segredo compartilhado.
Selecione Gerar e clique em Gerar para gerar automaticamente um segredo
compartilhado. Salve o segredo compartilhado gerado para configuração no
NAS para que ele possa se comunicar com o NPS.
7. Em Novo Cliente RADIUS, em Opções Adicionais, se você estiver usando métodos

de autenticação diferentes de EAP e PEAP e se todos os seus NASs deem suporte
ao uso do atributo de autenticador de mensagem, selecione Mensagens de
solicitação de acesso devem conter o atributo Message Authenticator.
8. Clique em OK. Seus NASs aparecem na lista de clientes RADIUS configurados no
NPS.
Para obter mais informações, consulte Clientes RADIUS.
Configurar grupos de servidores
RADIUS remotos
Você pode usar este tópico para configurar grupos de servidores RADIUS remotos
quando quiser configurar o NPS para atuar como um servidor proxy e encaminhar
solicitações de conexão para outros NPSs para processamento.
Adicionar um grupo de servidores RADIUS

remoto
Você pode usar esse procedimento para adicionar um novo grupo de servidores
RADIUS remoto no snap-in NPS (Servidor de Políticas de Rede).
Ao configurar o NPS como um proxy RADIUS, você cria uma nova política de solicitação
de conexão que o NPS usa para determinar quais solicitações de conexão encaminhar
para outros servidores RADIUS. Além disso, a política de solicitação de conexão é
configurada especificando um grupo de servidores RADIUS remoto que contém um ou
mais servidores RADIUS, que informa ao NPS para onde enviar as solicitações de
conexão que corresponderem à política de solicitação de conexão.
７ Observação
Você também pode configurar um novo grupo de servidores RADIUS remoto

durante o processo de criação de uma nova política de solicitação de conexão.

Para adicionar um grupo de servidores RADIUS remoto

1. No Gerenciador do Servidor, clique em Ferramentas e, em seguida, clique em
Servidor de Política de Rede para abrir o console nps.
2. Na árvore de console, clique duas vezes em Clientes e Servidores RADIUS, clique
com o botão direito do mouse em Grupos de Servidores RADIUS Remotos e
clique em Novo.
3. A caixa de diálogo Novo Grupo de Servidores RADIUS Remoto é aberta. Em
Nome do grupo, digite um nome para o grupo de servidores RADIUS remoto.
4. Em Servidores RADIUS, clique em Adicionar. A caixa de diálogo Adicionar
Servidores RADIUS é aberta. Digite o endereço IP do servidor RADIUS que você
deseja adicionar ao grupo ou digite o FQDN (Nome de Domínio Totalmente
Qualificado) do servidor RADIUS e clique em Verificar.
5. Em Adicionar Servidores RADIUS, clique na guia Autenticação/Contabilidade .
Em Segredo compartilhado eConfirmar segredo compartilhado, digite o segredo
compartilhado. Você deve usar o mesmo segredo compartilhado ao configurar o
computador local como um cliente RADIUS no servidor RADIUS remoto.
6. Se você não estiver usando o Protocolo de Autenticação Extensível (EAP) para
autenticação, clique em Solicitação deve conter o atributo de autenticador de
mensagem. O EAP usa o Message-Authenticator por padrão.
7. Verifique se os números de porta de autenticação e contabilidade estão corretos
para sua implantação.
8. Se você usar um segredo compartilhado diferente para contabilidade, em
Contabilidade, des marque a caixa de seleção Usar o mesmo segredo
compartilhado para autenticação e contabilidade e digite o segredo compartilhado
de contabilidade em Segredo compartilhado e Confirmar segredo compartilhado.
9. Se você não quiser encaminhar mensagens de início e parada do servidor de
acesso à rede para o servidor RADIUS remoto, des marque a caixa de seleção
Encaminhar notificações de início e parada do servidor de acesso à rede para esse
servidor.
Gerenciar certificados usados com NPS
Se você implantar um método de autenticação baseado em certificado Protocol-

Transport, como EAP-TLS (Segurança de Camada extensível de autenticação extensível),
PEAP-TL Protocol-Transport S (Segurança de Camada extensível de autenticação
extensível protegida) e protocolo de autenticação de handshake de desafio do PEAP-
Microsoft versão 2 (MS-CHAP v2), você deverá registrar um certificado do servidor em
todos os NPSs. O certificado do servidor deve:
Atender aos requisitos mínimos de certificado do servidor, conforme descrito em

Configurar modelos de certificado para requisitos de PEAP e EAP
Ser emitido por uma AC (autoridade de certificação) confiável para computadores

cliente. Uma AC é confiável quando seu certificado existe no armazenamento de
certificados de Autoridades de Certificação Confiáveis para o usuário atual e o
computador local.
As instruções a seguir auxiliam no gerenciamento de certificados NPS em implantações

em que a AC raiz confiável é uma AC de terceiros, como a Verisign, ou é uma AC que
você implantou para sua PKI (infraestrutura de chave pública) usando Serviços de
Certificados do Active Directory (AD CS).
Alterar a expiração do handle TLS armazenado

em cache
Durante os processos de autenticação iniciais para EAP-TLS, PEAP-TLS e PEAP-MS-CHAP
v2, o NPS armazena em cache uma parte das propriedades de conexão TLS do cliente
de conexão. O cliente também armazena em cache uma parte das propriedades de
conexão TLS do NPS.
Cada coleção individual dessas propriedades de conexão TLS é chamada de um handle

TLS.
Os computadores cliente podem armazenar em cache os alças TLS para vários

autenticadores, enquanto os NPSs podem armazenar em cache os alças TLS de muitos
computadores cliente.
Os tratamentos TLS armazenados em cache no cliente e no servidor permitem que o
processo de reauttenticação ocorra mais rapidamente. Por exemplo, quando um
computador sem fio é autenticado novamente com um NPS, o NPS pode examinar o
manipular TLS para o cliente sem fio e pode determinar rapidamente que a conexão do
cliente é uma reconexão. O NPS autoriza a conexão sem executar a autenticação
completa.
Correspondentemente, o cliente examina o handle TLS para o NPS, determina que ele é
uma reconexão e não precisa executar a autenticação do servidor.
Em computadores que executam Windows 10 e Windows Server 2016, a expiração do

handle TLS padrão é de 10 horas.
Em algumas circunstâncias, talvez você queira aumentar ou diminuir o tempo de

expiração do lidar com TLS.
Por exemplo, talvez você queira diminuir o tempo de expiração do handle TLS em
circunstâncias em que o certificado de um usuário é revogado por um administrador e o
certificado expirou. Nesse cenário, o usuário ainda poderá se conectar à rede se um NPS
tiver um alça TLS armazenado em cache que não expirou. Reduzir a expiração do lidar
com TLS pode ajudar a impedir que esses usuários com certificados revogados se
reconectem.
７ Observação
A melhor solução para esse cenário é desabilitar a conta de usuário no Active

Directory ou remover a conta de usuário do grupo do Active Directory que tem
permissão para se conectar à rede na política de rede. A propagação dessas
alterações em todos os controladores de domínio também pode ser atrasada, no
entanto, devido à latência de replicação.
Configurar o tempo de expiração do handle

TLS em computadores cliente
Você pode usar esse procedimento para alterar a quantidade de tempo que os
computadores cliente armazenam em cache o alça TLS de um NPS. Depois de autenticar
com êxito um NPS, os computadores cliente armazenam em cache as propriedades de
conexão TLS do NPS como um handle TLS. O handle TLS tem uma duração padrão de
10 horas (36.000.000 milissegundos). Você pode aumentar ou diminuir o tempo de
expiração do handle TLS usando o procedimento a seguir.
este procedimento.
） Importante
Esse procedimento deve ser executado em um NPS, não em um computador

cliente.
Para configurar o tempo de expiração do handle TLS em

computadores cliente
1. Em um NPS, abra o Editor do Registro.
2. Navegue até a chave do

RegistroHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityPro
viders\SCHANNEL
3. No menu Editar , clique em Novo e, em seguida, clique em Chave.
4. Digite ClientCacheTime e pressione ENTER.
5. Clique com o botão direito do mouse em ClientCacheTime, clique em Novoe em

Valor DWORD (32 bits).
6. Digite a quantidade de tempo, em milissegundos, que você deseja que os

computadores cliente armazenam em cache o identificador TLS de um NPS após a
primeira tentativa de autenticação bem-sucedida pelo NPS.
Configurar o tempo de expiração do handle

TLS no NPSs
Use este procedimento para alterar a quantidade de tempo que o NPSs armazena em
cache o handle TLS dos computadores cliente. Depois de autenticar com êxito um
cliente de acesso, o NPSs armazena em cache as propriedades de conexão TLS do
computador cliente como um manipular TLS. O handle TLS tem uma duração padrão de
10 horas (36.000.000 milissegundos). Você pode aumentar ou diminuir o tempo de
expiração do handle TLS usando o procedimento a seguir.

este procedimento.
） Importante
Esse procedimento deve ser executado em um NPS, não em um computador

cliente.
Para configurar o tempo de expiração do handle TLS no

NPSs
1. Em um NPS, abra o Editor do Registro.
2. Navegue até a chave do

RegistroHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityPro
viders\SCHANNEL
3. No menu Editar , clique em Novo e, em seguida, clique em Chave.
4. Digite ServerCacheTime e pressione ENTER.
5. Clique com o botão direito do mouse em ServerCacheTime, clique em Novoe em

Valor DWORD (32 bits).
6. Digite a quantidade de tempo, em milissegundos, que você deseja que o NPSs

armazena em cache o identificador TLS de um computador cliente após a primeira
tentativa de autenticação bem-sucedida pelo cliente.
Obter o hash SHA-1 de um certificado de AC

raiz confiável
Use este procedimento para obter o hash SHA-1 (Secure Hash Algorithm) de uma AC
(autoridade de certificação) raiz confiável de um certificado instalado no computador
local. Em algumas circunstâncias, como ao implantar Política de Grupo, é necessário
designar um certificado usando o hash SHA-1 do certificado.
Ao usar Política de Grupo, você pode designar um ou mais certificados de AC raiz

confiáveis que os clientes devem usar para autenticar o NPS durante o processo de
autenticação mútua com EAP ou PEAP. Para designar um certificado de AC raiz confiável
que os clientes devem usar para validar o certificado do servidor, você pode inserir o
hash SHA-1 do certificado.
Este procedimento demonstra como obter o hash SHA-1 de um certificado de AC raiz

confiável usando o snap-in certificados Console de Gerenciamento Microsoft (MMC).
Para concluir este procedimento, você deve ser um membro do grupo Usuários no
computador local.
Para obter o hash SHA-1 de um certificado de AC raiz

confiável
1. Na caixa de diálogo Executar ou Windows PowerShell, digite mmc e pressione
ENTER. O Console de Gerenciamento Microsoft (MMC) é aberto. No MMC, clique
em Arquivo e, em seguida , clique em Adicionar/Remover Snap\in. A caixa de

em Certificados. O assistente de snap-in Certificados é aberto. Clique em Conta de
computador e em Avançar.
3. Em Selecionar Computador, verifique se Computador local ( o computador em

que este console está sendo executado) está selecionado, clique em Concluir e
clique emOK.
4. No painel esquerdo, clique duas vezes em Certificados (Computador Local) e

clique duas vezes na pasta Autoridades de Certificação Confiáveis .
5. A pasta Certificados é uma subpasta da pasta Autoridades de Certificação

Confiáveis . Clique na pasta Certificados.
6. No painel de detalhes, navegue até o certificado para sua AC raiz confiável. Clique
duas vezes no certificado. A caixa de diálogo Certificado é aberta.
7. Na caixa de diálogo Certificado, clique na guia Detalhes.
8. Na lista de campos, role até e selecione Impressão Digital.
9. No painel inferior, a cadeia de caracteres hexadecimal que é o hash SHA-1 do seu

certificado é exibida. Selecione o hash SHA-1 e pressione o atalho de teclado
Windows para o comando Copy (CTRL+C) para copiar o hash para a área de
transferência Windows dados.
10. Abra o local no qual você deseja colar o hash SHA-1, localize corretamente o
cursor e pressione o atalho de teclado Windows para o comando Colar (CTRL+V).
Para obter mais informações sobre certificados e NPS, consulte Configurar modelos de
certificado para requisitos de PEAP e EAP.
Configurar modelos de certificado para
requisitos de PEAP e EAP
Todos os certificados usados para autenticação de acesso à rede com o EAP-TLS

(Protocolo de Autenticação Extensível Protocol-Transport de Autenticação Extensível
Protocol-Transport Layer Security) e o Protocolo de Autenticação de Handshake de
Desafio do PEAP-Microsoft versão 2 (MS-CHAP v2) devem atender aos requisitos de
certificados X.509 e trabalhar para conexões que usam o protocolo SSL/TLS. Os
certificados de cliente e servidor têm requisitos adicionais.
） Importante
Este tópico fornece instruções para configurar modelos de certificado. Para usar
essas instruções, é necessário que você tenha implantado sua própria PKI
(Infraestrutura de Chave Pública) com Serviços de Certificados do Active Directory
(AD CS).
Requisitos mínimos de certificado do servidor

Com PEAP-MS-CHAP v2, PEAP-TLS ou EAP-TLS como o método de autenticação, o NPS
deve usar um certificado do servidor que atenda aos requisitos mínimos de certificado
do servidor.
Os computadores cliente podem ser configurados para validar certificados do servidor

usando a opção Validar certificado do servidor no computador cliente ou Política de
Grupo.
O computador cliente aceita a tentativa de autenticação do servidor quando o

certificado do servidor atende aos seguintes requisitos:
O Nome da assunto contém um valor . Se você emitir um certificado para o

servidor que executa o NPS (Servidor de Políticas de Rede) que tenha um Nome de
assunto em branco, o certificado não estará disponível para autenticar o NPS. Para
configurar o modelo de certificado com um Nome de assunto:
1. Abra os Modelos de Certificado.

2. No painel de detalhes, clique com o botão direito do mouse no modelo de
certificado que você deseja alterar e clique em Propriedades .
3. Clique na guia Nome da Assunto e clique em Criar com base nas
informações do Active Directory.
4. Em Formato de nome da assunto, selecione um valor diferente de Nenhum.
O certificado do computador nas cadeias de servidores a uma AC (autoridade de

certificação) raiz confiável e não falha em nenhuma das verificações executadas
pelo CryptoAPI e especificadas na política de acesso remoto ou na política de rede.
O certificado do computador para o servidor NPS ou VPN é configurado com a

finalidade de Autenticação de Servidor em extensões de EKU (Uso Estendido de
Chave). (O identificador de objeto para Autenticação de Servidor é 1.3.6.1.5.5.7.3.1.)
Configure o certificado do servidor com a configuração de criptografia necessária:

certificado que você deseja alterar e clique em Propriedades.
3. Clique na guia Criptografia e configure o seguinte:
Categoria do provedor: Provedor de Armazenamento chave
Nome do algoritmo: RSA
Provedores: Provedor de Criptografia da Plataforma Microsoft
Tamanho mínimo da chave: 2048
Algoritmo de hash: SHA2
A extensão Nome Alternativo da Assunto (SubjectAltName), se usada, deve conter

o nome DNS do servidor. Para configurar o modelo de certificado com o nome
DNS (Sistema de Nomes de Domínio) do servidor de registro:

certificado que você deseja alterar e clique em Propriedades .
4. Em Incluir essas informações no nome alternativo da assunto, selecione
Nome DNS.
Ao usar PEAP e EAP-TLS, o NPSs exibe uma lista de todos os certificados instalados no
armazenamento de certificados do computador, com as seguintes exceções:
Certificados que não contêm a finalidade de Autenticação de Servidor em
extensões de EKU não são exibidos.
Certificados que não contêm um Nome da assunto não são exibidos.
Os certificados de logon baseados em Registro e cartão inteligente não são

exibidos.
Para obter mais informações, consulte Implantar certificados de servidor para

implantações com fio e sem fio 802.1X.
Requisitos mínimos de certificado do cliente

Com EAP-TLS ou PEAP-TLS, o servidor aceita a tentativa de autenticação do cliente
quando o certificado atende aos seguintes requisitos:
O certificado do cliente é emitido por uma AC corporativa ou mapeado para uma

conta de usuário ou computador no Active Directory Domain Services (AD DS).
O certificado do usuário ou do computador nas cadeias de cliente para uma AC

raiz confiável, inclui a finalidade da Autenticação do Cliente em extensões de EKU
(o identificador de objeto para Autenticação de Cliente é 1.3.6.1.5.5.7.3.2) e não
falha nas verificações executadas pelo CryptoAPI e que são especificadas na
política de rede ou política de acesso remoto nem nas verificações de identificador
de objeto de certificado especificadas na política de rede NPS.
O cliente 802.1X não usa certificados baseados no Registro que são certificados
protegidos por senha ou logon de cartão inteligente.
Para certificados de usuário, a extensão Nome Alternativo da Entidade

(SubjectAltName) no certificado contém o NOME UPN. Para configurar o UPN em
um modelo de certificado:

4. Em Incluir essas informações no nome alternativo da entidade, selecione
NOME UPN.
Para certificados de computador, a extensão Nome Alternativo da Assunto

(SubjectAltName) no certificado deve conter o FQDN (nome de domínio
totalmente qualificado) do cliente, que também é chamado de nome DNS. Para
configurar esse nome no modelo de certificado:

4. Em Incluir essas informações no nome alternativo da assunto, selecione
Nome DNS.
Com PEAP-TLS e EAP-TLS, os clientes exibem uma lista de todos os certificados

instalados no snap-in Certificados, com as seguintes exceções:
Os clientes sem fio não exibem certificados de logon baseados em registro e

cartão inteligente.
Clientes sem fio e clientes VPN não exibem certificados protegidos por senha.
Certificados que não contêm a finalidade de Autenticação de Cliente em extensões

de EKU não são exibidos.
Gerenciar NPSs
Você pode usar os tópicos nesta seção para gerenciar NPSs.
７ Observação
Para obter documentação adicional do Servidor de Políticas de Rede, você pode


Configurar o NPS em um computador multihomed

Configurar informações de porta UDP do NPS
Desabilitar o encaminhamento de notificação do NAS
Exportar uma configuração do NPS para importação em outro servidor
Aumentar autenticações simultâneas processadas pelo NPS
Balanceamento de carga do servidor proxy NPS
Registrar um NPS em um domínio do Active Directory
Cancelar o registro de um NPS de um domínio do Active Directory
Usar expressões regulares no NPS
Verificar a configuração após alterações do NPS
Configurar o NPS em um computador
multihomed
Você pode usar este tópico para configurar um NPS com vários adaptadores de rede.
Ao usar vários adaptadores de rede em um servidor que executa o NPS (Servidor de

Políticas de Rede), você pode configurar o seguinte:
Os adaptadores de rede que fazem e não enviam e recebem tráfego Remote

Authentication Dial-In User Service (RADIUS).
Em uma base de adaptador por rede, se o NPS monitora o tráfego RADIUS em
protocolo IP versão 4 (IPv4), IPv6 ou IPv4 e IPv6.
Os números de porta UDP pelos quais o tráfego RADIUS é enviado e recebido por
protocolo (IPv4 ou IPv6), por adaptador de rede.
Por padrão, o NPS escuta o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 para
IPv6 e IPv4 para todos os adaptadores de rede instalados. Como o NPS usa
automaticamente todos os adaptadores de rede para tráfego RADIUS, você só precisa
especificar os adaptadores de rede que deseja que o NPS use para o tráfego RADIUS
quando quiser impedir que o NPS use um adaptador de rede específico.
７ Observação
Se você desinstalar IPv4 ou IPv6 em um adaptador de rede, o NPS não monitorará

o tráfego RADIUS para o protocolo desinstalado.
Em um NPS que tenha vários adaptadores de rede instalados, talvez você queira
configurar o NPS para enviar e receber o tráfego RADIUS somente nos adaptadores
especificados.
Por exemplo, um adaptador de rede instalado no NPS pode levar a um segmento de

rede que não contém clientes RADIUS, enquanto um segundo adaptador de rede
fornece NPS com um caminho de rede para seus clientes RADIUS configurados. Nesse
cenário, é importante direcionar o NPS para usar o segundo adaptador de rede para
todo o tráfego RADIUS.
Em outro exemplo, se o NPS tiver três adaptadores de rede instalados, mas você quiser
que o NPS use apenas dois dos adaptadores para tráfego RADIUS, você poderá
configurar informações de porta somente para os dois adaptadores. Excluindo a
configuração de porta para o terceiro adaptador, você impede que o NPS use o
adaptador para tráfego RADIUS.
Usando um adaptador de rede

Para configurar o NPS para escutar e enviar o tráfego RADIUS em um adaptador de
rede, use a seguinte sintaxe na caixa de diálogo Propriedades do Servidor de Política de
Rede no console do NPS:
Sintaxe de tráfego IPv4: IPAddress:UDPport, em que IPAddress é o endereço IPv4

configurado no adaptador de rede pelo qual você deseja enviar o tráfego RADIUS
e UDPport é o número da porta RADIUS que você deseja usar para autenticação
RADIUS ou tráfego de contabilidade.
Sintaxe de tráfego IPv6: [IPv6Address] : UDPport , em que os colchetes em torno
de IPv6Address são necessários, IPv6Address é o endereço IPv6 configurado no
adaptador de rede pelo qual você deseja enviar o tráfego RADIUS e UDPport é o
número da porta RADIUS que você deseja usar para autenticação RADIUS ou
tráfego de contabilidade.
Os seguintes caracteres podem ser usados como delimitadores para configurar o

endereço IP e as informações de porta UDP:
Delimidor de endereço/porta: dois-pontos (:)

Delimiter de porta: vírgula (,)
Delimiter de interface: ponto e vírgula (;)
Configurando servidores de acesso à rede

Certifique-se de que os servidores de acesso à rede estão configurados com os mesmos
números de porta UDP RADIUS configurados em seus NPSs. As portas UDP padrão
RADIUS definidas nas RFCs 2865 e 2866 são 1812 para autenticação e 1813 para
contabilidade; No entanto, alguns servidores de acesso são configurados por padrão
para usar a porta UDP 1645 para solicitações de autenticação e a porta UDP 1646 para
solicitações de contabilidade.
） Importante
Se você não usar os números de porta padrão RADIUS, deverá configurar exceções
no firewall do computador local para permitir o tráfego RADIUS nas novas portas.
Para obter mais informações, consulte Configurar firewalls para tráfego RADIUS.
Configurar o NPS multihomed

Você pode usar o procedimento a seguir para configurar o NPS multihomed.

Para especificar o adaptador de rede e as portas UDP que

o NPS usa para o tráfego RADIUS
1. No Gerenciador do servidor, clique em Ferramentase clique em Servidor de
Políticas de Rede para abrir o console do NPS.
2. Clique com o botão direito do mouse em Servidor de Política de Redee clique em

Propriedades.
3. Clique na guia Portas e prentente o endereço IP do adaptador de rede que você

deseja usar para o tráfego RADIUS para os números de porta existentes. Por
exemplo, se você quiser usar o endereço IP 192.168.1.2 e as portas RADIUS 1812 e
1645 para solicitações de autenticação, altere a configuração da porta de
1812.1645 para 192.168.1.2:1812.1645. Se as portas UDP de contabilidade RADIUS e
radius são diferentes dos valores padrão, altere as configurações de porta de
acordo.
4. Para usar várias configurações de porta para solicitações de autenticação ou

contabilidade, separe os números de porta com vírgulas.
Para obter mais informações sobre portas UDP do NPS, consulte Configurar informações
de porta UDP do NPS
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede
Configurar informações da porta UDP
do NPS
Você pode usar o procedimento a seguir para configurar as portas que o servidor de
diretivas de rede (NPS) usa para autenticação de serviço RADIUS (RADIUS) e o tráfego
de contabilização.
Por padrão, o NPS escuta o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 para o
protocolo IP versão 6 (IPv6) e IPv4 para todos os adaptadores de rede instalados.
７ Observação
Se você desinstalar o IPv4 ou IPv6 em um adaptador de rede, o NPS não

monitorará o tráfego RADIUS para o protocolo desinstalado.
Os valores de porta de 1812 para autenticação e 1813 para contabilidade são portas
RADIUS padrão definidas pela IETF (Internet Engineering Task Force) nas RFCs 2865 e
2866. No entanto, por padrão, muitos servidores de acesso usam as portas 1645 para
solicitações de autenticação e 1646 para solicitações de contabilização. Não importa
quais números de porta você decidir usar, verifique se o NPS e o servidor de acesso
estão configurados para usar os mesmos.
FUNDAMENTAL Se você não usar os números de porta RADIUS padrão, deverá

configurar exceções no firewall para o computador local para permitir o tráfego
RADIUS nas novas portas. Para obter mais informações, consulte Configurar firewalls
para tráfego RADIUS.

Para configurar as informações de porta UDP

do NPS
1. Abra o console do NPS.
2. Clique com o botão direito do mouse em servidor de políticas de redee clique em
Propriedades.
3. Clique na guia portas e examine as configurações de portas. Se as portas UDP de
autenticação RADIUS e contabilização RADIUS variarem dos valores padrão
fornecidos (1812 e 1645 para autenticação e 1813 e 1646 para contabilização),
digite as configurações de porta em autenticação e contabilidade.
4. Para usar várias configurações de porta para solicitações de autenticação ou de
estatísticas, separe os números de porta com vírgulas.
Para obter mais informações sobre como gerenciar o NPS, consulte gerenciar o servidor
Desabilitar o encaminhamento de
notificação do NAS no NPS
Você pode usar esse procedimento para desabilitar o encaminhamento de mensagens

de início e parada de NASs (servidores de acesso à rede) para membros de um grupo de
servidores RADIUS remoto configurado no NPS.
Quando você tiver grupos de servidores RADIUS remotos configurados e, em Políticas

de Solicitação de Conexão NPS, desempurar a caixa de seleção Encaminhar solicitações
de contabilidade para esse grupo de servidores RADIUS remoto, esses grupos ainda
receberão mensagens de notificação de início e parada do NAS.
Isso cria tráfego de rede desnecessário. Para eliminar esse tráfego, desabilite o
encaminhamento de notificação nas para servidores individuais em cada grupo de
servidores RADIUS remoto.
Para desabilitar o encaminhamento de notificação nas

Servidor de Políticas de Rede. O console NPS é aberto.
2. No console do NPS, clique duas vezes em Clientes e Servidores RADIUS, clique em

Grupos de Servidores RADIUS Remotos e clique duas vezes no grupo de
servidores RADIUS remoto que você deseja configurar. A caixa de diálogo
Propriedades do grupo de servidores RADIUS remoto é aberta.
3. Clique duas vezes no membro do grupo que você deseja configurar e clique na
guia Autenticação/Contabilidade .
4. Em Contabilidade, des marque a caixa de seleção Encaminhar notificações de

início e parada do servidor de acesso à rede para esse servidor e clique em OK.
5. Repita as etapas 3 e 4 para todos os membros do grupo que você deseja

configurar.
Exportar uma configuração do NPS para
importação em outro servidor
Você pode exportar toda a configuração do NPS – incluindo clientes e servidores

RADIUS, política de rede, política de solicitação de conexão, registro e configuração de
log – de um NPS para importação em outro NPS.
Use uma das seguintes ferramentas para exportar a configuração do NPS:
No Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012, você
pode usar o Netsh ou pode usar Windows PowerShell.
No Windows Server 2008 R2 e Windows Server 2008, use Netsh.
） Importante
Não use esse procedimento se o banco de dados NPS de origem tiver um número
de versão maior do que o número de versão do banco de dados NPS de destino.
Você pode exibir o número de versão do banco de dados NPS na exibição do
comando netsh nps show config .
Como as configurações do NPS não são criptografadas no arquivo XML exportado,

enviá-lo por uma rede pode representar um risco de segurança, portanto, tome
precauções ao mover o arquivo XML do servidor de origem para os servidores de
destino. Por exemplo, adicione o arquivo a um arquivo morto criptografado protegido
por senha antes de mover o arquivo. Além disso, armazene o arquivo em um local
seguro para impedir que usuários mal-intencionados o acessem.
７ Observação
Se SQL Server log estiver configurado no NPS de origem, SQL Server configurações
de log não serão exportadas para o arquivo XML. Depois de importar o arquivo em
outro NPS, você deve configurar manualmente SQL Server log.
Exportar e importar a configuração do NPS
usando Windows PowerShell
Para Windows Server 2012 e versões posteriores do sistema operacional, você pode
exportar a configuração do NPS usando Windows PowerShell.
A sintaxe de comando para exportar a configuração do NPS é a seguinte.
PowerShell
Export-NpsConfiguration -Path <filename>
A tabela a seguir lista parâmetros para o cmdlet Export-NpsConfiguration Windows

PowerShell. Parâmetros em negrito são necessários.
Parâmetro Descrição
Caminho Especifica o nome e o local do arquivo XML para o qual você deseja exportar a
configuração do NPS.
Exemplo de exportação
No exemplo a seguir, a configuração do NPS é exportada para um arquivo XML
localizado na unidade local. Para executar esse comando, execute Windows PowerShell
como Administrador no NPS de origem, digite o comando a seguir e pressione Enter.
PowerShell
Export-NpsConfiguration –Path c:\config.xml
Para obter mais informações, consulte Export-NpsConfiguration.
Depois de exportar a configuração do NPS, copie o arquivo XML para o servidor de

destino.
A sintaxe de comando para importar a configuração do NPS no servidor de destino é a

seguinte.
PowerShell
Import-NpsConfiguration [-Path] <String> [ <CommonParameters>]
Exemplo de importação
O comando a seguir importa configurações do arquivo chamado C:\Npsconfig.xml para
NPS. Para executar esse comando, execute Windows PowerShell como Administrador no
NPS de destino, digite o comando a seguir e pressione Enter.
PowerShell
Import-NpsConfiguration -Path "C:\Npsconfig.xml"
Para obter mais informações, consulte Import-NpsConfiguration.
Exportar e importar a configuração do NPS

usando o Netsh
Você pode usar o Netsh (Shell de Rede) para exportar a configuração do NPS usando o
comando netsh nps export .
Quando o comando netsh nps import é executado, o NPS é atualizado

automaticamente com as definições de configuração atualizadas. Você não precisa
interromper o NPS no computador de destino para executar o comando netsh nps
import , no entanto, se o console NPS ou o snap-in do NPS MMC estiver aberto durante
a importação da configuração, as alterações na configuração do servidor não serão
visíveis até que você atualize a exibição.
７ Observação
Ao usar o comando netsh nps export , você precisa fornecer o parâmetro de

comando exportPSK com o valor YES. Esse parâmetro e valor explicitamente
afirmam que você entende que está exportando a configuração do NPS e que o
arquivo XML exportado contém segredos compartilhados não criptografados para
clientes RADIUS e membros de grupos de servidores RADIUS remotos.

Para copiar uma configuração do NPS para outro NPS
usando comandos Netsh
1. No NPS de origem, abra o Prompt de Comando, digite netsh e pressione Enter.
2. No prompt netsh , digite nps e pressione Enter.
3. No prompt netsh nps, digite export filename="path\file.xml" exportPSK=YES, em

que path é o local da pasta em que você deseja salvar o arquivo de configuração
do NPS e o arquivo é o nome do arquivo XML que você deseja salvar. Pressione
Enter.
Isso armazena as definições de configuração (incluindo as configurações do

Registro) em um arquivo XML. O caminho pode ser relativo ou absoluto ou pode
ser um caminho UNC (Convenção universal de nomenização). Depois de
pressionar Enter, uma mensagem será exibida indicando se a exportação para o
arquivo foi bem-sucedida.
4. Copie o arquivo que você criou para o NPS de destino.
5. Em um prompt de comando no NPS de destino, digite netsh nps import

filename="path\file.xml"e pressione Enter. Uma mensagem é exibida indicando se
a importação do arquivo XML foi bem-sucedida.
Aumentar autenticações simultâneas
processadas pelo NPS
Você pode usar este tópico para obter instruções sobre como configurar autenticações
simultâneas do Servidor de Políticas de Rede.
Se você instalou o NPS (Servidor de Política de Rede) em um computador diferente de

um controlador de domínio e o NPS está recebendo um grande número de solicitações
de autenticação por segundo, você pode melhorar o desempenho do NPS aumentando
o número de autenticações simultâneas permitidas entre o NPS e o controlador de
domínio.
Para fazer isso, você deve editar a seguinte chave do Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Adicione um novo valor DWORD chamado MaxConcurrentApi e atribua a ele um valor

de 150.
Ｕ Cuidado
Se você atribuir um valor a MaxConcurrentApi muito alto, o NPS poderá colocar

uma carga excessiva no controlador de domínio.
Para obter mais informações sobre MaxConcurrentApi, consulte Como fazer o ajuste de
desempenho para autenticação NTLM usando a configuração MaxConcurrentApi
Para obter mais informações sobre como gerenciar o NPS, consulte Gerenciar Servidor
de Política de Rede.
Para obter mais informações sobre o NPS, consulte NPS (Servidor de Política de Rede).
Instalar o NPS (Servidor de Políticas de
Rede)
Você pode usar este tópico para instalar o NPS (Servidor de Políticas de Rede) usando o
Windows PowerShell ou o Assistente para Adicionar Funções e Recursos. O NPS é um
serviço de função da função de servidor Serviços de Acesso e Política de Rede.
７ Observação
Por padrão, o NPS ouve o tráfego RADIUS nas portas 1812, 1813, 1645 e 1646 em
todos os adaptadores de rede instalados. Se Windows Firewall com Segurança
Avançada estiver habilitado quando você instalar o NPS, as exceções de firewall
para essas portas serão criadas automaticamente durante o processo de instalação
para o tráfego IPv6 (protocolo IPv6) e IPv4. Se os servidores de acesso à rede estão
configurados para enviar tráfego RADIUS por portas diferentes desses padrões,
remova as exceções criadas no Firewall do Windows com Segurança Avançada
durante a instalação do NPS e crie exceções para as portas que você usa para o
tráfego RADIUS.
de Domínio.
Para instalar o NPS usando Windows

PowerShell
PowerShell administrador, digite o comando a seguir e pressione ENTER.
Para instalar o NPS usando o Gerenciador do

Servidor
1. No NPS1, no Gerenciador do Servidor, clique em Gerenciar e em Adicionar
７ Observação



5. Em Selecionar Funções de Servidor, em Funções, selecione Política de Rede e

Serviços do Access. Uma caixa de diálogo é aberta perguntando se ela deve
adicionar recursos necessários para a Política de Rede e Serviços do Access. Clique
em Adicionar Recursose clique em Próximo
6. Em Selecionar recursos, clique em Avançar e, em Serviços de Acesso e Política de

Rede, analise as informações fornecidas e clique em Avançar.
7. Em Selecionar serviços de função, clique em Servidor de Políticas de Rede. Em

Adicionar recursos que são necessários para Servidor de Políticas de Rede, clique
em Adicionar Recursos. Clique em Próximo.

status durante o processo de instalação. Quando o processo for concluído, a
mensagem "Instalação bem-sucedida no ComputerName" será exibida, em que
ComputerName é o nome do computador no qual você instalou o Servidor de
Política de Rede. Clique em fechar
Para obter mais informações, consulte Gerenciar NPSs.

Balanceamento de carga do servidor
proxy NPS
Clientes do serviço RADIUS (RADIUS), que são servidores de acesso à rede, como
servidores de rede virtual privada (VPN) e pontos de acesso sem fio, criam solicitações
de conexão e as enviam para servidores RADIUS, como o NPS. Em alguns casos, um NPS
pode receber muitas solicitações de conexão ao mesmo tempo, resultando em um
desempenho degradado ou em uma sobrecarga. Quando um NPS está sobrecarregado,
é uma boa ideia adicionar mais NPSs à sua rede e configurar o balanceamento de carga.
Quando você distribui uniformemente as solicitações de conexão de entrada entre
vários NPSs para evitar o sobrecarregamento de um ou mais NPSs, ele é chamado de
balanceamento de carga.
O balanceamento de carga é particularmente útil para:
Organizações que usam EAP-TLS (autenticação extensível Protocol-Transport

segurança de camada) ou PEAP (protocolo de autenticação extensível protegida)
TLS para autenticação. Como esses métodos de autenticação usam certificados
para autenticação de servidor e para autenticação de computador cliente ou de
usuário, a carga em proxies e servidores RADIUS é mais pesada do que quando
métodos de autenticação baseados em senha são usados.
Organizações que precisam manter a disponibilidade contínua do serviço.
Provedores de serviços de Internet (ISPs) que terceirizam o acesso VPN para outras
organizações. Os serviços de VPN terceirizados podem gerar um grande volume
de tráfego de autenticação.
Há dois métodos que você pode usar para balancear a carga de solicitações de conexão
enviadas para seu NPSs:
Configure seus servidores de acesso à rede para enviar solicitações de conexão

para vários servidores RADIUS. Por exemplo, se você tiver 20 pontos de acesso
sem fio e dois servidores RADIUS, configure cada ponto de acesso para enviar
solicitações de conexão para ambos os servidores RADIUS. Você pode balancear a
carga e fornecer failover em cada servidor de acesso à rede configurando o
servidor de acesso para enviar solicitações de conexão a vários servidores RADIUS
em uma ordem de prioridade especificada. Esse método de balanceamento de
carga geralmente é melhor para pequenas organizações que não implantam um
grande número de clientes RADIUS.
Use o NPS configurado como um proxy RADIUS para balancear a carga de
solicitações de conexão entre vários NPSs ou outros servidores RADIUS. Por
exemplo, se você tiver 100 pontos de acesso sem fio, um proxy NPS e três
servidores RADIUS, você poderá configurar os pontos de acesso para enviar todo o
tráfego para o proxy NPS. No proxy NPS, configure o balanceamento de carga
para que o proxy distribua uniformemente as solicitações de conexão entre os três
servidores RADIUS. Esse método de balanceamento de carga é melhor para
organizações de médio e grande porte que têm muitos clientes e servidores
RADIUS.
Em muitos casos, a melhor abordagem para o balanceamento de carga é configurar

clientes RADIUS para enviar solicitações de conexão para dois servidores proxy NPS e,
em seguida, configurar os proxies NPS para balancear a carga entre os servidores
RADIUS. Essa abordagem fornece failover e balanceamento de carga para proxies NPS e
servidores RADIUS.
Prioridade e peso do servidor RADIUS

Durante o processo de configuração do proxy NPS, você pode criar grupos de
servidores RADIUS remotos e, em seguida, adicionar servidores RADIUS a cada grupo.
Para configurar o balanceamento de carga, você deve ter mais de um servidor RADIUS
por grupo de servidores RADIUS remotos. Ao adicionar membros do grupo ou depois
de criar um servidor RADIUS como um membro do grupo, você pode acessar a caixa de
diálogo Adicionar servidor RADIUS para configurar os seguintes itens na guia
balanceamento de carga:
Prioridade. Prioridade especifica a ordem de importância do servidor RADIUS para

o servidor proxy NPS. O nível de prioridade deve ser atribuído um valor que seja
um inteiro, como 1, 2 ou 3. Quanto menor o número, maior a prioridade que o
proxy NPS fornece ao servidor RADIUS. Por exemplo, se o servidor RADIUS receber
a prioridade mais alta de 1, o proxy NPS enviará solicitações de conexão para o
servidor RADIUS primeiro; Se os servidores com prioridade 1 não estiverem
disponíveis, o NPS enviará solicitações de conexão para servidores RADIUS com
prioridade 2 e assim por diante. Você pode atribuir a mesma prioridade a vários
servidores RADIUS e, em seguida, usar a configuração de peso para balancear a
carga entre eles.
Peso. O NPS usa essa configuração de peso para determinar quantas solicitações
de conexão devem ser enviadas a cada membro do grupo quando os membros do
grupo têm o mesmo nível de prioridade. A configuração de peso deve ser
atribuída a um valor entre 1 e 100, e o valor representa um percentual de 100%.
Por exemplo, se o grupo de servidores remotos RADIUS contiver dois membros
que tenham um nível de prioridade 1 e uma classificação de peso de 50, o proxy
NPS encaminhará 50% das solicitações de conexão para cada servidor RADIUS.
Configurações avançadas. Essas configurações de failover fornecem uma maneira

para o NPS determinar se o servidor RADIUS remoto está indisponível. Se o NPS
determinar que um servidor RADIUS está indisponível, ele poderá começar a enviar
solicitações de conexão para outros membros do grupo. Com essas configurações,
você pode configurar o número de segundos que o proxy NPS espera por uma
resposta do servidor RADIUS antes de considerar a solicitação descartada; o
número máximo de solicitações removidas antes que o proxy NPS identifique o
servidor RADIUS como indisponível; e o número de segundos que podem decorrer
entre solicitações antes que o proxy NPS identifique o servidor RADIUS como
indisponível.
Configurar balanceamento de carga de proxy

do NPS
Antes de configurar o balanceamento de carga, crie um plano de implantação que
inclua quantos grupos de servidores RADIUS remotos você precisa, quais servidores são
membros de cada grupo específico e a configuração de prioridade e peso de cada
servidor.
７ Observação
As etapas a seguir pressupõem que você já implantou e configurou servidores

RADIUS.
Para configurar o NPS para atuar como um servidor proxy e encaminhar solicitações de
conexão de clientes RADIUS para servidores RADIUS remotos, você deve executar as
seguintes ações:
1. Implante seus clientes RADIUS (servidores VPN, servidores dial-up, servidores de

gateway de serviços de terminal, comutadores de autenticação 802.1 X e pontos
de acesso sem fio 802.1 X) e configure-os para enviar solicitações de conexão para
seus servidores proxy NPS.
2. No proxy NPS, configure os servidores de acesso à rede como clientes RADIUS.

Para obter mais informações, consulte configurar clientes RADIUS.
3. No proxy NPS, crie um ou mais grupos de servidores RADIUS remotos. Durante
esse processo, adicione servidores RADIUS aos grupos de servidores RADIUS
remotos. Para obter mais informações, consulte configurar grupos de servidores
remotos RADIUS.
4. No proxy NPS, para cada servidor RADIUS que você adiciona a um grupo de
servidores remotos RADIUS, clique na guia balanceamento de carga do servidor
RADIUS e configure prioridade, pesoe Configurações avançadas.
5. No proxy NPS, configure as políticas de solicitação de conexão para encaminhar

solicitações de autenticação e contabilização para grupos de servidores RADIUS
remotos. Você deve criar uma política de solicitação de conexão por grupo de
servidores RADIUS remotos. Para obter mais informações, consulte Configurar
políticas de solicitação de conexão.
Registrar um NPS em um domínio do
Active Directory
Você pode usar este tópico para registrar um servidor que executa o Servidor de
Políticas de Rede Windows Server 2016 no domínio padrão do NPS ou em outro
domínio.
Registrar um NPS em seu domínio padrão

Você pode usar esse procedimento para registrar um NPS no domínio em que o
servidor é um membro de domínio.
Os NPSs devem ser registrados no Active Directory para que tenham permissão para ler
as propriedades discadas das contas de usuário durante o processo de autorização.
Registrar um NPS adiciona o servidor ao grupo servidores RAS e IAS no Active
Directory.


em Servidor de Política de Rede. O console do Servidor de Políticas de Rede é
aberto.

Servidor no Active Directory. A caixa de diálogo Servidor de Políticas de Rede é
aberta.
Registrar um NPS em outro domínio

Para fornecer um NPS com permissão para ler as propriedades discadas de contas de
usuário no Active Directory, o NPS deve ser registrado no domínio em que as contas
residem.
Você pode usar esse procedimento para registrar um NPS em um domínio em que o
NPS não é um membro de domínio.

Para registrar um NPS em outro domínio

1. No controlador de domínio, em Gerenciador do Servidor, clique em Ferramentase
clique em Usuários e Computadores do Active Directory. O console de Usuários e
Computadores do Active Directory é aberto.
2. Na árvore de console, navegue até o domínio em que você deseja que o NPS leia
as informações da conta de usuário e clique na pasta Usuários.
3. No painel de detalhes, clique com o botão direito do mouse em Servidores RAS e

IAS e clique em Propriedades. A caixa de diálogo Propriedades de Servidores
RAS e IAS é aberta.
4. Na caixa de diálogo Propriedades de Servidores RAS e IAS, clique na guia

Membros, adicione cada um dos NPSs que deseja registrar no domínio e clique em
OK.
Para registrar um NPS em outro domínio usando

comandos Netsh para NPS
1. Abra o Prompt de Comando ou o Windows PowerShell.
2. Digite o seguinte no prompt de comando: netsh nps add

registeredserverdomainserver e pressione ENTER.
７ Observação
No comando anterior, domínio é o nome de domínio DNS do domínio em que

você deseja registrar o NPS e o servidor é o nome do computador NPS.
Cancelar o registro de um NPS de um
domínio do Active Directory
No processo de gerenciamento da implantação do NPS, talvez seja útil mover um NPS

para outro domínio, substituir um NPS ou desativar um NPS.
Ao mover ou desativar um NPS, você pode cancelar o registro do NPS nos domínios de
Active Directory em que o NPS tem permissão para ler as propriedades de contas de
usuário em Active Directory.

Para cancelar o registro de um NPS

1. No controlador de domínio, em Gerenciador do Servidor, clique em ferramentase,
em seguida, clique em Active Directory usuários e computadores. O console de
Usuários e Computadores do Active Directory é aberto.
2. Clique em usuáriose, em seguida, clique duas vezes em Servidores RAS e ias.
3. Clique na guia Membros e selecione o NPS que você deseja cancelar o registro.
4. Clique em remover, em Sime em OK.

Use expressões regulares no NPS
Este tópico explica o uso de expressões regulares para correspondência de padrões no

NPS no Windows Server. Você pode usar essa sintaxe para especificar as condições de
atributos de política de rede e realms RADIUS.
７ Observação
O Console do NPS e o snap-in do NPS MMC têm um limite de 256 caracteres para
todas as configurações que levam um valor de cadeia de caracteres. Isso inclui
todas as configurações que podem ser configuradas usando expressões regulares.
Para configurar valores de cadeia de caracteres que excedem 256 caracteres, use
comandos NPS NETSH.
Valores de cadeia de caracteres configurados que excedem
256 caracteres não podem ser editados no Console do NPS ou no snap-in do NPS
MMC sem invalidá-los.
Referência de correspondência de padrões

Você pode usar a tabela a seguir como uma fonte de referência ao criar expressões
regulares com sintaxe de correspondência de padrões. Observe que os padrões de
expressão regular geralmente são cercados por barras (/).
Caractere Descrição Exemplo
\ Indica que o caractere a seguir é um caractere /n/ matches the character "n"
especial ou deve ser interpretado literalmente. while the sequence /\n/ matches a
line feed or newline character.
^ Corresponde ao início da entrada ou linha.
$ Corresponde ao final da entrada ou linha.
* Corresponde ao caractere anterior zero ou /zo*/ matches either "z" or

mais vezes. "zoo."
+ Corresponde ao caractere anterior uma ou /zo+/ matches "zoo" but not "z."
mais vezes.
? Corresponde ao caractere anterior zero ou /a?ve?/ matches the "ve" in

uma vez. "never."
. Corresponde a qualquer caractere único,

exceto um caractere de nova linha.
(pattern) Corresponde a "padrão" e lembra a

correspondência.
Para corresponder aos caracteres literais ( e

) (parênteses), use $ ou $ .
x | y Corresponde a x ou y.
{n} Corresponde exatamente a n vezes (n é um /o{2}/ does not match the "o" in
inteiro não negativo). "Bob," but matches the first two
instances of the letter o in
"foooood."
{n,} Corresponde pelo menos n vezes (n é um /o{2,}/ does not match the "o" in
inteiro não negativo). "Bob" but matches all of the
instances of the letter o in
"foooood." /o{1,}/ is equivalent
to /o+/.
{n,m} Corresponde pelo menos n e no máximo m /o{1,3}/ matches the first three
vezes (m e n são inteiros não negativos). instances of the letter o in
"fooooood."
[xyz] Corresponde a qualquer um dos caracteres /[abc]/ matches the "a" in

delimitados (um conjunto de caracteres). "plain."
[^xyz] Corresponde a todos os caracteres que não /[^abc]/ matches the "p" in
estão incluídos (um conjunto de caracteres "plain."
negativo).
\b Corresponde a um limite de palavra (por /ea*r\b/ matches the "er" in

exemplo, um espaço). "never early."
\B Corresponde a um limite de não palavra. /ea*r\B/ matches the "ear" in

"never early."
\d Corresponde a um caractere de dígito

(equivalente a dígitos de 0 a 9).
\D Corresponde a um caractere nondigit

(equivalente a [^0-9] ).
\f Corresponde a um caractere de feed de

formulário.
\n Corresponde a um caractere de feed de linha.
\r Corresponde a um caractere de retorno de

carro.
\s Corresponde a qualquer caractere de espaço

em branco, incluindo espaço, guia e feed de
formulário (equivalente a [ \f\n\r\t\v] ).
\S Corresponde a qualquer caractere de espaço

não branco (equivalente a [^ \f\n\r\t\v] ).
\t Corresponde a um caractere de guia.
\v Corresponde a um caractere de guia vertical.
\w Corresponde a qualquer caractere de palavra,

incluindo sublinhado (equivalente a [A-Za-z0-
9_] ).
\W Corresponde a qualquer caractere que não é

de palavra, excluindo sublinhado (equivalente
a [^A-Za-z0-9_] ).
\num Refere-se a correspondências lembradas ( ? \1 substitui o que é armazenado

num em que num é um inteiro positivo). Essa na primeira correspondência
opção só pode ser usada na caixa de texto lembrada.
Substituir ao configurar a manipulação de
atributo.
/n/ Permite a inserção de códigos ASCII em

expressões regulares ( ?n em que n é um valor
octal, hexadecimal ou decimal escape).
Exemplos de atributos de política de rede

Os exemplos a seguir descrevem o uso da sintaxe de correspondência de padrões para
especificar atributos de política de rede:
Para especificar todos os números de telefone dentro do código de área 899, a

sintaxe é:
899.*
Para especificar um intervalo de endereços IP que começam com 192.168.1, a
sintaxe é:
192\.168\.1\..+
Exemplos de manipulação do nome de realm

no atributo Nome de Usuário
７ Observação
A manipulação de realm não funciona com PEAP.
O comportamento desejado pode ser realizado alternando para EAP-TLS ou EAP-

MSCHAPv2 para autenticação ou adicionando um sufixo UPN ao domínio para
cada nome de domínio adicional que você precisa resolver.
Os exemplos a seguir descrevem o uso da sintaxe de correspondência de padrões para

manipular nomes de realm para o atributo Nome de Usuário, que está localizado na
guia Atributo nas propriedades de uma política de solicitação de conexão.
Para remover a parte realm do atributo Nome de Usuário
Em um cenário de discagem terceirizado no qual um provedor de serviços de Internet

(ISP) roteia solicitações de conexão para um NPS da organização, o proxy RADIUS do
ISP pode exigir um nome realm para rotear a solicitação de autenticação. No entanto, o
NPS pode não reconhecer a parte do nome realm do nome de usuário. Portanto, o
nome do realm deve ser removido pelo proxy RADIUS do ISP antes de ser encaminhado
para o NPS da organização.
Encontrar: @microsoft\.com
Substitua:
Para substituir user@example.microsoft.com por example.microsoft.com\user
Encontrar: (.*)@(.*)
Substituir: $2\$1
Para substituir domain\user por specific_domain\user
Encontrar: (.*)\\(.*)
Substituir: specific_domain \$2

Para substituir o usuário por user@specific_domain
Encontrar: $
Substituir: @specific_domain
Exemplo de encaminhamento de mensagens

RADIUS por um servidor proxy
Você pode criar regras de roteamento que encaminham mensagens RADIUS com um
nome realm especificado para um conjunto de servidores RADIUS quando o NPS é
usado como um proxy RADIUS. A seguir está uma sintaxe recomendada para
solicitações de roteamento com base no nome do realm.
Nome do NetBIOS: WCOAST

Padrão: ^wcoast\\
No exemplo a seguir, wcoast.microsoft.com é um sufixo UPN (nome de entidade de

usuário) exclusivo para o domínio DNS ou Active Directory wcoast.microsoft.com.
Usando o padrão fornecido, o proxy NPS pode rotear mensagens com base no nome
netBIOS do domínio ou no sufixo UPN.
Nome do NetBIOS: WCOAST

Sufixo UPN: wcoast.microsoft.com
Padrão: ^wcoast\\|@wcoast\.microsoft\.com$
de política de rede.
Para obter mais informações sobre o NPS, consulte NPS (Servidor de Política de Rede).
Verificar a configuração após as
alterações do NPS
Você pode usar este tópico para verificar a configuração do NPS após a alteração de um
endereço IP ou nome para o servidor.
Verificar a configuração após a alteração de um

endereço IP do NPS
Pode haver circunstâncias em que você precisa alterar o endereço IP de um NPS ou
proxy, como quando você move o servidor para uma sub-rede IP diferente.
Se você alterar um endereço IP de proxy ou NPS, será necessário reconfigurar partes de

sua implantação do NPS.
Use as diretrizes gerais a seguir para ajudá-lo a verificar se uma alteração de endereço
IP não interrompe a autenticação, autorização ou contabilização de acesso à rede em
sua rede para servidores RADIUS NPS e servidores proxy RADIUS.
Você deve ser um membro de Administradores, ou equivalente, para executar esses

procedimentos.
Para verificar a configuração após a alteração de um

endereço IP do NPS
1. Reconfigure todos os clientes RADIUS, como pontos de acesso sem fio e
servidores VPN, com o novo endereço IP do NPS.
2. Se o NPS for membro de um grupo de servidores RADIUS remotos, reconfigure o

proxy NPS com o novo endereço IP do NPS.
3. se você configurou o NPS para usar SQL Server registro em log, verifique se a
conectividade entre o computador que está executando o SQL Server e o NPS
ainda está funcionando corretamente.
4. se você tiver implantado o IPsec para proteger o tráfego RADIUS entre o NPS e um
proxy nps ou outros servidores ou dispositivos, reconfigure a política IPsec ou a
regra de segurança de conexão no Windows Firewall com segurança avançada
para usar o novo endereço IP do NPS.
5. Se o NPS for de hospedagem múltipla e você tiver configurado o servidor para

associar a um adaptador de rede específico, redefina as configurações de porta do
NPS com o novo endereço IP.
Para verificar a configuração após a alteração de um

endereço IP de proxy NPS
1. Reconfigure todos os clientes RADIUS, como pontos de acesso sem fio e
servidores VPN, com o novo endereço IP do proxy NPS.
2. Se o proxy NPS for de hospedagem múltipla e você tiver configurado o proxy para
associar a um adaptador de rede específico, redefina as configurações de porta do
NPS com o novo endereço IP.
3. Reconfigure todos os membros de todos os grupos de servidores remotos RADIUS

com o endereço IP do servidor proxy. Para realizar essa tarefa, em cada NPS que
tem o proxy NPS configurado como um cliente RADIUS:
a. Clique duas vezes em NPS (local), clique duas vezes em clientes e servidores
RADIUS, clique em clientes RADIUSe, no painel de detalhes, clique duas vezes no
cliente RADIUS que você deseja alterar.
b. Em Propriedadesdo cliente RADIUS, em Endereço (IP ou DNS), digite o novo

endereço IP do proxy NPS.
4. se você tiver configurado o proxy NPS para usar o log de SQL Server, verifique se a
conectividade entre o computador que executa o SQL Server e o proxy NPS ainda
está funcionando corretamente.
Verificar a configuração após renomear um

NPS
Pode haver circunstâncias em que você precisa alterar o nome de um NPS ou proxy,
como quando você remodela as convenções de nomenclatura para seus servidores.
Se você alterar um nome de proxy ou NPS, será necessário reconfigurar partes de sua
implantação do NPS.
Use as diretrizes gerais a seguir para ajudá-lo a verificar se uma alteração de nome de
servidor não interrompe a autenticação, autorização ou contabilização de acesso à rede.
Você deve ser um membro de Administradores, ou equivalente, para executar esse

procedimento.
Para verificar a configuração após a alteração de um NPS

ou de um nome de proxy
1. Se o NPS for membro de um grupo de servidores remotos RADIUS e o grupo
estiver configurado com nomes de computador em vez de endereços IP,
reconfigure o grupo de servidores remotos RADIUS com o novo nome do NPS.
2. Se os métodos de autenticação baseados em certificado forem implantados no

NPS, a alteração de nome invalida o certificado do servidor. Você pode solicitar um
novo certificado do administrador da autoridade de certificação (CA) ou, se o
computador for um computador membro do domínio e registrar automaticamente
os certificados para os membros do domínio, você poderá atualizar Política de
Grupo para obter um novo certificado por meio do registro automático. Para
atualizar Política de Grupo:
a. Abra o prompt de comando ou Windows PowerShell.
b. Digite gpupdate e pressione ENTER.
3. Depois de ter um novo certificado de servidor, solicite que o administrador da

autoridade de certificação revogue o certificado antigo.
Depois que o certificado antigo for revogado, o NPS continuará a usá-lo até que o
certificado antigo expire. Por padrão, o certificado antigo permanece válido por
um tempo máximo de uma semana e 10 horas. Esse período de tempo pode ser
diferente dependendo se a expiração da CRL (lista de certificados revogados) e a
expiração do tempo de cache da TLS (segurança da camada de transporte) foram
modificadas a partir de seus padrões. A expiração da CRL padrão é de uma
semana; a expiração do tempo de cache TLS padrão é de 10 horas.
Se você quiser configurar o NPS para usar o novo certificado imediatamente, no

entanto, você pode reconfigurar manualmente as políticas de rede com o novo
certificado.
4. Depois que o certificado antigo expira, o NPS começa automaticamente a usar o

novo certificado.
5. se você configurou o NPS para usar SQL Server registro em log, verifique se a
conectividade entre o computador que está executando o SQL Server e o NPS
ainda está funcionando corretamente.
Coleta de dados de usuário do servidor
de políticas de rede
Este documento explica como localizar informações de usuário coletadas pelo NPS
(servidor de diretivas de rede) no evento que você gostaria de removê-las.
７ Observação
Se você estiver interessado em exibir ou excluir dados pessoais, examine as

diretrizes da Microsoft no site Solicitações de entidades de dados do Windows
para o RGPD. Se você estiver procurando informações gerais sobre o RGPD, confira
a seção RGPD do Portal de Confiança do Serviço .
Informações coletadas pelo NPS

Timestamp
Carimbo de hora do evento
Nome de Usuário
Nome de usuário totalmente qualificado
Endereço IP do Cliente
Fornecedor do cliente
Nome amigável do cliente
Tipo de autenticação
Vários outros campos relacionados ao protocolo RADIUS
Coletar dados do NPS

se os dados de contabilidade estiverem habilitados e configurados, os registros das
tentativas de autenticação do NPS de um usuário poderão ser obtidos em SQL Server
ou nos arquivos de log, dependendo da configuração.
se os dados de contabilidade estiverem configurados para SQL Server, consulte para

todos os registros em que User_Name = '<username>' .
Se os dados de contabilidade estiverem configurados para um arquivo de log, pesquise

o arquivo de log para <username> Localizar todas as entradas de log.
as entradas de diretiva de rede e de log de eventos Serviços do Access são consideradas
duplicadas para os dados de contabilidade e não precisam ser coletadas.
se os dados de contabilidade não estiverem habilitados, os registros das tentativas de

autenticação NPS de um usuário poderão ser obtidos na diretiva de rede e no log de
eventos Serviços do Access pesquisando <username> pelo.
Gerenciar modelos do NPS
Você pode usar modelos npS (Servidor de Políticas de Rede) para criar elementos de
configuração, como clientes Remote Authentication Dial-In User Service (RADIUS) ou
segredos compartilhados, que você pode reutilizar no NPS local e exportar para uso em
outros NPSs.
O Gerenciamento de Modelos fornece um nó no console do NPS em que você pode

criar, modificar, excluir, duplicar e exibir o uso de modelos NPS. Os modelos NPS são
projetados para reduzir a quantidade de tempo e o custo necessários para configurar o
NPS em um ou mais servidores.
Os seguintes tipos de modelo NPS estão disponíveis para configuração no

Gerenciamento de Modelos.
Segredos compartilhados. Esse tipo de modelo possibilita que você especifique

um segredo compartilhado que você pode reutilizar (selecionando o modelo no
local apropriado no console do NPS) ao configurar clientes e servidores RADIUS.
Clientes RADIUS. Esse tipo de modelo possibilita definir as configurações do

cliente RADIUS que você pode reutilizar selecionando o modelo no local
apropriado no console do NPS.
Servidores RADIUS remotos. Esse modelo possibilita definir as configurações

remotas do servidor RADIUS que você pode reutilizar selecionando o modelo no
local apropriado no console do NPS.
Filtros IP. Esse modelo possibilita que você crie filtros protocolo IP versão 4 (IPv4)
e IPv6 (Internet Protocol versão 6) que você possa reutilizar (selecionando o
modelo no local apropriado no console NPS) ao configurar políticas de rede.
Criar um modelo NPS

Configurar um modelo é diferente de configurar o NPS diretamente. A criação de um
modelo não afeta a funcionalidade do NPS. É somente quando você seleciona o modelo
no local apropriado no console nps e aplica o modelo que afeta a funcionalidade do
NPS.
Por exemplo, se você configurar um cliente RADIUS no console do NPS em Clientes e
Servidores RADIUS, altere a configuração do NPS e dê uma etapa na configuração do
NPS para se comunicar com um de seus servidores de acesso à rede. (A próxima etapa é
configurar o NAS (servidor de acesso à rede) para se comunicar com o NPS.)
No entanto, se você configurar um novo modelo de Clientes RADIUS no console NPS

em Gerenciamento de Modelos em vez de criar um novo cliente RADIUS em Clientes e
Servidores RADIUS, você criou um modelo, mas ainda não alterou a funcionalidade nps.
Para alterar a funcionalidade do NPS, você deve aplicar o modelo do local correto no
console do NPS.
O procedimento a seguir fornece instruções sobre como criar um novo modelo.

este procedimento.
Para criar um modelo NPS

2. No console do NPS , expanda Gerenciamento de Modelos, clique com o botão

direito do mouse em um tipo de modelo, como Clientes RADIUS e clique em
Novo.
3. Uma nova caixa de diálogo de propriedades de modelo é aberta que você pode
usar para configurar seu modelo.
Aplicar um modelo NPS

Você pode usar um modelo que você criou no Gerenciamento de Modelos navegando
até um local no console do NPS em que você pode aplicar o modelo. Por exemplo, se
você quiser aplicar um modelo de Segredos Compartilhados a uma configuração de
cliente RADIUS, poderá usar o procedimento a seguir.

este procedimento.
Para aplicar um modelo NPS

2. No console do NPS, expanda Clientes e Servidores RADIUS e, em seguida,
expanda Clientes RADIUS.
3.In clientes RADIUS, no painel de detalhes, clique com o botão direito do mouse no
cliente RADIUS ao qual você deseja aplicar o modelo NPS e clique em Propriedades.
4. Na caixa de diálogo propriedades do cliente RADIUS, em Selecionar um modelo de

Segredos Compartilhados existente, selecione o modelo que você deseja aplicar
na lista de modelos.
Exportar ou importar modelos NPS

Você pode exportar modelos para uso em outros NPSs ou importar modelos para o
Gerenciamento de Modelos para uso no computador local.

este procedimento.
Para exportar ou importar modelos NPS

1. Para exportar modelos NPS, no console do NPS, clique com o botão direito do
mouse em Gerenciamento de Modelos e clique emExportar Modelos para um
Arquivo.
2. Para importar modelos NPS, no console do NPS, clique com o botão direito do
mouse em Gerenciamento de Modelos e clique em Importar Modelos de um
Computador ou Importar Modelos de um Arquivo.
Shell de rede (netsh)
Azure Stack HCI, versões 21H2 e 20H2
O Netsh (Shell de Rede) é um utilitário de linha de comando que permite configurar e

exibir o status de vários componentes e funções de servidor de comunicações de rede
depois que são instalados nos computadores que executam o Windows Server.
Algumas tecnologias de cliente, como o cliente DHCP (Dynamic Host Configuration

Protocol) e o BranchCache, também fornecem comandos netsh que permitem
configurar computadores cliente que estão executando Windows 10.
Na maioria dos casos, os comandos netsh fornecem a mesma funcionalidade disponível

quando você usa o snap-in do MMC (Console de Gerenciamento da Microsoft) para
cada função de servidor de rede ou recurso de rede. Por exemplo, você pode configurar
o NPS (Servidor de Política de Rede) usando o snap-in MMC do NPS ou os comandos
netsh no contexto netsh nps .
Além disso, há comandos netsh para tecnologias de rede, como para IPv6, ponte de
rede e RPC (Chamada de Procedimento Remoto), que não estão disponíveis no
Windows Server como um snap-in do MMC.
） Importante
Recomendamos usar o Windows PowerShell para gerenciar as tecnologias de rede

no Windows Server e Windows 10 em vez de no Shell de Rede. O Shell de Rede
está incluído para compatibilidade com seus scripts e seu uso tem suporte.
Referência técnica do Netsh

A referência de comando netsh fornece uma lista abrangente de comandos netsh,
incluindo sintaxe, parâmetros e exemplos. Você pode usar essa referência para criar
scripts e arquivos em lote usando comandos netsh para gerenciamento local ou remoto
de tecnologias de rede e dispositivos.
Sintaxe, Contextos e Formatação do
Comando Netsh
Você pode usar este tópico para aprender a inserir contextos e subcontextos netsh, a
entender a formatação da sintaxe e do comando netsh e a executar comandos netsh em
computadores locais e remotos.
O Netsh é um utilitário de script de linha de comando que permite exibir ou modificar a

configuração de rede de um computador em execução no momento. Os comandos
netsh podem ser executados digitando comandos no prompt netsh e podem ser usados
em arquivos ou scripts em lotes. Os computadores remotos e o computador local
podem ser configurados usando comandos netsh.
O Netsh também fornece um recurso de script com o qual você pode executar um
grupo de comandos no modo em lote para um computador especificado. Com o Netsh,
você pode salvar um script de configuração em um arquivo de texto para fins de
arquivamento ou para ajudar você a configurar outros computadores.
Contextos netsh
O Netsh interage com outros componentes do sistema operacional usando arquivos
DLL (biblioteca de vínculo dinâmico).
Cada DLL auxiliar do netsh fornece um amplo conjunto de recursos chamado de

contexto, que é um grupo de comandos específicos a uma função de servidor de rede
ou recurso. Esses contextos ampliam a funcionalidade do netsh fornecendo suporte de
configuração e monitoramento para um ou mais serviços, utilitários ou protocolos. Por
exemplo, Dhcpmon.dll fornece o netsh com o contexto e o conjunto de comandos
necessários para configurar e gerenciar servidores DHCP.
Obter uma lista de contextos

Você pode obter uma lista de contextos netsh abrindo o prompt de comando ou o
Windows PowerShell em um computador que executa Windows Server 2016 ou
Windows 10. Digite o comando netsh e pressione ENTER. Digite /? e pressione ENTER.
Veja a seguir um exemplo de saída desses comandos em um computador que executa o
Windows Server 2016 Datacenter.
PS C:\Windows\system32> netsh
netsh>/?
The following commands are available:
Commands in this context:
.. - Goes up one context level.
? - Displays a list of commands.
abort - Discards changes made while in offline mode.
add - Adds a configuration entry to a list of entries.
advfirewall - Changes to the `netsh advfirewall' context.
alias - Adds an alias.
branchcache - Changes to the `netsh branchcache' context.
bridge - Changes to the `netsh bridge' context.
bye - Exits the program.
commit - Commits changes made while in offline mode.
delete - Deletes a configuration entry from a list of entries.
dhcpclient - Changes to the `netsh dhcpclient' context.
dnsclient - Changes to the `netsh dnsclient' context.
dump - Displays a configuration script.
exec - Runs a script file.
exit - Exits the program.
firewall - Changes to the `netsh firewall' context.
help - Displays a list of commands.
http - Changes to the `netsh http' context.
interface - Changes to the `netsh interface' context.
ipsec - Changes to the `netsh ipsec' context.
ipsecdosprotection - Changes to the `netsh ipsecdosprotection' context.
lan - Changes to the `netsh lan' context.
namespace - Changes to the `netsh namespace' context.
netio - Changes to the `netsh netio' context.
offline - Sets the current mode to offline.
online - Sets the current mode to online.
popd - Pops a context from the stack.
pushd - Pushes current context on stack.
quit - Exits the program.
ras - Changes to the `netsh ras' context.
rpc - Changes to the `netsh rpc' context.
set - Updates configuration settings.
show - Displays information.
trace - Changes to the `netsh trace' context.
unalias - Deletes an alias.
wfp - Changes to the `netsh wfp' context.
winhttp - Changes to the `netsh winhttp' context.
winsock - Changes to the `netsh winsock' context.
The following sub-contexts are available:
advfirewall branchcache bridge dhcpclient dnsclient firewall http

interface ipsec ipsecdosprotection lan namespace netio ras rpc trace wfp
winhttp winsock
To view help for a command, type the command, followed by a space, and
then type ?.
Subcontextos
Os contextos netsh podem conter comandos e contextos adicionais, chamados
subcontextos. Por exemplo, dentro do contexto de roteiros, você pode alterar para os
subcontextos IP e IPv6.
Para exibir uma lista de comandos e subcontextos que você pode usar em um contexto,
no prompt netsh, digite o nome do contexto e digite /? ou help. Por exemplo, para
exibir uma lista de subcontextos e comandos que você pode usar no contexto de
roteamento, no prompt netsh (ou seja, netsh), digite um dos seguintes:
routing /?
routing help
Para executar tarefas em outro contexto sem alterar o contexto atual, digite o caminho
de contexto do comando que você deseja usar no prompt do netsh. Por exemplo, para
adicionar uma interface denominada "Conexão de Área Local" no contexto IGMP sem
primeiro alterar para o contexto IGMP, no prompt do netsh, digite:
routing ip igmp add interface "Local Area Connection" startupqueryinterval=21
Executar comandos netsh

Para executar um comando netsh, você deve iniciar o netsh no prompt de comando
digitando netsh e pressionando ENTER. Em seguida, você pode mudar para o contexto
que contém o comando que deseja usar. Os contextos disponíveis dependem dos
componentes de rede instalados. Por exemplo, se você digitar dhcp no prompt do netsh
e pressionar ENTER, o netsh mudará para o contexto do servidor DHCP. No entanto, se
você não tiver o DHCP instalado, a seguinte mensagem será exibida:
O seguinte comando não foi encontrado: dhcp.
Legenda de formatação
Você pode usar a legenda de formatação a seguir para interpretar e usar a sintaxe de
comando netsh correta ao executar o comando no prompt netsh ou em um arquivo ou
script em lotes.
O texto em itálico é a informação que você deve fornecer enquanto digita o
comando. Por exemplo, se um comando tiver um parâmetro denominado -
UserName, você deverá digitar o nome de usuário real.
O texto em negrito é a informação que você deve digitar exatamente conforme
mostrado enquanto você digita o comando.
Texto seguido por reellipse (...) é um parâmetro que pode ser repetido várias vezes
em uma linha de comando.
Texto entre colchetes [ ] é um item opcional.
Texto entre chaves { } com opções separadas por um pipe fornece um conjunto de
opções do qual você deve selecionar apenas uma, como {enable|disable} .
O texto formatado com a fonte Courier é a saída do código ou do programa.
Executar comandos Netsh no prompt de

comando ou no Windows PowerShell
Para iniciar o Shell de Rede e inserir o netsh no prompt de comando ou no Windows
PowerShell, você pode usar o comando a seguir.
netsh
O Netsh é um utilitário de script de linha de comando que permite, local ou
remotamente, exibir ou modificar a configuração de rede de um computador em
execução no momento. Usado sem parâmetros, o netsh abre o prompt Netsh.exe
comando (ou seja, netsh).
Sintaxe
netsh[ -aAliasFile] [ -cContext ] [-rRemoteComputer] [ -u [ DomainName\ ] UserName ] [
-pPassword | *] [{NetshCommand-fScriptFile}]
Parâmetros
-a
Opcional. Especifica que você é levado de volta ao prompt do netsh depois de executar
AliasFile.
AliasFile
Opcional. Especifica o nome do arquivo de texto que contém um ou mais comandos
netsh.
-c
Opcional. Especifica que o netsh insere o contexto do netsh especificado.
Context
Opcional. Especifica o contexto do netsh que você deseja inserir.
-r
Opcional. Especifica que você deseja que o comando seja executado em um

computador remoto.
） Importante
Quando você usa alguns comandos netsh remotamente ou outro computador com
o parâmetro netsh –r, o serviço do Registro Remoto deve ser executado no
computador remoto. Se não estiver em execução, o Windows exibirá uma
mensagem de erro "Caminho de Rede não encontrado".
RemoteComputer
Opcional. Especifica o computador remoto que você deseja configurar.
-u
Opcional. Especifica que você deseja executar o comando netsh em uma conta de
usuário.
DomainName\\
Opcional. Especifica o domínio em que a conta de usuário está localizada. O padrão será
o domínio local se DomainName\ não for especificado.
UserName
Opcional. Especifica o nome da conta de usuário.
-p
Opcional. Especifica que você deseja fornecer uma senha para a conta de usuário.
Password
Opcional. Especifica a senha da conta de usuário que você especificou com -
uUserName.
NetshCommand
Opcional. Especifica o comando netsh que você deseja executar.
-f
Opcional. Sai do netsh depois de executar o script que você designa com ScriptFile.
ScriptFile
Opcional. Especifica o script que você deseja executar.
/?
Opcional. Exibe a ajuda no prompt do netsh.
７ Observação
Se você especificar -r seguido por outro comando, -r executará o comando no

computador remoto e voltará para o prompt de comando Cmd.exe. Se você
especificar -r sem outro comando, o -r será aberto no modo remoto. O processo
é semelhante ao uso de set machine no prompt de comando Netsh. Quando você
usa -r , você define o computador de destino da instância atual do -r somente.
Depois de sair e entrar novamente no netsh, o computador de destino será
redefinido como o computador local. Você pode executar comandos netsh em um
computador remoto especificando um nome do computador armazenado no
WINS, um nome UNC, um nome de Internet a ser resolvido pelo servidor DNS ou
um endereço IP.
Digitar valores de cadeia de caracteres de parâmetro para comandos netsh
Em toda a referência do comando Netsh, há comandos que contêm parâmetros para os

quais um valor de cadeia de caracteres é necessário.
Caso um valor de cadeia de caracteres contenha espaços entre caracteres, como valores
de cadeia de caracteres compostos por mais de uma palavra, é necessário colocar o
valor da cadeia de caracteres entre aspas. Por exemplo, para um parâmetro denominado
interface com um valor de cadeia de caracteres de Conexão de Rede Sem Fio, use o
valor de cadeia de caracteres entre aspas:
interface="Wireless Network Connection"

Arquivo em lotes de exemplo do Netsh
(shell de rede)
Use este tópico para aprender a criar um arquivo em lotes que executa várias tarefas
usando o Netsh no Windows Server. Este exemplo de arquivo em lotes usa o contexto
netsh wins.
Visão geral do arquivo em lote de exemplo

Você pode usar comandos Netsh para Windows WINS (Serviço de Nome da Internet)
em arquivos em lotes e outros scripts para automatizar tarefas. O exemplo de arquivo
em lotes a seguir demonstra como usar comandos Netsh para o WINS para executar
uma variedade de tarefas relacionadas.
Neste arquivo em lotes de exemplo, WINS-A é um servidor WINS com o endereço IP

192.168.125.30 e WINS-B é um servidor WINS com o endereço IP 192.168.0.189.
O arquivo em lotes de exemplo realiza as tarefas a seguir.
Adiciona um registro de nome dinâmico com o endereço IP 192.168.0.205,

MY_RECORD [04h], a WINS-A
Define WINS-B como um parceiro de replicação de push/pull do WINS-A
Conecta-se ao WINS-B e define WINS-A como um parceiro de replicação de
push/pull do WINS-B
Inicia uma replicação por push de WINS-A para WINS-B
Conecta-se ao WINS-B para verificar se o novo registro, MY_RECORD, foi replicado
com êxito
Arquivo em lotes de exemplo Netsh

No exemplo de arquivo em lotes a seguir, as linhas que contêm comentários são
precedidas por "rem", de remark (comentário, em inglês). O Netsh ignora os
comentários.
rem: Begin example batch file.
rem two WINS servers:
rem (WINS-A) 192.168.125.30
rem (WINS-B) 192.168.0.189
rem 1. Connect to (WINS-A), and add the dynamic name MY\_RECORD \[04h\] to
the (WINS-A) database.
netsh wins server 192.168.125.30 add name Name=MY\_RECORD EndChar=04 IP=

{192.168.0.205}
rem 2. Connect to (WINS-A), and set (WINS-B) as a push/pull replication

partner of (WINS-A).
netsh wins server 192.168.125.30 add partner Server=192.168.0.189 Type=2
rem 3. Connect to (WINS-B), and set (WINS-A) as a push/pull replication

partner of (WINS-B).
netsh wins server 192.168.0.189 add partner Server=192.168.125.30 Type=2
rem 4. Connect back to (WINS-A), and initiate a push replication to (WINS-

B).
netsh wins server 192.168.125.30 init push Server=192.168.0.189 PropReq=0
rem 5. Connect to (WINS-B), and check that the record MY_RECORD [04h] was
replicated successfully.
netsh wins server 192.168.0.189 show name Name=MY_RECORD EndChar=04
rem 6. End example batch file.
Comandos WINS do Netsh usados no exemplo

de arquivo em lotes
A seção a seguir lista os comandos netsh wins usados neste procedimento de exemplo.
server. Desloca o contexto de linha de comando WINS atual para o servidor

especificado por seu nome ou endereço IP.
add name. Registra um nome no servidor WINS.
add partner. Adiciona um parceiro de replicação no servidor WINS.
init push. Inicia e envia um gatilho de envio para um servidor WINS.
show name. Exibe informações detalhadas de um registro específico no banco de
dados do servidor WINS.
Comandos Netsh http
Use netsh http para consultar e definir configurações e parâmetros de HTTP.sys.
 Dica
Se você estiver usando o Windows PowerShell em um computador que executa

Windows Server ou Windows 10, insira netsh e pressione Enter. No prompt netsh,
digite http e pressione Enter para obter o prompt netsh http.
netsh http>
Os comandos netsh http disponíveis são:
add iplisten
add sslcert
add timeout
add urlacl
delete cache
delete iplisten
delete sslcert
delete timeout
delete urlacl
flush logbuffer
show cachestate
show iplisten
show servicestate
show sslcert
show timeout
show urlacl
add iplisten
Adiciona um novo endereço IP à lista de escuta de IP, excluindo o número da porta.
Sintaxe
PowerShell
add iplisten [ ipaddress= ] IPAddress
Parâmetros
Parâmetro Descrição Requisito
ipaddress O endereço IPv4 ou IPv6 a ser adicionado à lista de escuta de IP. A lista Necessária
de escuta de IP é usada para definir o escopo da lista de endereços
aos quais o serviço HTTP associa-se. "0.0.0.0" significa qualquer
endereço IPv4 e "::" significa qualquer endereço IPv6.
Exemplos
A seguir, estão quatro exemplos do comando add iplisten.
add iplisten ipaddress=fe80::1

add iplisten ipaddress=1.1.1.1
add iplisten ipaddress=0.0.0.0
add iplisten ipaddress=::
add sslcert
Adiciona uma nova associação de certificado do servidor SSL e as políticas de certificado
de cliente correspondentes a um endereço IP e uma porta.
Sintaxe
PowerShell
add sslcert [ ipport= ] IPAddress:port [ certhash= ] CertHash [ appid= ]

GUID [ [ certstorename= ] CertStoreName [ verifyclientcertrevocation= ]
enable | disable [verifyrevocationwithcachedclientcertonly= ] enable |
disable [ usagecheck= ] enable | disable [ revocationfreshnesstime= ] U-Int
[ urlretrievaltimeout= ] U-Int [sslctlidentifier= ] SSLCTIdentifier [
sslctlstorename= ] SLCtStoreName [ dsmapperusage= ] enable | disable [
clientcertnegotiation= ] enable | disable ] ]
Parâmetros

ipport Especifica o endereço IP e a porta para Necessária

a associação. Um caractere de dois-
pontos (:) é usado como delimitador
entre o endereço IP e o número da
porta.
certhash Especifica o hash de SHA do certificado. Necessária

Esse hash tem 20 bytes e é especificado
como uma cadeia de caracteres
hexadecimal.
appid Especifica o GUID para identificar o Necessária

aplicativo proprietário.
certstorename Especifica o nome do repositório para o Opcional

certificado. O padrão é MY. O
certificado deve ser armazenado no
contexto do computador local.
verifyclientcertrevocation Especifica a verificação de Opcional

Ativada/desativada de revogação de
certificados de cliente.
verifyrevocationwithcachedclientcertonly Especifica se o uso somente do Opcional

certificado de cliente em cache para
verificação de revogação está
habilitado ou desabilitado.
usagecheck Especifica se a verificação de uso está Opcional

habilitada ou desabilitada. O padrão é
habilitada.
revocationfreshnesstime Especifica o intervalo de tempo, em Opcional

segundos, para verificar se há uma CRL
(lista de certificados revogados)
atualizada. Se esse valor for zero, a
nova CRL será atualizada somente se a
anterior expirar.
urlretrievaltimeout Especifica o intervalo de tempo limite Opcional

(em milissegundos) após a tentativa de
recuperar a lista de certificados
revogados para a URL remota.
sslctlidentifier Especifica a lista dos emissores de Opcional

certificado que podem ser confiáveis.
Essa lista pode ser um subconjunto dos
emissores de certificado que são
confiáveis para o computador.
sslctlstorename Especifica o nome do repositório de Opcional

certificados em LOCAL_MACHINE em
que SslCtlIdentifier é armazenado.
dsmapperusage Especifica se os mapeadores do DS Opcional

estão habilitados ou desabilitados. O
padrão é desabilitado.
clientcertnegotiation Especifica se a negociação do Opcional

certificado está habilitada ou
desabilitada. O padrão é desabilitado.
Exemplos
A seguir, está um exemplo do comando add sslcert.
add sslcert ipport=1.1.1.1:443

certhash=0102030405060708090A0B0C0D0E0F1011121314 appid={00112233-4455-
6677-8899- AABBCCDDEEFF}
add timeout
Adiciona um tempo limite global ao serviço.
Sintaxe
PowerShell
add timeout [ timeouttype= ] IdleConnectionTimeout | HeaderWaitTimeout [

value=] U-Short
Parâmetros
timeouttype Tipo de tempo limite para a configuração.
value Valor do tempo limite (em segundos). Se o valor estiver em notação hexadecimal,
adicione o prefixo 0x.
Exemplos
A seguir, estão dois exemplos do comando add timeout.
add timeout timeouttype=idleconnectiontimeout value=120

add timeout timeouttype=headerwaittimeout value=0x40
add urlacl
Adiciona uma entrada de reserva de URL (Uniform Resource Locator). Esse comando
reserva a URL para contas e usuários não administradores. A DACL pode ser especificada
usando um nome de conta do NT com os parâmetros listen e delegate ou usando uma
cadeia de caracteres SDDL.
Sintaxe
PowerShell
add urlacl [ url= ] URL [ [user=] User [ [ listen= ] yes | no [ delegate= ]

yes | no ] | [ sddl= ] SDDL ]
Parâmetros
url Especifica a URL (Uniform Resource Locator) totalmente qualificada. Necessária
user Especifica o nome do usuário ou do grupo de usuários Necessária
listen Especifica um dos seguintes valores: sim: permitir que o usuário Opcional
registre URLs. Este é o valor padrão. não: negar que o usuário registre
URLs.
delegate Especifica um dos seguintes valores: sim: permitir que o usuário Opcional
delegue URLs não: negar que o usuário delegue URLs. Este é o valor
padrão.
sddl Especifica uma cadeia de caracteres SDDL que descreve a DACL. Opcional
Exemplos
A seguir, estão quatro exemplos do comando add urlacl.
Adicionar URL do urlacl = https://+:80/MyUri User = domínio \ usuário

Adicionar URL do urlacl = https://www.contoso.com:80/MyUri User = domínio \
usuário de escuta = sim
Add urlacl URL = https://www.contoso.com:80/MyUri User = domínio \ usuário
delegado = não
add urlacl url=https://+:80/MyUri sddl=...
delete cache
Exclui todas as entradas ou uma entrada especificada do cache do URI do kernel do
serviço HTTP.
Sintaxe
PowerShell
delete cache [ [ url= ] URL [ [recursive= ] yes | no ]
Parâmetros
url Especifica a URL (Uniform Resource Locator) totalmente qualificada que Opcional
você deseja excluir.
recursive Especifica se todas as entradas no cache de URL são removidas. Sim: Opcional
remover todas as entradas não: não remover todas as entradas
Exemplos
A seguir, estão dois exemplos do comando delete cache.
delete cache url=https://www.contoso.com:80/myresource/ recursive=yes

delete cache
delete iplisten
Exclui um endereço IP da lista de escuta de IP. A lista de escuta de IP é usada para
definir o escopo da lista de endereços aos quais o serviço HTTP associa-se.
Sintaxe
PowerShell
delete iplisten [ ipaddress= ] IPAddress
Parâmetros

ipaddress O endereço IPv4 ou IPv6 a ser excluído da lista de escuta de IP. A lista Necessária
de escuta de IP é usada para definir o escopo da lista de endereços
aos quais o serviço HTTP associa-se. "0.0.0.0" significa qualquer
endereço IPv4 e "::" significa qualquer endereço IPv6. Isso não inclui o
número da porta.
Exemplos
A seguir, estão quatro exemplos do comando delete iplisten.
delete iplisten ipaddress=fe80::1

delete iplisten ipaddress=1.1.1.1
delete iplisten ipaddress=0.0.0.0
delete iplisten ipaddress=::
delete sslcert
Excluir as associações de certificado do servidor SSL e as políticas de certificado de
cliente correspondentes a um endereço IP e uma porta.
Sintaxe
PowerShell
delete sslcert [ ipport= ] IPAddress:port
Parâmetros
ipport Especifica o endereço IPv4 ou IPv6 e a porta para a qual as associações Necessária
de certificado SSL são excluídas. Um caractere de dois-pontos (:) é
usado como delimitador entre o endereço IP e o número da porta.
Exemplos
A seguir, estão três exemplos do comando delete sslcert.
delete sslcert ipport=1.1.1.1:443

delete sslcert ipport=0.0.0.0:443
delete sslcert ipport=[::]:443
delete timeout
Exclui um tempo limite global e faz com que o serviço reverta para os valores padrão.
Sintaxe
PowerShell
delete timeout [ timeouttype= ] idleconnectiontimeout | headerwaittimeout
Parâmetros
timeouttype Especifica o tipo de configuração de tempo limite. Necessária
Exemplos
A seguir, estão dois exemplos do comando delete timeout.
delete timeout timeouttype=idleconnectiontimeout

delete timeout timeouttype=headerwaittimeout
delete urlacl
Exclui as reservas de URL.
Sintaxe
PowerShell
delete urlacl [ url= ] URL
Parâmetros
url Especifica a URL (Uniform Resource Locator) totalmente qualificada Necessária

que você deseja excluir.
Exemplos
A seguir, estão dois exemplos do comando delete urlacl.

delete urlacl url=https://+:80/MyUri
delete urlacl url=https://www.contoso.com:80/MyUri
flush logbuffer
Libera os buffers internos para os arquivos de log.
Sintaxe
PowerShell
flush logbuffer
show cachestate
Lista os recursos de URI armazenados em cache e suas propriedades associadas. Este
comando lista todos os recursos e propriedades associadas em cache no cache de
resposta HTTP ou exibe um único recurso e as propriedades associadas a ele.
Sintaxe
PowerShell
show cachestate [ [url= ] URL]
Parâmetros
url Especifica a URL totalmente qualificada que você deseja exibir. Se não Opcional
for especificado, todas as URLs serão exibidas. A URL também pode ser
um prefixo para URLs registradas.
Exemplos
Veja abaixo dois exemplos do comando show cachestate:
show cachestate url=https://www.contoso.com:80/myresource

show cachestate
show iplisten
Exibe todos os endereços IP na lista de escuta de IP. A lista de escuta de IP é usada para
definir o escopo da lista de endereços aos quais o serviço HTTP associa-se. "0.0.0.0"
significa qualquer endereço IPv4 e "::" significa qualquer endereço IPv6.
Sintaxe
PowerShell
show iplisten
show servicestate
Exibe um instantâneo do serviço HTTP.
Sintaxe
PowerShell
show servicestate [ [ view= ] session | requestq ] [ [ verbose= ] yes | no ]
Parâmetros
Exibir Especifica se um instantâneo do estado do serviço HTTP deve ser Opcional

exibido com base na sessão do servidor ou nas filas de solicitação.
Verbose Especifica se é devem ser exibidas informações detalhadas que também Opcional
mostram informações de propriedade.
Exemplos
A seguir, estão dois exemplos do comando show servicestate.
show servicestate view="session"

show servicestate view="requestq"
show sslcert
Exibe associações de certificado do servidor de protocolo SSL e as políticas de
certificado de cliente correspondentes a um endereço IP e uma porta.
Sintaxe
PowerShell
show sslcert [ ipport= ] IPAddress:port
Parâmetros
ipport Especifica o endereço IPv4 ou IPv6 e a porta para a qual as associações Necessária
de certificado SSL são exibidas. Um caractere de dois-pontos (:) é
usado como delimitador entre o endereço IP e o número da porta. Se
você não especificar ipport, todas as associações serão exibidas.
Exemplos
A seguir, estão cinco exemplos do comando show sslcert.
show sslcert ipport=[fe80::1]:443

show sslcert ipport=1.1.1.1:443
show sslcert ipport=0.0.0.0:443
show sslcert ipport=[::]:443
show sslcert
show timeout
Exibe, em segundos, os valores de tempo limite do serviço HTTP.
Sintaxe
PowerShell
show timeout
show urlacl
Exibe DACLs (listas de controle de acesso discricional) para a URL reservada especificada
ou todas as URLs reservadas.
Sintaxe
PowerShell
show urlacl [ [url= ] URL]
Parâmetros
url Especifica a URL totalmente qualificada que você deseja exibir. Se não Opcional
for especificado, todas as URLs serão exibidas.
Exemplos
A seguir, estão três exemplos do comando show urlacl.
show urlacl url=https://+:80/MyUri

show urlacl url=https://www.contoso.com:80/MyUri
show urlacl
Comandos netsh interface portproxy
Use os comandos netsh interface portproxy para funcionar como proxies entre as redes
e aplicativos IPv4 e IPv6. Você pode usar esses comandos para estabelecer o serviço de
proxy das seguintes maneiras:
Mensagens de computador e aplicativo configuradas para IPv4 enviadas para

outros computadores e aplicativos configurados para IPv4.

computadores e aplicativos configurados para IPv6.

computadores e aplicativos configurados para IPv4.

outros computadores e aplicativos configurados para IPv6.
Ao gravar arquivos ou scripts em lotes usando esses comandos, cada comando deve
começar com netsh interface portproxy. Por exemplo, ao usar o comando delete
v4tov6 para especificar que o servidor portproxy exclua uma porta e um endereço IPv4
da lista de endereços IPv4 para os quais o servidor escuta, o script ou o arquivo em
lotes deverá usar a seguinte sintaxe:
PowerShell
netsh interface portproxy delete v4tov6 listenport= {Integer | ServiceName}

[[listenaddress=] {IPv4Address| HostName}] [[protocol=]tcp]
Os comandos netsh interface portproxy disponíveis são:
add v4tov4
add v4tov6
add v6tov4
add v6tov6
delete v4tov4
delete v4tov6
delete v6tov6
reset ipv4
reset ipv6
set v4tov4
set v4tov6
setv6tov4
set v6tov6
show all
show v4tov4
show v4tov6
show v6tov4
show v6tov6
add v4tov4
O servidor portproxy escuta mensagens enviadas a uma porta e um endereço IPv4
específicos. Ele mapeia uma porta e um endereço IPv4 para enviar as mensagens
recebidas após estabelecer uma conexão TCP separada.
Sintaxe
PowerShell
add v4tov4 listenport= {Integer | ServiceName} [[connectaddress=]

{IPv4Address | HostName}] [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv4Address | HostName}] [[protocol=]tcp]
Parâmetros
listenport Especifica a porta IPv4, por número da porta ou nome do serviço, na qual
escutar.
connectaddress Especifica o endereço IPv4 ao qual se conectar. Os valores aceitáveis são

endereço IP, nome NetBIOS do computador ou nome DNS do computador. Se
um endereço não for especificado, o padrão é o computador local.
connectport Especifica a porta IPv4, por número da porta ou nome do serviço, à qual se
conectar. Se connectport não for especificado, o padrão será o valor de
listenport no computador local.
listenaddress Especifica o endereço IPv4 para o qual escutar. Os valores aceitáveis são
protocol Especifica o protocolo a ser usado.
add v4tov6
específicos e mapeia uma porta e um endereço IPv6 para enviar as mensagens
Sintaxe
PowerShell

{IPv6Address | HostName} [[connectport=] {Integer | ServiceName}]
[[listenaddress=] {IPv4Address | HostName} [[protocol=]tcp]
Parâmetros
escutar.

listenaddress Especifica o endereço IPv4 no qual escutar. Os valores aceitáveis são endereço
IP, nome NetBIOS do computador ou nome DNS do computador. Se um
endereço não for especificado, o padrão é o computador local.
add v6tov4
específicos e mapeia uma porta e um endereço IPv4 para os quais enviar as mensagens
Sintaxe
PowerShell

Parâmetros
escutar.

add v6tov6
específicos e mapeia uma porta e um endereço IPv6 para os quais enviar as mensagens
Sintaxe
PowerShell

Parâmetros
escutar.

delete v4tov4
O servidor portproxy exclui um endereço IPv4 da lista de portas e endereços IPv4 para
os quais o servidor escuta.
Sintaxe
PowerShell
delete v4tov4 listenport= {Integer | ServiceName} [[listenaddress=]

{IPv4Address | HostName} [[protocol=]tcp]
Parâmetros
listenport Especifica a porta IPv4 a ser excluída.
listenaddress Especifica o endereço IPv4 a ser excluído. Se um endereço não for especificado, o
padrão é o computador local.
delete v4tov6
O servidor portproxy exclui uma porta e um endereço IPv4 da lista de endereços IPv4
para os quais o servidor escuta.
Sintaxe
PowerShell

Parâmetros
delete v6tov4
O servidor portproxy exclui uma porta e um endereço IPv6 da lista de endereços IPv6
para os quais o servidor escuta.
Sintaxe
PowerShell

Parâmetros
delete v6tov6
O servidor portproxy exclui um endereço IPv6 da lista de endereços IPv6 para os quais o
servidor escuta.
Sintaxe
PowerShell

Parâmetros
reset-ipv4
Redefine o State Configuration do IPv4.
Sintaxe
PowerShell
netsh int ipv4 reset
reset-ipv6
Redefine o estado de configuração do IPv6.
Sintaxe
PowerShell
netsh int ipv6 reset
set v4tov4
Modifica os valores de parâmetro de uma entrada existente no servidor portproxy
criado com o comando add v4tov4 ou adiciona uma nova entrada à lista que mapeia os
pares porta/endereço.
Sintaxe
PowerShell
set v4tov4 listenport= {Integer | ServiceName} [[connectaddress=]

Parâmetros
escutar.

listenaddress Especifica o endereço IPv4 para o qual escutar. Os valores aceitáveis são
set v4tov6
Sintaxe
PowerShell

Parâmetros
escutar.

set v6tov4
Sintaxe
PowerShell

Parâmetros
escutar.

set v6tov6
Sintaxe
PowerShell

Parâmetros
escutar.

IP, nome NetBIOS do computador ou nome DNS do computador. Se você não
especificar um endereço, o padrão será o computador local.
exibir tudo
Exibe todos os parâmetros portproxy, incluindo pares porta/endereço para v4tov4,
v4tov6, v6tov4 e v6tov6.
Sintaxe
show all
show v4tov4
Exibe os parâmetros v4tov4 portproxy.
Sintaxe
show v4tov4
show v4tov6
Sintaxe
show v4tov6
show v6tov4
Sintaxe
show v6tov4
show v6tov6
Sintaxe
show v6tov6
Comandos netsh mbn
Use o netsh mbn para consultar e definir configurações e parâmetros de banda larga
móvel.
 Dica
Você pode obter ajuda sobre o comando netsh mbn usando
netsh mbn /?
Os comandos netsh mbn disponíveis são:
add
connect
delete
disconnect
diagnose
dump
help
set
show
teste
adicionar
Adiciona uma entrada de configuração a uma tabela.
Os comandos netsh mbn add disponíveis são:
dmprofile
profile
dmprofile
Adiciona um perfil de Configuração DM ao Armazenamento de Dados de Perfil.
Sintaxe
PowerShell
add dmprofile [interface=]<string> [name=]<string>
Parâmetros
interface Nome da interface. É um dos nomes de interface mostrados pelo Necessária

comando "netsh mbn show interfaces".
name Nome do arquivo XML do perfil. É o nome do arquivo XML que Necessária
contém os dados do perfil.
Exemplo
PowerShell
add dmprofile interface="Cellular" name="Profile1.xml"
perfil
Adiciona um perfil de rede ao Armazenamento de Dados do Perfil.
Sintaxe
PowerShell
add profile [interface=]<string> [name=]<string>
Parâmetros

Exemplo
PowerShell
add profile interface="Cellular" name="Profile1.xml"
connect
Conecta-se a uma rede de Banda Larga Móvel.
Sintaxe
PowerShell
connect [interface=]<string> [connmode=]tmp|name [name=]<string>
Parâmetros

connmode Especifica como os parâmetros de conexão estão sendo fornecidos. Necessária

Solicite a conexão usando um XML de perfil ou usando um nome de
perfil para o XML de perfil armazenado anteriormente no
Armazenamento de Dados de Perfil de Banda Larga Móvel usando o
comando "netsh mbn add profile". No primeiro caso, o parâmetro
connmode deve conter "tmp" como valor. Enquanto isso, deve ser
"name" no último caso
Exemplos
PowerShell
connect interface="Cellular" connmode=tmp name=d:\profile.xml
connect interface="Cellular" connmode=name name=MyProfileName
excluir
Exclui uma entrada de configuração de uma tabela.
Os comandos netsh mbn delete disponíveis são:
dmprofile
profile
dmprofile
Exclui um perfil de Configuração DM do Armazenamento de Dados de Perfil.
Sintaxe
PowerShell
delete dmprofile [interface=]<string> [name=]<string>
Parâmetros

Exemplo
PowerShell
delete dmprofile interface="Cellular" name="myProfileName"
perfil
Exclui um perfil de rede do Armazenamento de Dados de Perfil.
Sintaxe
PowerShell
delete profile [interface=]<string> [name=]<string>
Parâmetros

Exemplo
PowerShell
delete profile interface="Cellular" name="myProfileName"
diagnose
Executa o diagnóstico para problemas básicos de celular.
Sintaxe
PowerShell
diagnose [interface=]<string>
Parâmetros

Exemplo
PowerShell
diagnose interface="Cellular"
desconectar
Desconecta-se de uma rede de Banda Larga Móvel.
Sintaxe
PowerShell
disconnect [interface=]<string>
Parâmetros

Exemplo
PowerShell
disconnect interface="Cellular"
dump
Exibe um script de configuração.
Cria um script que contém a configuração atual. Se for salvo em um arquivo, esse script
poderá ser usado para restaurar as definições de configuração alteradas.
Sintaxe
PowerShell
dump
ajuda
Exibe uma lista de comandos.
Sintaxe
PowerShell
help
set
Define as informações de configuração.
Os comandos netsh mbn set disponíveis são:
acstate
dataenablement
dataroamcontrol
enterpriseapnparams
highestconncategory
powerstate
profileparameter
slotmapping
tracing
acstate
Define o estado de conexão automática de dados de Banda Larga Móvel para a
interface fornecida.
Sintaxe
PowerShell
set acstate [interface=]<string> [state=]autooff|autoon|manualoff|manualon
Parâmetros

name O estado de conexão automática a ser definido. Um dos seguintes Necessária

valores:
autooff: token de conexão automática desativado.
autoon: token de conexão automática ativado.
manualoff: token de conexão manual desativado.
manualon: token de conexão manual ativado.
Exemplo
PowerShell
set acstate interface="Cellular" state=autoon
dataenablement
Ativa ou desativa os dados de Banda Larga Móvel para o conjunto de perfis e a interface
especificados.
Sintaxe
PowerShell
set dataenablement [interface=]<string> [profileset=]internet|mms|all

[mode=]yes|no
Parâmetros

profileset Nome do conjunto de perfis. Necessária
mode Um dos seguintes valores:

Necessária
yes: habilita o conjunto de perfis alvo.
não: desabilita o conjunto de perfis alvo.
Exemplo
PowerShell
set dataenablement interface="Cellular" profileset=mms mode=yes
dataroamcontrol
Define o estado do controle de roaming de Dados de Banda Larga Móvel para o
conjunto de perfis e a interface especificados.
Sintaxe
PowerShell
set dataroamcontrol [interface=]<string> [profileset=]internet|mms|all

[state=]none|partner|all
Parâmetros

profileset Nome do conjunto de perfis. Necessária


Necessária
none: somente operadora residencial.
partner: somente operadoras residencial e de parceiro.
all: operadoras domésticas, parceiras e de roaming.
Exemplo
PowerShell
set dataroamcontrol interface="Cellular" profileset=mms mode=partner
enterpriseapnparams
Define os parâmetros enterpriseAPN de dados de Banda Larga Móvel para a interface
fornecida.
Sintaxe
PowerShell
set enterpriseapnparams [interface=]<string> [allowusercontrol=]yes|no|nc

[allowuserview=]yes|no|nc [profileaction=]add|delete|modify|nc
Parâmetros

allowusercontrol Um dos seguintes valores:

Necessária
yes: permite ao usuário controlar enterpriseAPN.
no: não permite ao usuário controlar enterpriseAPN.
nc: sem alteração.
allowuserview Um dos seguintes valores:

Necessária
yes: permite ao usuário visualizar enterpriseAPN.
no: não permite ao usuário visualizar enterpriseAPN.

profileaction Um dos seguintes valores:

Necessária
add: um perfil enterpriseAPN é adicionado.
delete: um perfil enterpriseAPN é excluído.
modify: um perfil enterpriseAPN é modificado.
Exemplo
PowerShell
set enterpriseapnparams interface="Cellular" profileset=mms mode=yes
highestconncategory
Define a categoria de conexão mais alta de dados de Banda Larga Móvel para a
Sintaxe
PowerShell
set highestconncategory [interface=]<string>

[highestcc=]admim|user|operator|device
Parâmetros

highestcc Um dos seguintes valores:

Necessária
admin: perfis provisionados pelo administrador.
user: perfis provisionados pelo usuário.
operator: perfis provisionados pelo operador.
device: perfis provisionados pelo dispositivo.
Exemplo
PowerShell
set highestconncategory interface="Cellular" highestcc=operator
powerstate
Ativa ou desativa o rádio de Banda Larga Móvel para a interface fornecida.
Sintaxe
PowerShell
set powerstate [interface=]<string> [state=]on|off
Parâmetros

state Um dos seguintes valores:

Necessária
on: ligar o transceptor de rádio.
off: desligar o transceptador de rádio.
Exemplo
PowerShell
set powerstate interface="Cellular" state=on
profileparameter
Definir parâmetros em um Perfil de Rede de Banda Larga Móvel.
Sintaxe
PowerShell
set profileparameter [name=]<string> [[interface=]<string>]

[[cost]=default|unrestricted|fixed|variable]
Parâmetros
name Nome do perfil a ser modificado. Se a interface for especificada, Necessária

somente o perfil nessa interface será modificado.
interface Nome da interface. É um dos nomes de interface mostrados pelo Opcional

cost Custo associado ao perfil. Opcional
Comentários
Pelo menos um parâmetro entre o nome da interface e o custo deve ser especificado.
Exemplo
PowerShell
set profileparameter name="profile 1" cost=default
slotmapping
Define o mapeamento de slot de modem de Banda Larga Móvel para a interface
fornecida.
Sintaxe
PowerShell
set slotmapping [interface=]<string> [slotindex=]<integer>
Parâmetros

slotindex Índice do slot a ser definido. Necessária
Exemplo
PowerShell
set slotmapping interface="Cellular" slotindex=1
tracing
Habilitar ou desabilitar o rastreamento.
Sintaxe
PowerShell
set tracing [mode=]yes|no
Parâmetros

Necessária
yes: habilita o rastreamento para Banda Larga Móvel.
não: desabilita o rastreamento para Banda Larga Móvel.
Exemplo
PowerShell
set tracing mode=yes
show
Exibe informações de rede de banda larga móvel.
Os comandos netsh mbn show disponíveis são:
acstate
capability
connection
dataenablement
dataroamcontrol
dmprofiles
enterpriseapnparams
highestconncategory
homeprovider
interfaces
netlteattachinfo
pin
pinlist
preferredproviders
profiles
profilestate
provisionedcontexts
purpose
radio
readyinfo
signal
slotmapping
slotstatus
smsconfig
tracing
visibleproviders
acstate
Mostra o estado de conexão automática de dados de Banda Larga Móvel para a
Sintaxe
PowerShell
show acstate [interface=]<string>
Parâmetros

Exemplo
PowerShell
show acstate interface="Cellular"
capability
Mostra as informações de capacidade da interface para a interface fornecida.
Sintaxe
PowerShell
show capability [interface=]<string>
Parâmetros

Exemplo
PowerShell
show capability interface="Cellular"
connection
Mostra as informações de conexão atuais para a interface fornecida.
Sintaxe
PowerShell
show connection [interface=]<string>
Parâmetros

Exemplo
PowerShell
show connection interface="Cellular"
dataenablement
Mostra o estado de habilitação de dados de Banda Larga Móvel para a interface
fornecida.
Sintaxe
PowerShell
show dataenablement [interface=]<string>
Parâmetros

Exemplo
PowerShell
show dataenablement interface="Cellular"
dataroamcontrol
Mostra o estado de controle de roaming de dados de Banda Larga Móvel para a
Sintaxe
PowerShell
show dataroamcontrol [interface=]<string>
Parâmetros

Exemplo
PowerShell
show dataroamcontrol interface="Cellular"
dmprofiles
Mostra uma lista de perfis de Configuração de DM configurados no sistema.
Sintaxe
PowerShell
show dmprofiles [[name=]<string>] [[interface=]<string>]
Parâmetros
name Nome do perfil a ser exibido. Opcional

Comentários
Mostra os dados do perfil ou lista os perfis no sistema.
Se o nome do perfil for fornecido, o conteúdo do perfil será exibido. Caso contrário, os
perfis serão listados para a interface.
Se o nome da interface for fornecido, somente o perfil especificado na interface

fornecida será listado. Caso contrário, o primeiro perfil correspondente será exibido.
Exemplo
PowerShell
show dmprofiles name="profile 1" interface="Cellular"
show dmprofiles name="profile 2"
show dmprofiles
enterpriseapnparams
Mostra os parâmetros enterpriseAPN de dados de Banda Larga Móvel para a interface
fornecida.
Sintaxe
PowerShell
show enterpriseapnparams [interface=]<string>
Parâmetros

Exemplo
PowerShell
show enterpriseapnparams interface="Cellular"
highestconncategory
Mostra a categoria de conexão mais alta de Dados de Banda Larga Móvel para a
Sintaxe
PowerShell
show highestconncategory [interface=]<string>
Parâmetros

Exemplo
PowerShell
show highestconncategory interface="Cellular"
homeprovider
Mostra as informações do provedor de residencial para a interface fornecida.
Sintaxe
PowerShell
show homeprovider [interface=]<string>
Parâmetros

Exemplo
PowerShell
show homeprovider interface="Cellular"
interfaces
Mostra uma lista de interfaces de Banda Larga Móvel no sistema. Não há parâmetros
para esse comando.
Sintaxe
PowerShell
show interfaces
netlteattachinfo
Mostra as informações de anexação LTE de rede de Banda Larga Móvel para a interface
fornecida.
Sintaxe
PowerShell
show netlteattachinfo [interface=]<string>
Parâmetros

Exemplo
PowerShell
show netlteattachinfo interface="Cellular"
pin
Mostra as informações de marcador para a interface fornecida.
Sintaxe
PowerShell
show pin [interface=]<string>
Parâmetros

Exemplo
PowerShell
show pin interface="Cellular"
pinlist
Mostra as informações de lista de marcadores para a interface fornecida.
Sintaxe
PowerShell
show pinlist [interface=]<string>

Parâmetros

Exemplo
PowerShell
show pinlist interface="Cellular"
preferredproviders
Mostra a lista de provedores preferenciais para a interface fornecida.
Sintaxe
PowerShell
show preferredproviders [interface=]<string>
Parâmetros

Exemplo
PowerShell
show preferredproviders interface="Cellular"
profiles
Mostra uma lista de perfis configurados no sistema.
Sintaxe
PowerShell
show profiles [[name=]<string>] [[interface=]<string>] [[purpose=]<string>]
Parâmetros
name Nome do perfil a ser exibido. Opcional

purpose Finalidade Opcional
Comentários
Se o nome do perfil for fornecido, o conteúdo do perfil será exibido. Caso contrário, os
perfis serão listados para a interface.
Se o nome da interface for fornecido, somente o perfil especificado na interface

fornecida será listado. Caso contrário, o primeiro perfil correspondente será exibido.
Se a finalidade for fornecida, somente os perfis com o GUID de finalidade

correspondente serão exibidos. Caso contrário, os perfis não serão filtrados por
finalidade. A cadeia de caracteres pode ser um GUID com chaves ou uma das seguintes
cadeias de caracteres: internet, supl, mms, ims ou allhost.
Exemplo
PowerShell
show profiles interface="Cellular" purpose="{00000000-0000-0000-0000-

000000000000}"
show profiles name="profile 1" interface="Cellular"
show profiles name="profile 2"
show profiles
profilestate
Mostra o estado de um perfil de Banda Larga Móvel para a interface fornecida.
Sintaxe
PowerShell
show profilestate [interface=]<string> [name=]<string>
Parâmetros

name Nome do perfil. É o nome do perfil que tem o estado a ser mostrado. Necessária
Exemplo
PowerShell
show profilestate interface="Cellular" name="myProfileName"
provisionedcontexts
Mostra as informações de contextos provisionadas para a interface fornecida.
Sintaxe
PowerShell
show provisionedcontexts [interface=]<string>
Parâmetros

Exemplo
PowerShell
show provisionedcontexts interface="Cellular"
purpose
Mostra os GUIDs do grupo de finalidade que podem ser usados para filtrar perfis no
dispositivo. Não há parâmetros para esse comando.
Sintaxe
PowerShell
show purpose
radio
Mostra as informações de estado de rádio para a interface fornecida.
Sintaxe
PowerShell
show radio [interface=]<string>
Parâmetros

Exemplo
PowerShell
show radio interface="Cellular"
readyinfo
Mostra as informações prontas para a interface fornecida.
Sintaxe
PowerShell
show readyinfo [interface=]<string>
Parâmetros

Exemplo
PowerShell
show readyinfo interface="Cellular"
signal
Mostra as informações de sinal para a interface fornecida.
Sintaxe
PowerShell
show signal [interface=]<string>
Parâmetros

Exemplo
PowerShell
show signal interface="Cellular"
slotmapping
Mostra o mapeamento de slot de modem de Banda Larga Móvel para a interface
fornecida.
Sintaxe
PowerShell
show slotmapping [interface=]<string>
Parâmetros


Exemplo
PowerShell
show slotmapping interface="Cellular"
slotstatus
Mostra o status do slot de modem de Banda Larga Móvel para a interface fornecida.
Sintaxe
PowerShell
show slotstatus [interface=]<string>
Parâmetros

Exemplo
PowerShell
show slotstatus interface="Cellular"
smsconfig
Mostra as informações de configuração do SMS para a interface fornecida.
Sintaxe
PowerShell
show smsconfig [interface=]<string>
Parâmetros

Exemplo
PowerShell
show smsconfig interface="Cellular"
tracing
Mostra se o rastreamento de Banda Larga Móvel está habilitado ou desabilitado.
Sintaxe
PowerShell
show tracing
visibleproviders
Mostra a lista de provedores visíveis para a interface fornecida.
Sintaxe
PowerShell
show visibleproviders [interface=]<string>
Parâmetros

Exemplo
PowerShell
show visibleproviders interface="Cellular"
test
Executa testes para uma área de recurso específica enquanto coleta logs.
Sintaxe
test [feature=<feature area>] [testPath=<path>] [taefPath=<path>] [param=

<test input params>]
Parâmetros
Marca Valor Opcional?
feature Uma área de recursos das áreas de Obrigatório

recursos compatíveis listadas abaixo
testpath Demarcador que contém os binários de Opcional se o servidor HLK estiver

teste instalado
taefpath Demarcador que contém os binários TAEF Opcional se o servidor HLK estiver
instalado
param Parâmetros separados por vírgulas, a Necessários para determinadas áreas de

serem usados para os testes recursos, opcionais para outros
Comentários
As áreas de recursos compatíveis são:
conectividade
potência
radio
esim
sms
dssa
lte
bringup
Alguns testes exigem que parâmetros adicionais sejam fornecidos no campo param .
Os
parâmetros necessários para os recursos estão listados abaixo.
connectivity: AccessString, UserName (se aplicável), Senha (se aplicável)
radio: AccessString, UserName (se aplicável), Senha (se aplicável)
esim: ActivationCode
bringup: AccessString, UserName (se aplicável), Senha (se aplicável)
Exemplos
test feature=connectivity param="AccessString=internet"
test feature=lte testpath="C:\\data\\test\\bin"

taefpath="C:\\data\\test\\bin"
test feature=lte
Ajuste do desempenho de subsistemas

de rede
Você pode usar este tópico para uma visão geral do subsistema de rede e para links
para outros tópicos neste guia.
７ Observação
Além deste tópico, as seções a seguir deste guia fornecem recomendações de

ajuste de desempenho para dispositivos de rede e a pilha de rede.
Escolhendo um adaptador de rede

Configurar a ordem das interfaces de rede
Adaptadores de rede de ajuste de desempenho
Contadores de desempenho relacionados à rede
Ferramentas de desempenho para cargas de trabalho de rede
O ajuste de desempenho do subsistema de rede, especialmente para cargas de trabalho

com uso intensivo de rede, pode envolver cada camada da arquitetura de rede, que
também é chamada de pilha de rede. Essas camadas são amplamente divididas nas
seções a seguir.
1. Interface de rede. Essa é a camada mais baixa da pilha de rede e contém o driver
de rede que se comunica diretamente com o adaptador de rede.
2. NDIS (Especificação da Interface do Driver de Rede). O NDIS expõe interfaces

para o driver abaixo dela e para as camadas acima dela, como a Pilha de
Protocolos.
3. Pilha de Protocolos. A pilha de protocolos implementa protocolos como TCP/IP e

UDP/IP. Essas camadas expõem a interface da camada de transporte para camadas
acima delas.
4. Drivers do sistema. Normalmente, são clientes que usam uma interface TDX
(extensão de dados de transporte) ou do Kernel winsock (WSK) para expor
interfaces a aplicativos do modo de usuário. A interface do WSK foi introduzida no
Windows Server 2008 e Windows ® Vista e é exposta por AFD.sys. A interface
melhora o desempenho eliminando a alternância entre o modo de usuário e o
modo kernel.
5. Aplicativos do modo de usuário. Normalmente, são soluções da Microsoft ou

aplicativos personalizados.
A tabela a seguir fornece uma ilustração vertical das camadas da pilha de rede,
incluindo exemplos de itens executados em cada camada.
Escolhendo um adaptador de rede
Você pode usar este tópico para aprender alguns dos recursos de adaptadores de rede
que podem afetar suas escolhas de compra.
Aplicativos com uso intensivo de rede exigem adaptadores de rede de alto

desempenho. Esta seção explora algumas considerações para escolher adaptadores de
rede, bem como como definir diferentes configurações de adaptador de rede para obter
o melhor desempenho de rede.
 Dica
Você pode definir as configurações do adaptador de rede usando Windows

PowerShell. Para obter mais informações, consulte Cmdlets do Adaptador de Rede
no Windows PowerShell.
Capacidades de descarregamento
Descarregar tarefas da CPU (unidade de processamento central) para o adaptador de
rede pode reduzir o uso da CPU no servidor, o que melhora o desempenho geral do
sistema.
A pilha de rede em produtos da Microsoft pode descarregar uma ou mais tarefas para
um adaptador de rede se você selecionar um adaptador de rede que tenha os recursos
de descarregamento apropriados. A tabela a seguir fornece uma breve visão geral dos
diferentes recursos de descarregamento disponíveis no Windows Server 2016.
Tipo de Descrição
descarregamento
Cálculo de soma A pilha de rede pode descarregar o cálculo e a validação de somas de

de verificação verificação TCP (Protocolo de Controle de Transmissão) nos caminhos de
para TCP código de envio e recebimento. Ele também pode descarregar o cálculo e a
validação de somas de verificação IPv4 e IPv6 nos caminhos de código de
envio e recebimento.
Tipo de Descrição
descarregamento

de verificação verificação UDP (User Datagram Protocol) em caminhos de código de envio
para UDP e recebimento.

de verificação verificação IPv4 nos caminhos de código de envio e recebimento.
para IPv4

de verificação verificação IPv6 nos caminhos de código de envio e recebimento.
para IPv6
Segmentação de A camada de transporte TCP/IP dá suporte ao LSOv2 (Descarregamento de

pacotes TCP Envio Grande v2). Com lSOv2, a camada de transporte TCP/IP pode
grandes descarregar a segmentação de pacotes TCP grandes para o adaptador de
rede.
RSS (Receive Side O RSS é uma tecnologia de driver de rede que permite a distribuição
Scaling) eficiente do processamento de recebimento de rede em várias CPUs em
sistemas multiprocessadores. Mais detalhes sobre o RSS são fornecidos
posteriormente neste tópico.
Receive Segment O RSC é a capacidade de agrupar pacotes para minimizar o processamento

Coalescing (RSC) de cabeçalho necessário para que o host seja executado. Um máximo de 64
KB de carga recebida pode ser agrupado em um único pacote maior para
processamento. Mais detalhes sobre o RSC são fornecidos posteriormente
neste tópico.
Receive Side Scaling

Windows Server 2016, Windows Server 2012, Windows Server 2012 R2, Windows Server
2008 R2 e Windows Server 2008 dão suporte ao RSS (Receive Side Scaling).
Alguns servidores são configurados com vários processadores lógicos que

compartilham recursos de hardware (como um núcleo físico) e que são tratados como
pares SMT (Multi-Threading Simultâneos). A Intel Hyper-Threading Technology é um
exemplo. O RSS direciona o processamento de rede para até um processador lógico por
núcleo. Por exemplo, em um servidor com Processadores lógicos Intel Hyper-Threading,
4 núcleos e 8, o RSS usa no máximo 4 processadores lógicos para processamento de
rede.
O RSS distribui pacotes de E/S de rede de entrada entre processadores lógicos para que
os pacotes que pertencem à mesma conexão TCP sejam processados no mesmo
processador lógico, o que preserva a ordenação.
O RSS também balancea a carga do tráfego unicast e multicast UDP e roteia fluxos
relacionados (que são determinados por hash dos endereços de origem e destino) para
o mesmo processador lógico, preservando a ordem de chegadas relacionadas. Isso
ajuda a melhorar a escalabilidade e o desempenho para cenários intensivos de
recebimento para servidores que têm menos adaptadores de rede do que
processadores lógicos qualificados.
Configurando o RSS
Em Windows Server 2016, você pode configurar o RSS usando Windows PowerShell
cmdlets e perfis RSS.
Você pode definir perfis RSS usando o parâmetro –Profile do cmdlet Set-NetAdapterRss
Windows PowerShell.
Windows PowerShell comandos para a configuração do RSS
Os cmdlets a seguir permitem ver e modificar parâmetros RSS por adaptador de rede.
７ Observação
Para obter uma referência de comando detalhada para cada cmdlet, incluindo
sintaxe e parâmetros, você pode clicar nos links a seguir. Além disso, você pode
passar o nome do cmdlet para Obter Ajuda no prompt de Windows PowerShell
para obter detalhes sobre cada comando.
Disable-NetAdapterRss. Esse comando desabilita o RSS no adaptador de rede que

você especificar.
Enable-NetAdapterRss. Esse comando habilita o RSS no adaptador de rede que

você especificar.
Get-NetAdapterRss. Este comando recupera as propriedades RSS do adaptador de

rede que você especificar.
Set-NetAdapterRss. Esse comando define as propriedades RSS no adaptador de

rede que você especificar.
Perfis RSS
Você pode usar o parâmetro –Profile do cmdlet Set-NetAdapterRss para especificar

quais processadores lógicos são atribuídos a qual adaptador de rede. Os valores
disponíveis para este parâmetro são:
Mais perto. Os números lógicos do processador que estão próximos ao

processador RSS base do adaptador de rede são preferenciais. Com esse perfil, o
sistema operacional pode reequilibrar processadores lógicos dinamicamente com
base na carga.
ClosestStatic. Os números do processador lógico próximos ao processador RSS

base do adaptador de rede são preferenciais. Com esse perfil, o sistema
operacional não reequilibra os processadores lógicos dinamicamente com base na
carga.
NUMA. Os números do processador lógico geralmente são selecionados em

diferentes nós NUMA para distribuir a carga. Com esse perfil, o sistema
operacional pode reequilibrar processadores lógicos dinamicamente com base na
carga.
NUMAStatic. Esse é o perfil padrão. Os números do processador lógico

geralmente são selecionados em diferentes nós NUMA para distribuir a carga.
Com esse perfil, o sistema operacional não reequilibrará os processadores lógicos
dinamicamente com base na carga.
Conservador. O RSS usa o menor número possível de processadores para

sustentar a carga. Essa opção ajuda a reduzir o número de interrupções.
Dependendo do cenário e das características da carga de trabalho, você também pode

usar outros parâmetros do cmdlet Set-NetAdapterRss Windows PowerShell para
especificar o seguinte:
Em uma base de adaptador por rede, quantos processadores lógicos podem ser
usados para o RSS.
O deslocamento inicial para o intervalo de processadores lógicos.
O nó do qual o adaptador de rede aloca memória.
A seguir estão os parâmetros de Set-NetAdapterRss adicionais que você pode usar

para configurar o RSS:
７ Observação
Na sintaxe de exemplo para cada parâmetro abaixo, o nome do adaptador de rede

Ethernet é usado como um valor de exemplo para o parâmetro –Name do
comando Set-NetAdapterRss . Ao executar o cmdlet, verifique se o nome do
adaptador de rede que você usa é apropriado para seu ambiente.
* MaxProcessors: define o número máximo de processadores RSS a serem usados.
Isso garante que o tráfego do aplicativo esteja associado a um número máximo de
processadores em uma determinada interface. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –MaxProcessors <value>
* BaseProcessorGroup: define o grupo de processadores base de um nó NUMA.

Isso afeta a matriz de processadores usada pelo RSS. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –BaseProcessorGroup <value>
* MaxProcessorGroup: define o grupo máximo de processadores de um nó

NUMA. Isso afeta a matriz de processadores usada pelo RSS. Definir isso
restringiria um grupo máximo de processadores para que o balanceamento de
carga seja alinhado em um grupo k. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –MaxProcessorGroup <value>
* BaseProcessorNumber: define o número de processador base de um nó NUMA.

Isso afeta a matriz de processadores usada pelo RSS. Isso permite particionar
processadores entre adaptadores de rede. Este é o primeiro processador lógico no
intervalo de processadores RSS atribuídos a cada adaptador. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –BaseProcessorNumber <Byte Value>
* NumaNode: o nó NUMA do qual cada adaptador de rede pode alocar memória.

Isso pode estar dentro de um grupo k ou de grupos K diferentes. Exemplo de
sintaxe:
Set-NetAdapterRss –Name "Ethernet" –NumaNodeID <value>
* NumberofReceiveQueues: se seus processadores lógicos parecem estar

subutilizados para receber tráfego (por exemplo, conforme exibido no Gerenciador
de Tarefas), você pode tentar aumentar o número de filas RSS do padrão de 2 para
o máximo com suporte do adaptador de rede. O adaptador de rede pode ter
opções para alterar o número de filas RSS como parte do driver. Exemplo de
sintaxe:
Set-NetAdapterRss –Name "Ethernet" –NumberOfReceiveQueues <value>
Para obter mais informações, clique no link a seguir para baixar a Rede Escalonável:
Eliminando o Gargalo de Processamento de Recebimento – Apresentando o RSS no
formato word.
Noções básicas sobre o desempenho do RSS
Ajustar o RSS requer entender a configuração e a lógica de balanceamento de carga.
Para verificar se as configurações do RSS entraram em vigor, você pode examinar a
saída ao executar o cmdlet Get-NetAdapterRss Windows PowerShell. Veja a seguir a
saída de exemplo desse cmdlet.
PS C:\Users\Administrator> get-netadapterrss
Name : testnic 2
InterfaceDescription : Broadcom BCM5708C NetXtreme II GigE (NDIS

VBD Client) #66
Enabled : True
NumberOfReceiveQueues : 2
Profile : NUMAStatic
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:15
MaxProcessors : 8
IndirectionTable: [Group:Number]:
0:0 0:4 0:0 0:4 0:0 0:4 0:0 0:4
(# indirection table entries are a power of 2 and based on # of processors)
0:0 0:4 0:0 0:4 0:0 0:4 0:0

0:4
Além de ecoar parâmetros que foram definidos, o aspecto principal da saída é a saída
da tabela de indireção. A tabela de indireção exibe os buckets de tabela de hash usados
para distribuir o tráfego de entrada. Neste exemplo, a notação n:c designa o par de
índice Numa K-Group:CPU usado para direcionar o tráfego de entrada. Vemos
exatamente duas entradas exclusivas (0:0 e 0:4), que representam k-group 0/cpu0 e k-
group 0/cpu 4, respectivamente.
Há apenas um grupo k para esse sistema (k-group 0) e um n (em que n <= 128) entrada
de tabela de indireção. Como o número de filas de recebimento é definido como 2,
apenas dois processadores (0:0, 0:4) são escolhidos – embora o máximo de
processadores esteja definido como 8. Na verdade, a tabela de indireção está hashando
o tráfego de entrada para usar apenas 2 CPUs das 8 disponíveis.
Para utilizar totalmente as CPUs, o número de Filas de Recebimento do RSS deve ser
igual ou maior que os Processadores Máximos. No exemplo anterior, a Fila de
Recebimento deve ser definida como 8 ou maior.
Agrupamento NIC e RSS
O RSS pode ser habilitado em um adaptador de rede que é combinado com outra placa
de interface de rede usando Agrupamento NIC. Nesse cenário, somente o adaptador de
rede física subjacente pode ser configurado para usar o RSS. Um usuário não pode
definir cmdlets RSS no adaptador de rede em equipe.
Receive Segment Coalescing (RSC)

A RSC (Associação de Segmentos de Recebimento) ajuda o desempenho reduzindo o
número de cabeçalhos IP processados para uma determinada quantidade de dados
recebidos. Ele deve ser usado para ajudar a dimensionar o desempenho dos dados
recebidos agrupando (ou unindo) os pacotes menores em unidades maiores.
Essa abordagem pode afetar a latência com benefícios vistos principalmente em ganhos
de taxa de transferência. É recomendável aumentar a taxa de transferência para cargas
de trabalho pesadas recebidas. Considere implantar adaptadores de rede que dão
suporte ao RSC.
Nesses adaptadores de rede, verifique se a RSC está ativada (essa é a configuração

padrão), a menos que você tenha cargas de trabalho específicas (por exemplo, baixa
latência, rede de baixa taxa de transferência) que mostram o benefício de RSC estar
desativado.
Noções básicas sobre o diagnóstico de RSC

Você pode diagnosticar o RSC usando os cmdlets Windows PowerShell Get-
NetAdapterRsc e Get-NetAdapterStatistics.
Veja a seguir a saída de exemplo quando você executa o cmdlet Get-NetAdapterRsc.
PS C:\Users\Administrator> Get-NetAdapterRsc
Name IPv4Enabled IPv6Enabled IPv4Operational

IPv6Operational IPv4FailureReason IPv6Failure
Reason
---- ----------- ----------- --------------- ---

------------ ----------------- ------------
Ethernet True False True

False NoFailure NicProperties
O cmdlet Get mostra se o RSC está habilitado na interface e se o TCP permite que o RSC
esteja em um estado operacional. O motivo da falha fornece detalhes sobre a falha em
habilitar o RSC nessa interface.
No cenário anterior, o IPv4 RSC tem suporte e está operacional na interface. Para
entender as falhas de diagnóstico, é possível ver os bytes unidos ou exceções causadas.
Isso fornece uma indicação dos problemas de coalescing.
Veja a seguir a saída de exemplo quando você executa o cmdlet Get-

NetAdapterStatistics.
PS C:\Users\Administrator> $x = Get-NetAdapterStatistics "myAdapter"
PS C:\Users\Administrator> $x.rscstatistics
CoalescedBytes : 0
CoalescedPackets : 0
CoalescingEvents : 0
CoalescingExceptions : 0
RSC e Virtualização
O RSC só tem suporte no host físico quando o adaptador de rede do host não está
associado ao Comutador Virtual do Hyper-V. O RSC é desabilitado pelo sistema
operacional quando o host está associado ao Comutador Virtual hyper-V. Além disso, as
máquinas virtuais não recebem o benefício do RSC porque os adaptadores de rede
virtual não dão suporte ao RSC.
O RSC pode ser habilitado para uma máquina virtual quando a SR-IOV (Virtualização de
Entrada/Saída) de Raiz Única estiver habilitada. Nesse caso, as funções virtuais dão
suporte à funcionalidade RSC; portanto, as máquinas virtuais também recebem o
benefício do RSC.
Recursos do Adaptador de Rede

Alguns adaptadores de rede gerenciam ativamente seus recursos para obter um
desempenho ideal. Vários adaptadores de rede permitem que você configure
manualmente os recursos usando a guia Rede Avançada para o adaptador. Para esses
adaptadores, você pode definir os valores de vários parâmetros, incluindo o número de
buffers de recebimento e o envio de buffers.
A configuração de recursos do adaptador de rede é simplificada pelo uso dos cmdlets
Windows PowerShell a seguir.
Get-NetAdapterAdvancedProperty
Set-NetAdapterAdvancedProperty
Enable-NetAdapter
Enable-NetAdapterBinding
Enable-NetAdapterChecksumOffload
Enable-NetAdapterIPSecOffload
Enable-NetAdapterLso
Enable-NetAdapterPowerManagement
Enable-NetAdapterQos
Enable-NetAdapterRDMA
Enable-NetAdapterSriov
Para obter mais informações, consulte Cmdlets do Adaptador de Rede no Windows

PowerShell.
Para obter links para todos os tópicos neste guia, consulte Ajuste de Desempenho do
Subsistema de Rede.
Configurar a ordem das interfaces de
rede
No Windows Server 2016 e Windows 10, você pode usar a métrica de interface para
configurar a ordem dos interfaces de rede.
Isso é diferente das versões anteriores do Windows e do Windows Server, que

permitiam configurar a ordem de associação dos adaptadores de rede usando a
interface do usuário ou os comandos INetCfgComponentBindings::MoveBefore e
INetCfgComponentBindings::MoveAfter. Esses dois métodos para ordenar interfaces
de rede não estão disponíveis em Windows Server 2016 e Windows 10.
Em vez disso, você pode usar o novo método para definir a ordem enumerada de
adaptadores de rede configurando a métrica de interface de cada adaptador. Você pode
configurar a métrica de interface usando o comando Set-NetIPInterface Windows
PowerShell interface.
Quando as rotas de tráfego de rede são escolhidas e você configura o parâmetro

InterfaceMetric do comando Set-NetIPInterface , a métrica geral usada para determinar
a preferência da interface é a soma da métrica de rota e da métrica de interface.
Normalmente, a métrica de interface dá preferência a uma interface específica, como
usar com fio se o com fio e o sem fio estão disponíveis.
O exemplo Windows PowerShell comando a seguir mostra o uso desse parâmetro.
PowerShell
Set-NetIPInterface -InterfaceIndex 12 -InterfaceMetric 15
A ordem na qual os adaptadores aparecem em uma lista é determinada pela métrica da

interface IPv4 ou IPv6. Para obter mais informações, consulte Função
GetAdaptersAddresses.
Para ver links para todos os tópicos neste guia, consulte Ajuste de desempenho do
subsistema de rede.
Adaptadores de rede para ajuste do
desempenho
Use as informações neste tópico para ajustar os adaptadores de rede de desempenho

para computadores que estão executando Windows Server 2016 e versões posteriores.
Se os adaptadores de rede fornecerem opções de ajuste, você poderá usar essas opções
para otimizar a produtividade de rede e o uso de recursos.
As configurações de ajuste corretas para os adaptadores de rede dependem das

seguintes variáveis:
O adaptador de rede e seu conjunto de recursos

O tipo de carga de trabalho que o servidor executa
Os recursos de hardware e software do servidor
Seus objetivos de desempenho para o servidor
As seções a seguir descrevem algumas de suas opções de ajuste de desempenho.
Habilitando recursos de descarregamento

O ajuste nos recursos de descarregamento do adaptador de rede normalmente é
benéfico. No entanto, o adaptador de rede pode não ser poderoso o suficiente para
lidar com os recursos de descarregagem com alta taxa de transferência.
） Importante
Não use os recursos de descarregador de tarefas IPsec oudescarregado de

10000001.000001.100001.000001.100001.100 Essas tecnologias foram preterida no
Windows Server 2016 e podem afetar negativamente o desempenho do servidor e
da rede. Além disso, essas tecnologias podem não ter suporte da Microsoft no
futuro.
Por exemplo, considere um adaptador de rede que tenha recursos de hardware

limitados.
Nesse caso, a habilitação de recursos de descarregamento de segmentação
pode reduzir a taxa de transferência máxima sustentável do adaptador. No entanto, se a
taxa de transferência reduzida for aceitável, você deverá habilitar os recursos de
descarregamento de segmentação.
７ Observação
Alguns adaptadores de rede exigem que você habilita os recursos de

descarregagem independentemente para os caminhos de envio e recebimento.
Habilitando o RSS (receive-side scaling) para

servidores Web
O RSS pode melhorar a escalabilidade e o desempenho da Web quando há menos
adaptadores de rede do que processadores lógicos no servidor. Quando todo o tráfego
da Web está passando pelos adaptadores de rede com capacidade para RSS, o servidor
pode processar solicitações da Web de entrada de diferentes conexões
simultaneamente entre diferentes CPUs.
） Importante
Evite usar adaptadores de rede não RSS e adaptadores de rede com capacidade
para RSS no mesmo servidor. Devido à lógica de distribuição de carga no RSS e no
PROTOCOLO HTTP, o desempenho poderá ser gravemente degradado se um
adaptador de rede não com capacidade de RSS aceitar o tráfego da Web em um
servidor que tenha um ou mais adaptadores de rede com capacidade para RSS.
Nesse caso, você deve usar adaptadores de rede habilitados para RSS ou
desabilitar RSS na guia Propriedades Avançadas das propriedades do adaptador
de rede.
Para determinar se um adaptador de rede está habilitado para RSS, você pode
visualizar as informações RSS na guia Propriedades Avançadas das propriedades
do adaptador de rede.
Perfis RSS e filas RSS

O perfil predefinido do RSS padrão é NUMAStatic, que é diferente do padrão que as
versões anteriores do Windows usadas. Antes de começar a usar perfis RSS, revise os
perfis disponíveis para entender quando eles são benéficos e como eles se aplicam ao
seu ambiente de rede e hardware.
Por exemplo, se você abrir o Gerenciador de Tarefas e analisar os processadores lógicos
em seu servidor e eles pareceram estar subutilizados para receber tráfego, você pode
tentar aumentar o número de filas RSS do padrão de duas para o máximo compatível
com o adaptador de rede. Seu adaptador de rede pode ter opções para alterar o
número de filas RSS como parte do driver.
Aumentando os recursos do adaptador de rede

Para adaptadores de rede que permitem configurar manualmente recursos como
buffers de recebimento e envio, você deve aumentar os recursos alocados.
Alguns adaptadores de rede configuram seus buffers de recebimento como baixos para
preservar a memória alocada do host. O valor baixo resulta em pacotes descartados e
desempenho reduzido. Portanto, para cenários de recebimento intenso, recomendamos
aumentar o valor do buffer de recebimento para o máximo.
７ Observação
Se um adaptador de rede não expõe a configuração manual de recursos, ele

configura dinamicamente os recursos ou os recursos são definidos como um valor
fixo que não pode ser alterado.
Habilitando a moderação de interrupção

Para controlar a moderação de interrupção, alguns adaptadores de rede expõem
diferentes níveis de moderação de interrupção, diferentes parâmetros de conciliação de
buffer (às vezes separadamente para enviar e receber buffers) ou ambos.
Você deve considerar a moderação de interrupção para cargas de trabalho vinculadas à

CPU. Ao usar a moderação de interrupção, considere a diferença entre a economia e a
latência da CPU do host em comparação com o aumento da economia de CPU do host
devido a mais interrupções e menor latência. Se o adaptador de rede não executar a
moderação de interrupção, mas ele expor a avaliação de buffer, você poderá melhorar o
desempenho aumentando o número de buffers coalesced para permitir mais buffers por
envio ou recebimento.
Ajuste de desempenho para processamento de

pacotes de baixa latência
Muitos adaptadores de rede fornecem opções para otimizar a latência induzida pelo
sistema operacional. A latência é o tempo decorrido entre o momento em que o driver
de rede processa um pacote recebido e o driver de rede envia o pacote de volta. Esse
tempo geralmente é medido em microssegundos. Para comparar, o tempo de
transmissão nas transmissões de pacote em longas distâncias geralmente é medido em
milissegundos (uma ordem de magnitude maior). Esse ajuste não reduzirá o tempo que
um pacote gasta em trânsito.
A seguir estão algumas sugestões de ajuste no desempenho para redes sensíveis a

microssegundo.
Defina o BIOS do computador para Alto Desempenho, com estados C

desabilitados. Entretanto, observe que isso depende do sistema e do BIOS, alguns
sistemas fornecerão maior desempenho se o sistema operacional controlar o
gerenciamento de energia. Você pode verificar e ajustar suas configurações de
gerenciamento de energia Configurações ou usando o comando powercfg. Para
obter mais informações, consulte Powercfg Command-Line Opções.
Defina o perfil de gerenciamento de energia do sistema operacional para Sistema

de alto desempenho.
７ Observação
Essa configuração não funcionará corretamente se o BIOS do sistema tiver

sido definido para desabilitar o controle do sistema operacional do
gerenciamento de energia.
Habilitar descarregados estáticos. Por exemplo, habilita as configurações de

Verificações UDP, TCP Checksums e LSO (Envio de Descarregado Grande).
Se o tráfego for transmitido por vários fluxos, como ao receber tráfego multicast
de alto volume, habilita o RSS.
Desabilite a configuração Moderação de interrupção dos drivers da placa de rede

que requerem a menor latência possível. Lembre-se de que essa configuração
pode usar mais tempo de CPU e representa uma troca.
Manipule as interrupções do adaptador de rede e DPCs em um processador de

núcleo que compartilha cache de CPU com o núcleo que está sendo usado pelo
programa (thread de usuário) que está lidando com o pacote. O ajuste na
afinidade da CPU pode ser usado para direcionar um processo para determinados
processadores lógicos em conjunto com a configuração de RSS com essa
finalidade. O uso do mesmo núcleo para interrupção, DPC e thread de modo de
usuário revela piora no desempenho na medida em que a carga aumenta, porque
o ISR, DPC e thread disputam o uso do núcleo.
Interrupções de gerenciamento do sistema

Muitos sistemas de hardware usam SMI (Interrupções de Gerenciamento do Sistema)
para uma variedade de funções de manutenção, como relatar erros de memória de ECC
(código de correção de erro), manter a compatibilidade de USB herdado, controlar o
ventilador e gerenciar configurações de energia controladas pelo BIOS.
O SMI é a interrupção de prioridade mais alta no sistema e coloca a CPU em um modo

de gerenciamento. Esse modo preempção de todas as outras atividades enquanto o SMI
executa uma rotina de serviço de interrupção, normalmente contida no BIOS.
Infelizmente, esse comportamento pode resultar em picos de latência de 100

microssegundos ou mais.
Se for necessário obter a menor latência, você deve solicitar uma versão do BIOS, junto
a seu fornecedor de hardware, que reduza as SMIs para o menor nível possível. Essas
versões do BIOS são frequentemente conhecidas como "BIOS de baixa latência" ou
"BIOS livre de SMI". Em alguns casos, não é possível que uma plataforma de hardware
elimine totalmente a atividade SMI porque ela é usada para controlar funções essenciais
(por exemplo, ventiladores de resfriamento).
７ Observação
O sistema operacional não pode controlar SMIs porque o processador lógico está
em execução em um modo de manutenção especial, o que impede a intervenção
do sistema operacional.
TCP de ajuste de desempenho

Você pode usar os itens a seguir para ajustar o desempenho do TCP.
Ajuste automático da janela de recebimento do TCP

No Windows Vista, no Windows Server 2008 e em versões posteriores do Windows, a
pilha de rede do Windows usa um recurso chamado nível de ajuste automático da
janela de recebimento TCP para negociar o tamanho da janela de recebimento do TCP.
Esse recurso pode negociar um tamanho de janela de recebimento definido para cada
comunicação TCP durante o Handshake TCP.
Em versões anteriores do Windows, a pilha de rede Windows usava uma janela de

recebimento de tamanho fixo (65.535 bytes) que limitava a taxa de transferência
potencial geral para conexões. A produtividade total acessível de conexões TCP pode
limitar cenários de uso de rede. O ajuste automático da janela de recebimento TCP
permite que esses cenários usem totalmente a rede.
Para uma janela de recebimento TCP que tem um tamanho específico, você pode usar a
equação a seguir para calcular a produtividade total de uma única conexão.
Produtividade total viável em bytesTamanho da janela de recebimento de TCP em

bytes * (1/latência de conexão em segundos)
Por exemplo, para uma conexão que tem uma latência de 10 ms, a produtividade total
que pode ser alcançada é de apenas 51 Mbps. Esse valor é razoável para uma
infraestrutura de rede corporativa grande. No entanto, usando o ajuste automático para
ajustar a janela de recebimento, a conexão pode atingir a taxa de linha completa de
uma conexão de 1 Gbps.
Alguns aplicativos definem o tamanho da janela de recebimento TCP. Se o aplicativo

não definir o tamanho da janela de recebimento, a velocidade do link determinará o
tamanho da seguinte forma:
Menos de 1 megabit por segundo (Mbps): 8 quilobytes (KB)

1 Mbps a 100 Mbps: 17 KB
100 Mbps a 10 gigabits por segundo (Gbps): 64 KB
10 Gbps ou mais rápido: 128 KB
Por exemplo, em um computador que tenha um adaptador de rede de 1 Gbps instalado,

o tamanho da janela deve ser de 64 KB.
Esse recurso também faz uso completo de outros recursos para melhorar o
desempenho da rede. Esses recursos incluem o restante das opções de TCP que são
definidas no RFC 1323 . usando esses recursos, computadores baseados em Windows
podem negociar tamanhos de janela de recepção TCP menores, mas são dimensionados
em um valor definido, dependendo da configuração. Esse comportamento é mais fácil
de lidar com dispositivos de rede.
７ Observação
Você pode enfrentar um problema em que o dispositivo de rede não está em
conformidade com a opção de dimensionamento de janela TCP, conforme
definido no RFC 1323 e, portanto, não dá suporte ao fator de escala. nesses
casos, consulte este KB 934430, a conectividade de rede falha quando você tenta
usar o Windows Vista atrás de um dispositivo de firewall ou entrar em contato
com a equipe de suporte para o fornecedor do dispositivo de rede.
Examinar e configurar o nível de ajuste automática da janela de

recepção TCP
você pode usar comandos netsh ou Windows PowerShell cmdlets para revisar ou
modificar o nível de ajuste da janela de recepção TCP.
７ Observação
ao contrário das versões do Windows que Windows 10 de dados ou Windows

Server 2019, você não pode mais usar o registro para configurar o tamanho da
janela de recepção TCP. Para obter mais informações sobre as configurações
preteridas, consulte parâmetros TCP preteridos.
７ Observação
Para obter informações detalhadas sobre os níveis de ajuste automática

disponíveis, consulte níveis de ajusteautomática.
Para usar o netsh para revisar ou modificar o nível de ajuste automática
Para examinar as configurações atuais, abra uma janela de prompt de comando e

execute o seguinte comando:
cmd
netsh interface tcp show global
A saída desse comando deve ser semelhante ao seguinte:
Querying active state...
TCP Global Parameters
-----
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
Fast Open : enabled
Fast Open Fallback : enabled
Pacing Profile : off
Para modificar a configuração, execute o seguinte comando no prompt de comando:
cmd
netsh interface tcp set global autotuninglevel=<Value>
７ Observação
No comando anterior, <<> representa o novo valor para o nível de ajuste

automático.
Para obter mais informações sobre esse comando, consulte comandos netsh para
protocolo de controle de transmissão de interface.
Para usar o PowerShell para revisar ou modificar o nível de ajuste automática
Para examinar as configurações atuais, abra uma janela do PowerShell e execute o

cmdlet a seguir.
PowerShell
Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal
A saída desse cmdlet deve ser semelhante ao seguinte.
SettingName AutoTuningLevelLocal
----------- --------------------
Automatic
InternetCustom Normal
DatacenterCustom Normal
Compat Normal
Datacenter Normal
Internet Normal
Para modificar a configuração, execute o seguinte cmdlet no prompt de comando do

PowerShell.
PowerShell
Set-NetTCPSetting -AutoTuningLevelLocal <Value>
７ Observação
No comando anterior, <<> representa o novo valor para o nível de ajuste

automático.
Para obter mais informações sobre esses cmdlets, consulte os seguintes artigos:
Get-NetTCPSetting
Set-NetTCPSetting
Níveis de ajuste automática

Você pode definir o ajuste automática da janela de recebimento para qualquer um dos
cinco níveis. O nível padrão é normal. A tabela a seguir descreve os níveis.
Nível Valor Comentários

hexadecimal
Normal 0x8 (fator de Defina a janela de recepção TCP para aumentar para acomodar
(padrão) escala de 8) quase todos os cenários.
Desabilitado Nenhum fator de Defina a janela de recepção TCP com seu valor padrão.
escala disponível
Restritos 0x4 (fator de Defina a janela de recepção TCP para aumentar além do valor
escala de 4) padrão, mas limite esse crescimento em alguns cenários.
Altamente 0x2 (fator de Defina a janela de recepção TCP para aumentar além do valor
restrito escala de 2) padrão, mas faça isso de forma muito conservadora.
Habilitação 0xE (fator de Defina a janela de recepção TCP para aumentar para acomodar
escala de 14) cenários extremos.
Se você usar um aplicativo para capturar pacotes de rede, o aplicativo deverá relatar
dados semelhantes aos seguintes para configurações de nível de ajuste automática de
janela diferentes.
Nível de ajuste automática: normal (estado padrão)
Frame: Number = 492, Captured Frame Length = 66, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-

F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F]
+ Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP,

Packet ID = 2667, Total IP Length = 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60975, DstPort=Microsoft-

DS(445), PayloadLen=0, Seq=4075590425, Ack=0, Win=64240 ( Negotiating
scale factor 0x8 ) = 64240
SrcPort: 60975
DstPort: Microsoft-DS(445)
SequenceNumber: 4075590425 (0xF2EC9319)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. -----------------------------------------------------

----> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x8 ) = 64240 ---------> TCP

Receive Window set as 64K as per NIC Link bitrate. Note it shows the
0x8 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 8 ----------------------------->

Scale factor, defined by AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:
Nível de ajuste automática: desabilitado



DS(445), PayloadLen=0, Seq=2315885330, Ack=0, Win=64240 ( ) = 64240
SrcPort: 60956
SequenceNumber: 2315885330 (0x8A099B12)
+ Flags: ......S. -----------------------------------------------------

----> SYN Flag set
Window: 64240 ( ) = 64240 ----------------------------------------> TCP

Receive Window set as 64K as per NIC Link bitrate. Note there is no
Scale Factor defined. In this case, Scale factor is not being sent as a
TCP Option, so it will not be used by Windows.
Checksum: 0x817E, Bad
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ NoOption:
+ SACKPermitted:
Nível de ajuste automática: restrito



SrcPort: 60890
SequenceNumber: 1966088568 (0x75302178)
+ Flags: ......S. -----------------------------------------------------

----> SYN Flag set

0x4 Scale Factor.
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 4 ------------------------------->

Scale factor, defined by AutoTuningLevel.
+ NoOption:
+ NoOption:
+ SACKPermitted:
Nível de ajuste automática: altamente restrito




SrcPort: 60903
SequenceNumber: 1463725706 (0x573EAE8A)
+ Flags: ......S. -----------------------------------------------------

----> SYN Flag set

0x2 Scale Factor.
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 2 ------------------------------>

+ NoOption:
+ NoOption:
+ SACKPermitted:
Nível de ajuste automática: experimental



scale factor 0xe ) = 64240
SrcPort: 60933
SequenceNumber: 2095111365 (0x7CE0DCC5)
+ Flags: ......S. -----------------------------------------------------

----> SYN Flag set
Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP

0xe Scale Factor.
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 14 ----------------------------->

+ NoOption:
+ NoOption:
+ SACKPermitted:
Parâmetros TCP preteridos

as seguintes configurações do registro do Windows Server 2003 não são mais
suportadas e são ignoradas em versões posteriores.
TcpWindowSize
NumTcbTablePartitions
MaxHashTableSize
Todas essas configurações foram localizadas na seguinte subchave do registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Plataforma de filtragem do Windows

o Windows Vista e o Windows Server 2008 introduziram a WFP (plataforma de filtragem
de Windows). A WFP fornece APIs para fornecedores de software independentes (ISVs)
que não são da Microsoft para criar filtros de processamento de pacotes. Exemplos
incluem software de firewall e antivírus.
７ Observação
Um filtro WFP mal escrito pode diminuir significativamente o desempenho de rede

de um servidor. para obter mais informações, consulte portando Packet-
Processing Drivers e aplicativos para o WFP no Windows Centro de
Desenvolvimento.
Para obter links para todos os tópicos deste guia, consulte ajuste de desempenho do
subsistema de rede.
Contadores de desempenho
relacionados à rede
Este tópico lista os contadores relevantes para gerenciar o desempenho da rede e

contém as seções a seguir.
Utilização de recursos
Possíveis problemas de rede
Desempenho de RSC (Coalescing do Lado de Recebimento)
Utilização de recursos
Os contadores de desempenho a seguir são relevantes para a utilização de recursos de
rede.
IPv4, IPv6
Datagramas recebidos/s
Datagramas enviados/s
TCPv4, TCPv6
Segmentos recebidos/s
Segmentos Enviados/s
Segmentos Retransmitidos/s
Adaptador de rede(*), Adaptador de Rede(*)
Bytes Recebidos/s
Bytes Enviados/s
Pacotes recebidos/s
Pacotes enviados/s
Tamanho da Fila de Saída
Esse contador é o comprimento da fila de pacotes de saída (em pacotes). Se for

maior que 2, ocorrerão atrasos. Você deverá encontrar o gargalo e eliminá-lo, se
possível. Como o NDIS enfileia as solicitações, esse comprimento sempre deve
ser 0.
Informações do processador
% Tempo do Processador
Interrupções/s
DPCs na fila/s
Esse contador é uma taxa média na qual os DPCs foram adicionados à fila DPC
do processador lógico. Cada processador lógico tem sua própria fila DPC. Esse
contador mede a taxa na qual os DPCs são adicionados à fila, não o número de
DPCs na fila. Ele exibe a diferença entre os valores que foram observados nos
dois últimos exemplos, divididos pela duração do intervalo de exemplo.
Possíveis problemas de rede

Os contadores de desempenho a seguir são relevantes para possíveis problemas de
rede.
Adaptador de rede(*), Adaptador de Rede(*)
Pacotes Recebidos Descartados
Erros de Pacotes Recebidos
Pacotes de Saída Descartados
Erros de Pacotes de Saída
WFPv4, WFPv6
Pacotes descartados/s
UDPv4, UDPv6
Erros recebidos de datagramas
TCPv4, TCPv6
Falhas de Conexão
Conexões Redefinidas
Política de QoS de rede
Pacotes descartados
Pacotes descartados/s
Atividade de placa de interface de rede por processador
Indicações de recebimento de recursos baixos/s
Pacotes de Baixo Recurso Recebidos/s
Microsoft Winsock BSP
Datagramas descartados
Datagramas descartados/s
Conexões rejeitadas
Conexões rejeitadas/s
Desempenho de RSC (Coalescing do Lado de

Recebimento)
Os contadores de desempenho a seguir são relevantes para o desempenho da RSC.
Adaptador de rede(*)
Conexões RSC Ativas TCP
Tamanho médio do pacote TCP RSC
Pacotes de RSC de TCP coalesced/s
Exceções de RSC TCP/s
Para ver links para todos os tópicos neste guia, consulte Ajuste de desempenho do
subsistema de rede.
Ferramentas de desempenho para
cargas de trabalho de rede
Você pode usar este tópico para saber mais sobre as ferramentas de desempenho.
Este tópico contém seções sobre a ferramenta Tráfego de Cliente para Servidor e
Tamanho da Janela TCP/IP.
Ferramenta de tráfego de cliente para servidor

A ferramenta tráfego de cliente para servidor (ctsTraffic) fornece a capacidade de criar e
verificar o tráfego de rede.
Para obter mais informações e para baixar a ferramenta, consulte ctsTraffic (tráfego de
cliente para servidor) .
Tamanho da janela TCP/IP

Para adaptadores de 1 GB, as configurações mostradas na tabela anterior devem
fornecer uma boa taxa de transferência porque NTttcp define o tamanho da janela TCP
padrão como 64 K por meio de uma opção específica do processador lógico
(SO_RCVBUF) para a conexão. Isso fornece um bom desempenho em uma rede de baixa
latência.
Por outro lado, para redes de alta latência ou para adaptadores de 10 GB, o valor de
tamanho da janela TCP padrão para NTttcp produz um desempenho inferior ao ideal.
Em ambos os casos, você deve ajustar o tamanho da janela TCP para permitir o produto
de atraso de largura de banda maior.
Você pode definir estaticamente o tamanho da janela TCP como um valor grande
usando a opção -rb . Essa opção desabilita o Ajuste Automático da Janela TCP e é
recomendável usá-la somente se o usuário entender totalmente a alteração resultante
no comportamento TCP/IP. Por padrão, o tamanho da janela TCP é definido com um
valor suficiente e se ajusta apenas sob carga pesada ou em links de alta latência.
Para obter mais informações, consulte Ajuste de desempenho do subsistema de rede.

Requisitos de rede de host para o Azure
Stack HCI
Aplica-se a: Azure Stack HCI, versões 22H2, 21H2 e 20H2
Este tópico discute as considerações e os requisitos de rede do host para o Azure Stack
HCI. Para obter informações sobre arquiteturas de datacenter e as conexões físicas entre
servidores, consulte Requisitos de rede física.
Para obter informações sobre como simplificar a rede de host usando a ATC de rede,
consulte Simplificar a rede de host com a ATC de rede.
Tipos de tráfego de rede

O tráfego de rede do Azure Stack HCI pode ser classificado por sua finalidade pretendida:
Tráfego de gerenciamento: Tráfego de ou para fora do cluster local. Por exemplo,

tráfego de réplica de armazenamento ou tráfego usado pelo administrador para
gerenciamento do cluster, como Área de Trabalho Remota, Windows Admin Center,
Active Directory etc.
Tráfego de computação: Tráfego proveniente ou destinado a uma VM (máquina
virtual).
Tráfego de armazenamento: Tráfego usando o protocolo SMB, por exemplo,
Espaços de Armazenamento Diretos ou migração dinâmica baseada em SMB. Esse
tráfego é de camada 2 e não é roteável.
） Importante
A réplica de armazenamento usa tráfego SMB não baseado em RDMA. Essa e a

natureza direcional do tráfego (Norte-Sul) o tornam estreitamente alinhado ao
tráfego de "gerenciamento" listado acima, semelhante ao de um compartilhamento
de arquivos tradicional.
Selecionar um adaptador de rede

Os adaptadores de rede são qualificados pelos tipos de tráfego de rede (veja acima) com
os quais eles têm suporte para uso. À medida que você examina o Catálogo do Windows
Server , a certificação do Windows Server 2022 agora indica uma ou mais das funções a
seguir. Antes de comprar um servidor para o Azure Stack HCI, você deve ter minimamente
pelo menos um adaptador qualificado para gerenciamento, computação e
armazenamento, pois todos os três tipos de tráfego são necessários no Azure Stack HCI.
Em seguida, você pode usar a ATC de Rede para configurar seus adaptadores para os tipos
de tráfego apropriados.
Para obter mais informações sobre essa qualificação nic baseada em função, consulte este
link .
） Importante
Não há suporte para o uso de um adaptador fora de seu tipo de tráfego qualificado.
Nível Função de Função de Função de

Gerenciamento computação armazenamento
Distinção baseada em Gerenciamento Padrão de Armazenamento de

função Computação Computação
Prêmio máximo Não Aplicável Computação Armazenamento Premium

Premium
７ Observação
A qualificação mais alta para qualquer adaptador em nosso ecossistema conterá as

qualificações de Gerenciamento, Computação Premium e Armazenamento
Premium .
Exigências do driver
Não há suporte para drivers de caixa de entrada para uso com o Azure Stack HCI. Para
identificar se o adaptador está usando um driver de caixa de entrada, execute o cmdlet a
seguir. Um adaptador está usando um driver de caixa de entrada se a propriedade
DriverProvider for Microsoft.
Powershell
Get-NetAdapter -Name <AdapterName> | Select *Driver*
Visão geral dos principais recursos do adaptador

de rede
Os recursos importantes do adaptador de rede usados pelo Azure Stack HCI incluem:
Várias filas de máquina virtual dinâmica (VMMQ dinâmico ou d.VMMQ)

Acesso Remoto Direto à Memória (RDMA)
RDMA convidado
Switch Embedded Teaming (SET)
VMMQ dinâmico
Todos os adaptadores de rede com a qualificação de Computação (Premium) dão suporte
ao VMMQ Dinâmico. O VMMQ dinâmico requer o uso do Agrupamento Inserido com
Comutador.
Tipos de tráfego aplicáveis: computação
Certificações necessárias: Computação (Premium)
O VMMQ dinâmico é uma tecnologia inteligente do lado do recebimento. Ele se baseia

em seus antecessores de VMQ (Fila de Máquina Virtual), vRSS (Virtual Receive Side
Scaling) e VMMQ, para fornecer três melhorias principais:
Otimiza a eficiência do host usando menos núcleos de CPU.

Ajuste automático do processamento de tráfego de rede para núcleos de CPU,
permitindo que as VMs atendam e mantenham a taxa de transferência esperada.
Permite que cargas de trabalho "com intermitência" recebam a quantidade esperada
de tráfego.
Para obter mais informações sobre o VMMQ dinâmico, consulte a postagem no blog
Acelerações sintéticas .
RDMA
RDMA é um descarregamento de pilha de rede para o adaptador de rede. Ele permite que
o tráfego de armazenamento SMB ignore o sistema operacional para processamento.
O RDMA permite a rede de alta taxa de transferência e baixa latência, usando recursos
mínimos de CPU do host. Esses recursos de CPU do host podem ser usados para executar
VMs ou contêineres adicionais.
Tipos de tráfego aplicáveis: armazenamento de host
Certificações necessárias: Armazenamento (Standard)
Todos os adaptadores com qualificação de Armazenamento (Standard) ou

Armazenamento (Premium) dão suporte ao RDMA do lado do host. Para obter mais
informações sobre como usar o RDMA com cargas de trabalho de convidado, consulte a
seção "RDMA convidado" mais adiante neste artigo.
O Azure Stack HCI dá suporte ao RDMA com as implementações de protocolo iWARP

(Protocolo RDMA de Ampla Área da Internet) ou RDMA sobre Implementações de
protocolo RoCE (Ethernet Converged).
） Importante
Os adaptadores RDMA só funcionam com outros adaptadores RDMA que

implementam o mesmo protocolo RDMA (iWARP ou RoCE).
Nem todos os adaptadores de rede de fornecedores dão suporte a RDMA. A tabela a

seguir lista os fornecedores (em ordem alfabética) que oferecem adaptadores RDMA
certificados. No entanto, há fornecedores de hardware não incluídos nesta lista que
também dão suporte a RDMA. Consulte o Catálogo do Windows Server para localizar
adaptadores com a qualificação de Armazenamento (Standard) ou Armazenamento
(Premium) que exigem suporte a RDMA.
７ Observação
Não há suporte para InfiniBand (IB) com o Azure Stack HCI.
Fornecedor de NIC iWARP RoCE
Broadcom Não Sim
Intel Sim Sim (alguns modelos)
Marvell (Qlogic) Sim Sim
Nvidia Não Sim
Para obter mais informações sobre como implantar o RDMA para o host, é altamente
recomendável usar a ATC de Rede. Para obter informações sobre a implantação manual,
consulte o repositório GitHub do SDN .
iWARP
O iWARP usa o Protocolo de Controle de Transmissão (TCP) e, opcionalmente, pode ser
aprimorado com o PFC (Controle de Fluxo Baseado em Prioridade) e o ETS (Serviço de
Transmissão Avançada).
Use iWARP se:
Você não tem experiência no gerenciamento de redes RDMA.

Você não gerencia ou se sente desconfortável ao gerenciar seus comutadores tor
(top-of-rack).
Você não gerenciará a solução após a implantação.
Você já tem implantações que usam iWARP.
Você não tem certeza de qual opção escolher.
RoCE
O RoCE usa o UDP (Protocolo de Datagrama de Usuário) e exige que o PFC e o ETS
forneçam confiabilidade.
Use RoCE se:
Você já tem implantações com RoCE em seu datacenter.

Você está confortável em gerenciar os requisitos de rede do DCB.
RDMA convidado
O RDMA convidado permite que cargas de trabalho SMB para VMs obtenham os mesmos
benefícios de usar o RDMA em hosts.
Tipos de tráfego aplicáveis: Armazenamento baseado em convidado
Certificações necessárias: Computação (Premium)
Os principais benefícios de usar o RDMA convidado são:
Descarregamento de CPU para a NIC para processamento de tráfego de rede.

Latência extremamente baixa.
Alta taxa de transferência.
Para obter mais informações, baixe o documento do repositório GitHub do SDN .
SET
SET é uma tecnologia de agrupamento baseada em software que foi incluída no sistema
operacional Windows Server desde Windows Server 2016. SET requer um adaptador de
Computação (Standard) ou Computação (Premium).
Tipos de tráfego aplicáveis: computação, armazenamento e gerenciamento
Certificações necessárias: Computação (Standard) ou Computação (Premium)
SET é a única tecnologia de agrupamento com suporte do Azure Stack HCI. SET funciona
bem com computação, armazenamento e tráfego de gerenciamento.
） Importante
O Azure Stack HCI não dá suporte ao agrupamento NIC com o LBFO (Balanceamento
de Carga/Failover) mais antigo. Confira a postagem no blog Agrupamento no Azure
Stack HCI para obter mais informações sobre LBFO no Azure Stack HCI.
SET é importante para o Azure Stack HCI porque é a única tecnologia de agrupamento
que permite:
Agrupamento de adaptadores RDMA (se necessário).

RDMA convidado.
VMMQ dinâmico.
Outros recursos importantes do Azure Stack HCI (consulte Agrupamento no Azure
Stack HCI ).
SET requer o uso de adaptadores simétricos (idênticos). Os adaptadores de rede simétrica

são aqueles que têm o mesmo:
make (fornecedor)
modelo (versão)
velocidade (taxa de transferência)
configuração
No 22H2, o ATC de Rede detectará e informará automaticamente se os adaptadores

escolhidos são assimétricos. A maneira mais fácil de identificar manualmente se os
adaptadores são simétricos é se as velocidades e as descrições da interface são
correspondências exatas . Eles só podem se desviar no numeral listado na descrição. Use o
Get-NetAdapterAdvancedProperty cmdlet para garantir que a configuração relatada liste
os mesmos valores de propriedade.
Consulte a tabela a seguir para obter um exemplo das descrições da interface desviando
apenas por numeral (#):
Nome Descrição da interface Velocidade do link
NIC1 Adaptador de rede nº 1 25 Gbps
７ Observação
SET dá suporte apenas à configuração independente de comutador usando

algoritmos de balanceamento de carga de Porta Dinâmica ou Hyper-V. Para obter um
melhor desempenho, a porta Hyper-V é recomendada para uso em todas as NICs
que operam em ou acima de 10 Gbps. A ATC de rede faz todas as configurações
necessárias para SET.
Considerações sobre o tráfego RDMA

Se você implementar o DCB, deverá garantir que a configuração de PFC e ETS seja
implementada corretamente em todas as portas de rede, incluindo comutadores de rede.
O DCB é necessário para RoCE e opcional para iWARP.
Para obter informações detalhadas sobre como implantar o RDMA, baixe o documento do
repositório GitHub do SDN .
As implementações do Azure Stack HCI baseadas em RoCE exigem a configuração de três

classes de tráfego PFC, incluindo a classe de tráfego padrão, na malha e em todos os
hosts.
Classe de tráfego de cluster
Essa classe de tráfego garante que haja largura de banda suficiente reservada para
pulsações de cluster:
Exigida: Sim
Habilitado para PFC: Não
Prioridade de tráfego recomendada: Prioridade 7
Reserva de largura de banda recomendada:
10 GbE ou redes RDMA inferiores = 2%
25 GbE ou redes RDMA superiores = 1%
Classe de tráfego RDMA
Essa classe de tráfego garante que haja largura de banda suficiente reservada para
comunicações RDMA sem perdas usando SMB Direct:
Exigida: Sim
Habilitado para PFC: Sim
Prioridade de tráfego recomendada: Prioridade 3 ou 4
Reserva de largura de banda recomendada: 50%
Classe de tráfego padrão

Essa classe de tráfego carrega todo o tráfego não definido no cluster ou nas classes de
tráfego RDMA, incluindo tráfego de VM e tráfego de gerenciamento:
Obrigatório: por padrão (nenhuma configuração necessária no host)

Controle de fluxo (PFC)habilitado: Não
Classe de tráfego recomendada: por padrão (Prioridade 0)
Reserva de largura de banda recomendada: por padrão (nenhuma configuração de
host é necessária)
Modelos de tráfego de armazenamento

O SMB oferece muitos benefícios como o protocolo de armazenamento para o Azure
Stack HCI, incluindo o SMB Multichannel. O SMB Multichannel não é abordado neste
artigo, mas é importante entender que o tráfego é multiplexado em todos os links
possíveis que o SMB Multichannel pode usar.
７ Observação
É recomendável usar várias sub-redes e VLANs para separar o tráfego de

armazenamento no Azure Stack HCI.
Considere o exemplo a seguir de um cluster de quatro nós. Cada servidor tem duas portas
de armazenamento (esquerda e direita). Como cada adaptador está na mesma sub-rede e
VLAN, o SMB Multichannel distribuirá conexões entre todos os links disponíveis. Portanto,
a porta do lado esquerdo no primeiro servidor (192.168.1.1) fará uma conexão com a
porta do lado esquerdo no segundo servidor (192.168.1.2). A porta do lado direito no
primeiro servidor (192.168.1.12) se conectará à porta do lado direito no segundo servidor.
Conexões semelhantes são estabelecidas para o terceiro e quarto servidores.
No entanto, isso cria conexões desnecessárias e causa congestionamento no interlink
(grupo de agregação de link de vários chassis ou MC-LAG) que conecta os comutadores
ToR (marcados com Xs). Confira o diagrama a seguir:
A abordagem recomendada é usar sub-redes e VLANs separadas para cada conjunto de

adaptadores. No diagrama a seguir, as portas à direita agora usam sub-rede 192.168.2.x
/24 e VLAN2. Isso permite que o tráfego nas portas do lado esquerdo permaneça em
TOR1 e o tráfego nas portas do lado direito permaneça no TOR2.

Alocação de largura de banda de tráfego

A tabela a seguir mostra exemplos de alocações de largura de banda de vários tipos de
tráfego, usando velocidades comuns do adaptador, no Azure Stack HCI. Observe que este
é um exemplo de uma solução convergida, em que todos os tipos de tráfego (computação,
armazenamento e gerenciamento) são executados nos mesmos adaptadores físicos e são
agrupados usando SET.
Como esse caso de uso representa a maioria das restrições, ele representa uma boa linha
de base. No entanto, considerando as permutações para o número de adaptadores e
velocidades, isso deve ser considerado um exemplo e não um requisito de suporte.
As seguintes suposições são feitas para este exemplo:
Há dois adaptadores por equipe.
Tráfego de SBL (Camada de Barramento de Armazenamento), CSV (Volume

Compartilhado Clusterizado) e Hyper-V (Migração Dinâmica):
Use os mesmos adaptadores físicos.
Use SMB.
O SMB recebe uma alocação de largura de banda de 50% usando DCB.

SBL/CSV é o tráfego de prioridade mais alta e recebe 70% da reserva de largura
de banda SMB.
A LM (Migração Dinâmica) é limitada usando o Set-SMBBandwidthLimit cmdlet e
recebe 29% da largura de banda restante.
Se a largura de banda disponível para Migração Dinâmica for >= 5 Gbps e os

adaptadores de rede forem capazes, use RDMA. Use o seguinte cmdlet para
fazer isso:
Powershell
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
Se a largura de banda disponível para Migração Dinâmica for < de 5 Gbps, use
a compactação para reduzir os tempos de apagão. Use o seguinte cmdlet para
fazer isso:
Powershell
Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
Se você estiver usando o RDMA para tráfego de Migração Dinâmica, verifique se o

tráfego de Migração Dinâmica não pode consumir toda a largura de banda alocada
para a classe de tráfego RDMA usando um limite de largura de banda SMB. Tenha
cuidado, pois esse cmdlet entra em bytes por segundo (Bps), enquanto os
adaptadores de rede são listados em bits por segundo (bps). Use o seguinte cmdlet
para definir um limite de largura de banda de 6 Gbps, por exemplo:
Powershell
Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
７ Observação
Neste exemplo, 750 MBps equivalem a 6 Gbps.
Aqui está o exemplo de tabela de alocação de largura de banda:

Velocidade Largura Reserva % de Largura % de Largura % de Largura
da NIC de banda de SBL/CSV de migração de banda pulsação de
agrupada largura banda ao vivo máxima banda
de SBL/CSV de de
banda migração pulsação
SMB** ao vivo
10 Gbps 20 Gbps 10 Gbps 70% 7 Gbps ** 200 Mbps
25 Gbps 50 Gbps 25 Gbps 70% 17,5 29% 7,25 Gbps 1% 250

Gbps Mbps
40 Gbps 80 Gbps 40 Gbps 70% 28 Gbps 29% 11,6 Gbps 1% 400

Mbps
50 Gbps 100 Gbps 50 Gbps 70% 35 Gbps 29% 14,5 Gbps 1% 500
Mbps
100 Gbps 200 Gbps 100 70% 70 Gbps 29% 29 Gbps 1% 1 Gbps
Gbps
200 Gbps 400 Gbps 200 70% 140 29% 58 Gbps 1% 2 Gbps
Gbps Gbps
* Use compactação em vez de RDMA, pois a alocação de largura de banda para o tráfego
de Migração Dinâmica é <de 5 Gbps.
** 50% é um exemplo de reserva de largura de banda.
Clusters estendidos
Os clusters estendidos fornecem recuperação de desastre que abrange vários datacenters.
Em sua forma mais simples, uma rede de cluster ampliada do Azure Stack HCI tem esta
aparência:

Requisitos de cluster estendido

Os clusters estendidos têm os seguintes requisitos e características:
O RDMA é limitado a um único site e não tem suporte em diferentes sites ou sub-
redes.
Os servidores no mesmo site devem residir no mesmo rack e no limite da Camada 2.
A comunicação de host entre sites deve cruzar um limite de Camada 3; Não há

suporte para topologias estendidas de Camada 2.
Tenha largura de banda suficiente para executar as cargas de trabalho no outro site.
No caso de um failover, o site alternativo precisará executar todo o tráfego.
Recomendamos que você provisione sites com 50% da capacidade de rede
disponível. No entanto, isso não é um requisito se você conseguir tolerar um
desempenho mais baixo durante um failover.
A replicação entre sites (tráfego norte/sul) pode usar as mesmas NICs físicas que o
armazenamento local (tráfego leste/oeste). Se você estiver usando os mesmos
adaptadores físicos, esses adaptadores deverão ser agrupados com SET. Os
adaptadores também devem ter NICs virtuais adicionais provisionadas para tráfego
roteável entre sites.
Adaptadores usados para comunicação entre sites:
Pode ser físico ou virtual (vNIC do host). Se os adaptadores forem virtuais, você
deverá provisionar uma vNIC em sua própria sub-rede e VLAN por NIC física.
Deve estar em sua própria sub-rede e VLAN que possam rotear entre sites.
O RDMA deve ser desabilitado usando o Disable-NetAdapterRDMA cmdlet .

Recomendamos que você exija explicitamente que a Réplica de Armazenamento
use interfaces específicas usando o Set-SRNetworkConstraint cmdlet .
Deve atender a quaisquer requisitos adicionais para a Réplica de Armazenamento.
Exemplo de cluster estendido

O exemplo a seguir ilustra uma configuração de cluster estendido. Para garantir que uma
NIC virtual específica seja mapeada para um adaptador físico específico, use o cmdlet Set-
VMNetworkAdapterTeammapping .
O exemplo a seguir mostra os detalhes da configuração do cluster estendido de exemplo.
７ Observação
Sua configuração exata, incluindo nomes NIC, endereços IP e VLANs, pode ser
diferente do que é mostrado. Isso é usado apenas como uma configuração de
referência que pode ser adaptada ao seu ambiente.
SiteA – Replicação local, RDMA habilitada, não roteável entre sites
Nome do Nome do NIC física VLAN IP e sub-rede Escopo do

nó vNIC (mapeada) tráfego
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Somente site

local

local

local

local
SiteB – Replicação local, RDMA habilitado, não roteável entre sites
Nome do Nome do NIC física VLAN IP e sub-rede Escopo do

nó vNIC (mapeada) tráfego
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Somente site

local

local

local

local
SiteA – Replicação estendida, RDMA desabilitada, roteável entre sites
Nome do nó Nome do vNIC NIC física (mapeada) IP e sub-rede Escopo do tráfego
NodeA1 Stretch1 pNIC01 173.0.0.1/8 Roteável entre sites

SiteB – replicação estendida, RDMA desabilitada, roteável entre sites
NodeB1 Stretch1 pNIC01 175.0.0.1/8 Roteável entre sites
Próximas etapas
Saiba mais sobre a opção de rede e os requisitos de rede física. Confira Requisitos de
rede física.
Saiba como simplificar a rede de host usando a ATC de Rede. Consulte Simplificar a
rede de host com a ATC de Rede.
Ative os conceitos básicos de rede de clustering de failover .
Para implantação, consulte Criar um cluster usando Windows Admin Center.
Para implantação, consulte Criar um cluster usando Windows PowerShell.
Monitor de pacote (Pktmon)
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows 10, Azure Stack
Hub, Azure, Azure Stack HCI, versões 21H2 e 20H2
O Monitor de Pacotes (Pktmon) é uma ferramenta de diagnóstico de rede entre

componentes em caixa para Windows. Ele pode ser usado para captura de pacotes,
detecção de descarte de pacotes, filtragem e contagem de pacotes. A ferramenta é
especialmente útil em cenários de virtualização, como rede de contêiner e SDN, pois
fornece visibilidade dentro da pilha de rede. Ele está disponível em caixa por meio do
comando pktmon.exe e por meio de extensões de Windows Admin Center.
Visão geral
Qualquer computador que se comunique pela rede tem pelo menos um adaptador de
rede. Todos os componentes entre esse adaptador e um aplicativo formam uma pilha de
rede: um conjunto de componentes de rede que processam e movem o tráfego de rede.
Em cenários tradicionais, a pilha de rede é pequena e todo o roteamento e alternância
de pacotes ocorre em dispositivos externos.
No entanto, com o advento da virtualização de rede, o tamanho da pilha de rede se

multiplicou. Essa pilha de rede estendida agora inclui componentes como o Comutador
Virtual que manipula o processamento e a alternância de pacotes. Esse ambiente flexível
permite um isolamento de segurança e utilização de recursos muito melhor, mas
também deixa mais espaço para erros de configuração que podem ser difíceis de
diagnosticar. O Monitor de Pacotes fornece a visibilidade aprimorada dentro da pilha de
rede que geralmente é necessária para identificar esses erros.
O Monitor de Pacotes intercepta pacotes em vários locais em toda a pilha de rede,
expondo a rota do pacote. Se um pacote tiver sido descartado por um componente
com suporte na pilha de rede, o Monitor de Pacotes relatará essa queda de pacote. Isso
permite que os usuários diferenciem entre um componente que é o destino pretendido
para um pacote e um componente que está interferindo em um pacote. Além disso, o
Monitor de Pacotes relatará motivos de descarte; por exemplo, incompatibilidade de
MTU ou VLAN filtrada, etc. Esses motivos de descarte fornecem a causa raiz do
problema sem a necessidade de esgotar todas as possibilidades. O Monitor de Pacotes
também fornece contadores de pacotes para cada ponto de interceptação, habilitando
um exame de fluxo de pacotes de alto nível sem a necessidade de análise de log
demorada.
Práticas Recomendadas
Use essas práticas recomendadas para simplificar sua análise de rede.
Verifique a ajuda da linha de comando para obter argumentos e recursos (por

exemplo, ajuda de início do pktmon).
Configure filtros de pacote correspondentes ao seu cenário (adicionar filtro
pktmon).
Verifique os contadores de pacote durante o experimento para exibição de alto
nível (contadores pktmon).
Examine o log para obter uma análise detalhada (pktmon format pktmon.etl).
Funcionalidade
O Monitor de Pacotes oferece a seguinte funcionalidade:
Monitoramento e contagem de pacotes em vários locais ao longo da pilha de rede

Detecção de descarte de pacotes em vários locais de pilha
Filtragem de pacotes em runtime flexível com suporte a encapsulamento
Suporte a registro em log e rastreamento geral (eventos ETW e WPP)
Análise de log TXT com base na análise de pacote TcpDump
Vários modos de log: em tempo real, alto volume na memória, vários arquivos,
circular
Suporte a tipos de mídia Ethernet, Wi-Fi e banda larga móvel
Suporte ao formato PCAPNG
Introdução com o Monitor de Pacotes

Os recursos a seguir estão disponíveis para ajudá-lo a começar a usar o Monitor de
Pacotes.
Sintaxe e formatação do comando do Pktmon

O Monitor de Pacotes está disponível em caixa por meio do comando pktmon.exe no
sistema operacional Vibranium (build 19041). Você pode usar este tópico para aprender
a entender a sintaxe, os comandos, a formatação e a saída do pktmon.
Extensão de monitoramento de pacotes no Windows

Admin Center
A extensão monitoramento de pacotes permite que você opere e consuma o Monitor
de Pacotes por meio de Windows Admin Center. A extensão ajuda você a diagnosticar
sua rede capturando e exibindo o tráfego de rede por meio da pilha de rede em um log
que é fácil de seguir e manipular. Você pode usar este tópico para aprender a operar a
ferramenta e entender sua saída.
Extensão de Diagnóstico de Caminho de Dados do SDN

no Windows Admin Center
O Diagnóstico de Caminho de Dados do SDN é uma ferramenta dentro da extensão de
monitoramento de SDN de Windows Admin Center. A ferramenta automatiza as
capturas de pacotes baseadas em Monitor de Pacotes de acordo com vários cenários de
SDN e apresenta a saída em uma única exibição fácil de seguir e manipular. Você pode
usar este tópico para aprender a operar a ferramenta e entender sua saída.
Suporte do Monitor de Rede da Microsoft (Netmon)

O Monitor de Pacotes gera logs no formato ETL. Esses logs podem ser analisados
usando o Microsoft Network Monitor (Netmon) usando analisadores especiais. Este
tópico explica como analisar arquivos ETL gerados pelo Monitor de Pacotes no Netmon.
Suporte do Wireshark (formato pcapng)

O Monitor de Pacotes pode converter logs em formato pcapng. Esses logs podem ser
analisados usando Wireshark (ou qualquer analisador pcapng). Este tópico explica a
saída esperada e como tirar proveito dela.
Fornecer comentários para a equipe de

engenharia
Relate os bugs ou envie comentários por meio do hub de comentários usando as
seguintes etapas:
1. Inicie o Hub de Comentários por meio do menu Iniciar .
2. Selecione o botão Relatar um problema ou sugerir um botão de recurso .
3. Forneça um título de comentários significativo em Resumir sua caixa de

problemas.
4. Forneça detalhes e etapas para reproduzir o problema na caixa Fornecer mais

detalhes .
5. Selecione Rede e Internet como a categoria superior e, em seguida, Monitor de

Pacotes (pktmon.exe) como a subcategoria.
6. Para nos ajudar a identificar e corrigir o bug mais rapidamente, capture capturas
de tela, anexe o log de saída do pktmon e/ou recrie o problema.
7. Clique em Enviar.
Depois de enviar os comentários/bugs, a equipe de engenharia poderá examinar os

comentários e endereçá-lo.
Formatação de comando Pktmon

fornece visibilidade dentro da pilha de rede. O Monitor de Pacotes está disponível em
caixa por meio do comando pktmon.exe em Windows 10 e Windows Server 2019
(versão 1809 e posterior). Você pode usar este tópico para aprender a entender a
sintaxe pktmon, a formatação de comando e a saída. Para obter uma lista completa de
comandos, consulte a sintaxe pktmon.
Início rápido
Use as seguintes etapas para começar em cenários genéricos:
1. Identifique o tipo de pacotes necessários para a captura, como endereços IP

específicos, portas ou protocolos associados ao pacote.
2. Verifique a sintaxe para aplicar filtros de captura e aplique os filtros para os

pacotes identificados na etapa anterior.
PowerShell
C:\Test> pktmon filter add help
C:\Test> pktmon filter add <filters>
3. Inicie a captura e habilite o log de pacotes.
PowerShell
C:\Test> pktmon start -c
4. Reproduza o problema que está sendo diagnosticado. Contadores de consulta

para confirmar a presença do tráfego esperado e para obter uma visão de alto
nível de como o tráfego fluiu no computador.
PowerShell
C:\Test> pktmon counters
5. Interrompa a captura e recupere os logs no formato txt para análise.
PowerShell
C:\Test> pktmon stop
C:\Test> pktmon etl2txt <etl file>
Consulte Analisar a saída do Monitor de Pacotes para obter instruções sobre como
analisar a saída do txt.
Capturar filtros
É altamente recomendável aplicar filtros antes de iniciar qualquer captura de pacote,
pois a solução de problemas de conectividade com um destino específico é mais fácil
quando você se concentra em um único fluxo de pacotes. Capturar todo o tráfego de
rede pode tornar a saída muito ruiva para ser analisada. Para que um pacote seja
relatado, ele deve corresponder a todas as condições especificadas em pelo menos um
filtro. Há suporte para até 32 filtros de uma só vez.
Por exemplo, o seguinte conjunto de filtros capturará qualquer tráfego ICMP de ou para
o endereço IP 10.0.0.10, bem como qualquer tráfego na porta 53.
PowerShell
C:\Test> pktmon filter add -i 10.0.0.10 -t icmp
C:\Test> pktmon filter add -p 53
Funcionalidade de filtragem
O Monitor de Pacotes dá suporte à filtragem por endereços MAC, endereços IP,
portas, EtherType, protocolo de transporte e ID de VLAN.
O Monitor de Pacotes não diferenciará a origem ou o destino quando se trata de

endereço MAC, endereço IP ou filtros de porta.
Para filtrar ainda mais os pacotes TCP, uma lista opcional de sinalizadores TCP a
serem correspondentes pode ser fornecida. Os sinalizadores com suporte são FIN,
SYN, RST, PSH, ACK, URG, ECE e CWR.
Por exemplo, o filtro a seguir capturará todos os pacotes SYN enviados ou
recebidos pelo endereço IP 10.0.0.10:
PowerShell
C:\Test> pktmon filter add -i 10.0.0.10 -t tcp syn
O Monitor de Pacotes pode aplicar um filtro a pacotes internos encapsulados,

além do pacote externo se o sinalizador [-e] tiver sido adicionado a qualquer filtro.
Os métodos de encapsulamento com suporte são VXLAN, GRE, NVGRE e IP em IP.
A porta VXLAN personalizada é opcional e é padrão para 4789.
Para obter mais informações, consulte a sintaxe do filtro pktmon.
Captura de pacotes e eventos gerais

O Monitor de Pacotes pode capturar pacotes por meio do parâmetro [-c] com o
comando iniciar. Isso habilitará a captura e o registro em log de pacotes, bem como
contadores de pacotes. Para habilitar os contadores de pacotes somente sem registrar o
pacote em log, adicione o parâmetro [-o] ao comando iniciar. Para obter mais
informações sobre contadores de pacotes, consulte a seção Contadores de pacotes
abaixo.
Você pode selecionar componentes para monitorar por meio do parâmetro [--comp] .
Ele pode ser apenas NICs ou uma lista de IDs de componente e é padrão para todos os
componentes. Você também pode filtrar por status de propagação de pacotes (pacotes
descartados ou fluindo) usando o parâmetro [--type] .
Junto com a captura de pacotes, o Monitor de Pacotes permite a captura de eventos

gerais, como eventos ETW e WPP, declarando o parâmetro [-t] e especificando os
provedores por meio do parâmetro [-p] . Use "pktmon stop" para interromper toda a
coleta de dados.
Por exemplo, o comando a seguir capturará pacotes somente dos adaptadores de rede:
PowerShell
C:\Test> pktmon start -c --comp nics
O comando a seguir capturará apenas os pacotes descartados que passam pelos

componentes 4 e 5 e os registrará em log:
PowerShell
C:\Test> pktmon start -c --comp 4,5 --type drop
Esse comando capturará pacotes e eventos de log do provedor "Microsoft-Windows-

TCPIP":
PowerShell
C:\Test> pktmon start --capture --trace -p Microsoft-Windows-TCPIP
Funcionalidade de log de pacotes

O Monitor de Pacotes dá suporte a vários modos de log:
Circular: novos pacotes substituem os mais antigos quando o tamanho máximo
do arquivo é atingido. Esse é o modo de log padrão.
Vários arquivos: um novo arquivo de log é criado quando o tamanho máximo
do arquivo é atingido. Os arquivos de log são numerados sequencialmente:
PktMon1.etl, PktMon2.etl etc. Aplique esse modo de registro em log para
manter todos os logs, mas tenha cuidado com a utilização do armazenamento.
Observação: use o carimbo de data/hora de criação de arquivo de cada arquivo
de log como uma indicação para um período específico na captura.
Em tempo real: os pacotes são exibidos na tela em tempo real. Nenhum arquivo
de log é criado. Use Ctrl+C para interromper o monitoramento.
Memória: os eventos são gravados em um buffer de memória circular. O
tamanho do buffer é especificado por meio do parâmetro [-s ]. O conteúdo do
buffer é gravado em um arquivo de log depois de interromper a captura. Use
esse modo de registro em log para cenários muito barulhentos para capturar
uma enorme quantidade de tráfego em um período muito curto de tempo no
buffer de memória. Usando outros modos de registro em log, algum tráfego
pode se perder.
Especifique quanto do pacote será registrado no parâmetro [-p ]. Registre todo o

pacote de cada pacote independentemente de seu tamanho definindo esse
parâmetro como 0. O padrão é 128 bytes que devem incluir os cabeçalhos da
maioria dos pacotes.
Especifique o tamanho do arquivo de log por meio do parâmetro [-s ]. Esse será o
tamanho máximo do arquivo em um modo de log circular antes que o Monitor de
Pacotes comece a substituir os pacotes mais antigos com os mais recentes. Esse
também será o tamanho máximo de cada arquivo no modo de log de vários
arquivos antes que o Monitor de Pacotes crie um novo arquivo para registrar os
próximos pacotes. Você também pode usar esse parâmetro para definir o tamanho
do buffer para o modo de registro em log de memória.
Para obter mais informações, consulte a sintaxe de início do pktmon.
Análise e formatação de pacotes

O Monitor de Pacotes gera arquivos de log no formato ETL. Há várias maneiras de
formatar o arquivo ETL para análise:
Converta o log em formato de texto (a opção padrão) e analise-o com a

ferramenta do editor de texto, como TextAnalysisTool.NET. Os dados do pacote
serão exibidos no formato TCPDump. Siga o guia abaixo para saber como analisar
a saída no arquivo de texto.
Converter o log em formato pcapng para analisá-lo usando Wireshark*
Abrir o arquivo ETL com o Monitor de Rede*
７ Observação
*Use os hiperlinks acima para saber como analisar e analisar logs do Monitor de
Pacotes no Wireshark e no Monitor de Rede.
Para obter mais informações, consulte sintaxe de formato pktmon.
Analisar a saída do Monitor de Pacotes

O Monitor de Pacotes captura um instantâneo do pacote por cada componente da pilha
de rede. Assim, haverá vários instantâneos de cada pacote (representados na imagem
abaixo pelas linhas da caixa azul).
Cada um desses instantâneos de pacote é
representado por algumas linhas (caixas vermelhas e verdes). Há pelo menos uma linha
que inclui alguns dados sobre a instância do pacote começando com o carimbo de
data/hora. Logo depois, há pelo menos uma linha (em negrito na imagem abaixo) para
mostrar o pacote bruto analisado no formato de texto (sem um carimbo de data/hora);
pode ser várias linhas se o pacote for encapsulado, como o pacote na caixa verde.
Para correlacionar todos os instantâneos dos mesmos pacotes, monitore os valores
PktGroupId e PktNumber (realçados em amarelo); todos os instantâneos do mesmo
pacote devem ter esses dois valores em comum. O valor de Aparência (realçado em
azul) atua como um contador para cada instantâneo subsequente do mesmo pacote.
Por exemplo, o primeiro instantâneo do pacote (em que o pacote apareceu pela
primeira vez na pilha de rede) tem o valor 1 para aparência, o próximo instantâneo tem
o valor 2 e assim por diante.
Cada instantâneo de pacote tem uma ID de componente (sublinhada na imagem acima)

indicando o componente associado ao instantâneo. Para resolver o nome do
componente e os parâmetros, pesquise essa ID de componente na lista de
componentes na parte inferior do arquivo de log. Uma parte da tabela de componentes
é mostrada na imagem abaixo destacando "Componente 1" em amarelo (este foi o
componente em que o último instantâneo acima foi capturado).
Componentes com 2
bordas relatarão dois instantâneos em cada borda (como os instantâneos com a
Aparência 3 e a Aparência 4, por exemplo, na imagem acima).
Na parte inferior de cada arquivo de log, a lista de filtros é apresentada conforme

mostrado na imagem abaixo (realçada em azul). Cada filtro exibe os parâmetros
especificados (Protocolo ICMP no exemplo abaixo) e zeros para o restante dos
parâmetros.
Para pacotes descartados, a palavra "soltar" é exibida antes de qualquer uma das linhas
que representam o instantâneo em que o pacote foi descartado. Cada pacote
descartado também fornece um valor dropReason. Esse parâmetro dropReason fornece
uma breve descrição do motivo da queda do pacote; por exemplo, incompatibilidade de
MTU, VLAN filtrada etc.
Contadores de pacotes
Os contadores do Monitor de Pacotes fornecem uma exibição de alto nível do tráfego
de rede em toda a pilha de rede sem a necessidade de analisar um log, o que pode ser
um processo caro. Examine os padrões de tráfego consultando contadores de pacotes
com contadores pktmon após iniciar a captura do Monitor de Pacotes. Redefina os
contadores como zero usando a redefinição de pktmon ou pare de monitorar todos
juntos usando a parada pktmon.
Os contadores são organizados por pilhas de associação com adaptadores de rede

na parte superior e protocolos na parte inferior.
Tx/Rx: Os contadores são separados em duas colunas para as direções Enviar (Tx) e
Receber (Rx).
Bordas: componentes relatam propagação de pacote quando um pacote está
cruzando o limite do componente (borda). Cada componente pode ter uma ou
mais bordas. Os drivers de miniport normalmente têm uma única borda superior,
os protocolos têm uma única borda inferior e os drivers de filtro têm bordas
superiores e inferiores.
Drops: os contadores de descarte de pacotes estão sendo relatados na mesma
tabela.
No exemplo a seguir, uma nova captura foi iniciada e, em seguida, o comando de
contadores pktmon foi usado para consultar os contadores antes que a captura fosse
interrompida. Os contadores mostram um único pacote saindo da pilha de rede,
começando da camada de protocolo até o adaptador de rede física e sua resposta
voltando na outra direção. Se o ping ou a resposta estiver ausente, será fácil detectá-lo
por meio dos contadores.
No exemplo a seguir, as quedas são relatadas na coluna "Contador". Recupere o Motivo

da Última Queda para cada componente solicitando dados de contadores no formato
JSON usando contadores pktmon --json ou analise o log de saída para obter
informações mais detalhadas.
Conforme mostrado por meio desses exemplos, os contadores podem fornecer muitas
informações por meio de um diagrama que pode ser analisado apenas por uma
aparência rápida.
Para obter mais informações, consulte a sintaxe de contadores pktmon.
Layout da pilha de rede

Examine o layout da pilha de rede por meio da lista pktmon de comando.
O comando mostra componentes de rede (drivers) organizados por associações de
adaptadores.
Uma associação típica consiste em:
Uma nic (placa de interface de rede) única

Alguns drivers de filtro (possivelmente zero)
Um ou mais drivers de protocolo (TCP/IP ou outros)
Cada componente é identificado exclusivamente por uma ID de componente do

Monitor de Pacotes, que são usadas para direcionar componentes individuais para
monitoramento.
７ Observação
As IDs não são persistentes e podem ser alteradas entre reinicializações e conforme
o driver do Monitor de Pacotes é reiniciado.
Algumas IDs que aparecem na saída do Monitor de Pacotes podem não aparecer
na lista de componentes. Isso ocorre devido à agregação de alguns componentes
em uma única ID para facilitar a seleção e a exibição deles. Para localizar as IDs
originais desses componentes, use a lista pktmon --json e procure a propriedade
SecondaryId na saída.
Para obter mais informações, consulte a sintaxe da lista pktmon.

Extensão de monitoramento de pacotes
no Windows Admin Center
A extensão monitoramento de pacotes permite que você opere e consuma o Monitor

de Pacotes por meio de Windows Admin Center. A extensão ajuda você a diagnosticar
sua rede capturando e exibindo o tráfego de rede por meio da pilha de rede em um log
fácil de seguir e manipular.
O que é o Monitor de Pacotes (Pktmon)?

componentes e caixa para Windows. Ele pode ser usado para captura de pacotes,
especialmente útil em cenários de virtualização, como rede de contêiner e SDN, porque
fornece visibilidade dentro da pilha de rede.
O que é o Windows Admin Center?

Windows Admin Center é uma ferramenta de gerenciamento baseada em navegador
implantada localmente que permite gerenciar seus Windows Servers sem dependência
do Azure ou da nuvem. O Windows Admin Center oferece controle total sobre todos os
aspectos da infraestrutura de servidor e é particularmente útil para gerenciar servidores
em redes privadas que não estejam conectadas à Internet. O Windows Admin Center é a
evolução moderna das ferramentas de gerenciamento "nativas", como o Gerenciador de
Servidores e o MMC.
Antes de começar
Para usar a ferramenta, o servidor de destino precisa estar executando o Windows
Server 2019, versão 1903 ou posterior.
Instalar o Windows Admin Center.
Adicione um servidor ao Windows Admin Center:
1. Clique em + Adicionar em Todas as Conexões.

2. Escolha adicionar uma Conexão de Servidor.
3. Digite o nome do servidor e, se solicitado, as credenciais a serem usadas.
4. Clique em Enviar para concluir.
O servidor será adicionado à sua lista de conexões na página Visão geral .
Introdução
Para acessar a ferramenta, navegue até o servidor que você criou na etapa anterior e vá
para a extensão "Monitoramento de pacotes".
Aplicação de filtros
É altamente recomendável aplicar filtros antes de iniciar qualquer captura de pacotes,
pois a solução de problemas de conectividade com um destino específico é mais fácil ao
se concentrar em um único fluxo de pacotes. Por outro lado, capturar todo o tráfego de
rede pode tornar a saída muito barulhenta para ser analisada. Assim, a extensão orienta
você para o painel de filtros primeiro antes de iniciar a captura. Você pode ignorar esta
etapa clicando em Avançar para começar a capturar sem filtros. O painel filtros orienta
você a adicionar filtros em três etapas.
1. Filtragem por componentes de pilha de rede
Se você quiser capturar o tráfego que passa apenas por componentes específicos,
a primeira etapa do painel de filtros mostrará o layout da pilha de rede para que
você possa selecionar os componentes pelos quais filtrar. Esse também é um
ótimo lugar para analisar e entender o layout da pilha de rede do computador.

2. Filtragem por parâmetros de pacote
Para a segunda etapa, o painel permite filtrar pacotes por seus parâmetros. Para
que um pacote seja relatado, ele deve corresponder a todas as condições
especificadas em pelo menos um filtro; há suporte para até 8 filtros ao mesmo
tempo. Para cada filtro, você pode especificar parâmetros de pacote como
Endereços MAC, Endereços IP, Portas, Ethertype, Protocolo de Transporte, ID de
VLAN.
Quando dois MACs, IPs ou portas forem especificados, a ferramenta não

distinguirá entre origem ou destino; ele capturará pacotes que têm os dois
valores, seja como destino ou origem. No entanto, os filtros de exibição
podem fazer essa distinção; consulte a seção Filtros de exibição abaixo.
Para filtrar ainda mais os pacotes TCP, é possível fornecer uma lista opcional
de sinalizadores TCP correspondentes. Os sinalizadores com suporte são FIN,
SYN, RST, PSH, ACK, URG, ECE e CWR.
Se a caixa de encapsulamento estiver marcada, a ferramenta aplicará o filtro
a pacotes internos encapsulados, além do pacote externo. Os métodos de
encapsulamento com suporte são VXLAN, GRE, NVGRE e IP em IP. A porta
VXLAN personalizada é opcional e o padrão é 4789.
3. Filtragem por status do fluxo de pacotes
O Monitor de Pacotes capturará pacotes de fluxo e descartados por padrão. Para

capturar somente em pacotes descartados, selecione Pacotes Descartados.

Posteriormente, um resumo de todas as condições de filtro selecionadas é exibido

para revisão. Você poderá recuperar essa exibição depois de iniciar a captura por
meio do botão Condições de Captura .
Log de captura
Os resultados são exibidos em uma tabela que mostra os principais parâmetros dos
pacotes capturados: Carimbo de data/hora, Endereço IP de Fontes, Porta de Origem,
Endereço IP de Destino, Porta de Destino, Ethertype, Protocolo, Sinalizadores TCP, se o
pacote foi descartado e o motivo da remoção.
O carimbo de data/hora para cada um desses pacotes também é um hiperlink que

redirecionará você para uma página diferente, na qual você poderá encontrar mais
informações sobre o pacote selecionado. Consulte a seção Página de Detalhes
abaixo.
Todos os pacotes descartados têm um valor "True" na guia Descartado , um
motivo de remoção e são exibidos em texto vermelho para facilitar a identificação.
Todas as guias podem ser classificadas em ordem crescente e decrescente.
Você pode pesquisar um valor em qualquer coluna no log usando a barra de
pesquisa.
Você pode reiniciar a captura com os mesmos filtros escolhidos usando o botão
Reiniciar .
Página de detalhes
Esta página apresenta um instantâneo do pacote conforme ele flui por cada
componente da pilha de rede local. Essa exibição mostra o caminho do fluxo de pacotes
e permite que você investigue como os pacotes são alterados à medida que são
processados por cada componente pelo qual passam.
Os instantâneos de pacote são agrupados por cada pilha de

adaptador/comutador; Ou seja, instantâneos de pacote capturados por um
adaptador/comutador, seus drivers de filtro e seus drivers de protocolo serão
agrupados sob o nome do adaptador/comutador. Isso facilitará o
acompanhamento do fluxo do pacote de um adaptador para o outro.
Quando um instantâneo é selecionado, mais detalhes sobre esse instantâneo
específico são mostrados, incluindo os cabeçalhos de pacote brutos.
motivo de remoção e são exibidos em texto vermelho para facilitar a identificação.

Exibir filtros
Os filtros de exibição permitem filtrar o log depois de capturar os pacotes. Para cada
filtro, você pode especificar parâmetros de pacote como Endereços MAC, Endereços IP,
Portas, Ethertype e Protocolo de Transporte. Ao contrário dos filtros de captura:
Os filtros de exibição podem distinguir entre a origem e o destino de endereços IP,

endereços MAC e portas.
Os filtros de exibição podem ser excluídos e editados depois de aplicá-los para
alterar a exibição do log.
Os filtros de exibição são invertidos nos logs salvos.

Salvar recurso
O botão Salvar permite que você salve o log no computador local, no computador
remoto ou em ambos. Os filtros de exibição serão invertidos no log salvo.
Se o log for salvo em seu computador local, você poderá salvá-lo em vários
formatos:
Formato etl que pode ser analisado usando Microsoft Monitor de Rede.
Observação: verifique esta página para obter mais informações.
Formato de texto que pode ser analisado usando qualquer editor de texto
como TextAnalysisTool.NET.
Formato Pcapng que pode ser analisado usando ferramentas como o Wireshark.
A maioria dos metadados do Monitor de Pacotes será perdida durante essa
conversão. Verifique esta página para obter mais informações.
Abrir recurso
O recurso aberto permitirá que você reabra qualquer um dos cinco últimos logs salvos
para analisar por meio da ferramenta.

Extensão de diagnóstico de caminho de
dados SDN no Windows Admin Center
O Diagnóstico de Caminho de Dados do SDN é uma ferramenta dentro da extensão de

monitoramento de SDN de Windows Admin Center que automatiza as capturas de
pacotes baseadas em Monitor de Pacotes de acordo com vários cenários de SDN e
apresenta a saída em uma única exibição fácil de seguir e manipular.
O que é o Monitor de Pacotes (Pktmon)?

detecção de descarte de pacotes, filtragem de pacotes e contagem. A ferramenta é
fornece visibilidade dentro da pilha de rede.
O que é o Windows Admin Center?

Windows Admin Center é uma ferramenta de gerenciamento baseada em navegador
implantada localmente que permite gerenciar seus servidores Windows sem
dependência do Azure ou da nuvem. O Windows Admin Center oferece controle total
sobre todos os aspectos da infraestrutura de servidor e é particularmente útil para
gerenciar servidores em redes privadas que não estejam conectadas à Internet. O
Windows Admin Center é a evolução moderna das ferramentas de gerenciamento
"nativas", como o Gerenciador de Servidores e o MMC.
Antes de começar
Para usar a ferramenta, o servidor de destino precisa estar executando Windows
Server 2019 versão 1903 (19H1) e superior.
Instalar o Windows Admin Center.
Adicione um cluster a Windows Admin Center:
1. Clique em + Adicionar em Todas as Conexões.

2. Escolha adicionar uma conexão de cluster Hyper-Converged.
3. Digite o nome do cluster e, se solicitado, as credenciais a serem usadas.
4. Verifique Configurar o controlador de rede para continuar.
5. Insira o URI do Controlador de Rede e clique em Validar.
6. Clique em Adicionar para concluir.
O cluster será adicionado à lista de conexões. Clique nele para iniciar o Painel.
Introdução
Para acessar a ferramenta, navegue até o cluster que você criou na etapa anterior e, em
seguida, até a extensão "Monitoramento do SDN" e, em seguida, até a guia
"Diagnóstico do Caminho de Dados".
Selecionando cenários
A primeira página lista todos os cenários de SDN classificados como cenários de carga
de trabalho e cenários de infraestrutura, conforme mostrado na imagem abaixo. Para
começar, selecione o cenário de SDN que precisa ser diagnosticado.

Parâmetros de cenário
Depois de escolher o cenário, preencha uma lista de parâmetros obrigatórios e
opcionais para iniciar a captura. Esses parâmetros básicos apontarão a ferramenta para
a conexão que precisa ser diagnosticada. Em seguida, a ferramenta usará esses
parâmetros para consultas para executar uma captura bem-sucedida, sem qualquer
intervenção do usuário para descobrir o fluxo de pacote esperado, os computadores
envolvidos no cenário, sua localização no cluster ou os filtros de captura a serem
aplicados em cada computador. Os parâmetros obrigatórios permitem que a captura
seja executada e os parâmetros opcionais ajudam a filtrar algum ruído.

Log de captura
Depois de iniciar a captura, a extensão mostrará uma lista dos computadores em que a
captura está sendo iniciada. Você poderá ser solicitado a entrar nesses computadores se
suas credenciais não forem salvas. Você pode começar a reproduzir o ping ou o
problema que está tentando diagnosticar capturando os pacotes relativos. Depois que
os pacotes forem capturados, a extensão mostrará marcas ao lado dos computadores
em que os pacotes foram capturados.
Depois de interromper a captura, os logs de todos os computadores serão mostrados

em uma única página, divididos pelo título do computador. Cada título incluirá o nome
do computador, sua função no cenário e seu host no caso de VMs (máquinas virtuais).

Os resultados são exibidos em uma tabela que mostra os principais parâmetros dos
pacotes capturados: Carimbo de data/hora, Endereço IP de Fontes, Porta de Origem,
Endereço IP de Destino, Porta de Destino, Ethertype, Protocolo, Sinalizadores TCP, se o
pacote foi descartado e o motivo da queda.
O carimbo de data/hora para cada um desses pacotes também é um hiperlink que

redirecionará você para uma página diferente onde você pode encontrar mais
informações sobre o pacote selecionado. Consulte a seção Página de Detalhes
abaixo.
motivo de descarte e são exibidos em texto vermelho para facilitar a localização.
Todas as guias podem ser classificadas em ordem crescente e decrescente.
Você pode pesquisar um valor em qualquer coluna no log usando a barra de
pesquisa.
Você pode reiniciar a captura com os mesmos filtros escolhidos usando o botão
Reiniciar .
Página de detalhes
As informações nesta página são particularmente valiosas se você tiver problemas
incorretos de propagação de pacotes ou problemas de configuração incorreta, pois
você pode investigar o fluxo do pacote por meio de cada componente da pilha de rede.
Para cada salto de pacote, há detalhes que incluem os parâmetros de pacote, bem
como os detalhes brutos do pacote.
Os saltos são agrupados com base nos componentes envolvidos. Cada adaptador
e os drivers na parte superior dele são agrupados pelo nome do adaptador. Isso
facilita o acompanhamento do pacote em um alto nível por meio desses títulos de
grupo.
Todos os pacotes descartados também serão exibidos em texto vermelho para
torná-los mais fáceis de identificar.
Selecione um salto para exibir mais detalhes. Em cenários de encapsulamento e NAT

(Conversão de Endereços de Rede), esse recurso permite que você veja o pacote
mudando conforme ele passa pela pilha de rede e verifique se há problemas de
configuração incorreta.

Role para baixo para exibir detalhes brutos do pacote:
Exibir filtros
Os filtros de exibição permitem filtrar o log depois de capturar os pacotes. Para cada
filtro, você pode especificar parâmetros de pacote como Endereços MAC, Endereços IP,
Portas, Ethertype e Protocolo de Transporte.
Os filtros de exibição podem distinguir entre a origem e o destino de endereços IP,

endereços MAC e portas.
Os filtros de exibição podem ser excluídos e editados depois de aplicá-los para
alterar a exibição do log.
Os filtros de exibição são invertidos nos logs salvos.

Salvar
O botão salvar permite que você salve o log em seu computador local para análise
adicional por meio de outras ferramentas. Os filtros de exibição serão invertidos no log
salvo. Os logs podem ser salvos em vários formatos:
Formato ETL que pode ser analisado usando o Microsoft Network Monitor.
Observação: verifique esta página para obter mais informações.
Formato de texto que pode ser analisado usando qualquer editor de texto como
TextAnalysisTool.NET.
Formato Pcapng que pode ser analisado usando ferramentas como o Wireshark.
A maioria dos metadados do Monitor de Pacotes será perdida durante essa
conversão. Observação: verifique esta página para obter mais informações.

Suporte do Pktmon para o Microsoft
Network Monitor (Netmon)
O Monitor de Pacotes (Pktmon) gera logs no formato ETL. Esses logs podem ser
analisados usando o Microsoft Network Monitor (Netmon) usando analisadores
especiais. Este tópico explica como analisar arquivos ETL gerados pelo Monitor de
Pacotes no Netmon.
Configuração e configuração do Monitor de

Rede
Siga estas etapas para instalar e configurar o Netmon para analisar arquivos ETL
gerados pelo Monitor de Pacotes:
1. Instale o Monitor de Rede 3.4 .

2. Inicie o Monitor de Rede com privilégios elevados e defina Windows como perfil
de analisador ativo em (Ferramentas/Opções/Perfis do Analisador).
3. Copie etl_Microsoft-Windows-PktMon-Events.npl daqui para
"%PROGRAMDATA%\Microsoft\Network Monitor 3\NPL\NetworkMonitor
Parsers\Windows"
4. Copie stub_etl_Microsoft-Windows-PktMon-Events.npl daqui para
"%PROGRAMDATA%\Microsoft\Network Monitor 3\NPL\NetworkMonitor
Parsers\Windows\Stubs"
5. Renomeie stub_etl_Microsoft-Windows-PktMon-Events.npl para etl_Microsoft-
Windows-PktMon-Events.npl
6. Inclua etl_Microsoft-Windows-PktMon-Events.npl em
NetworkMonitor_Parsers_sparser.npl em "%PROGRAMDATA%\Microsoft\Network
Monitor 3\NPL\NetworkMonitor Parsers"
7. Reinicie o Monitor de Rede com privilégios elevados para recompilar os
analisadores.
Suporte do Pktmon para Wireshark
(pcapng)
O Monitor de Pacotes (Pktmon) pode converter logs em formato pcapng. Esses logs
podem ser analisados usando Wireshark (ou qualquer analisador pcapng); no entanto,
algumas das informações críticas podem estar ausentes nos arquivos pcapng. Este
tópico explica a saída esperada e como tirar proveito dela.
Sintaxe pktmon pcapng

Use os comandos a seguir para converter a captura de pktmon em formato pcapng.
PowerShell
C:\Test> pktmon pcapng help
pktmon pcapng log.etl [-o log.pcapng]
Convert log file to pcapng format.
Dropped packets are not included by default.
-o, --out
Name of the formatted pcapng file.
-d, --drop-only
Convert dropped packets only.
-c, --component-id
Filter packets by a specific component ID.
Example: pktmon pcapng C:\tmp\PktMon.etl -d -c nics
Filtragem de saída
Todas as informações sobre os relatórios de soltar pacotes e o fluxo de pacotes pela
pilha de rede serão perdidas na saída do pcapng. Portanto, o conteúdo do log deve ser
cuidadosamente pré-filtrado para essa conversão. Por exemplo:
O formato Pcapng não distingue entre um pacote fluindo e um pacote descartado.

Para separar todos os pacotes na captura de pacotes descartados, gere dois
arquivos pcapng; um que contém todos os pacotes ("pktmon pcapng log.etl --out
log-capture.etl"), e outro que contém apenas pacotes descartados ("pktmon
pcapng log.etl --drop-only --out log-drop.etl"). Dessa forma, você poderá
analisar os pacotes descartados em um log separado.
O formato Pcapng não distingue entre diferentes componentes de rede em que
um pacote foi capturado. Para esses cenários multicamadas, especifique a ID de
componente desejada na saída pcapng "pktmon pcapng log.etl --component-id
5". Repita este comando para cada conjunto de IDs de componente em que você
está interessado.
Política de QoS (qualidade de serviço)
Você pode usar a Política de QoS como um ponto central de gerenciamento de largura
de banda de rede em toda sua infraestrutura do Active Directory por meio da criação de
perfis de QoS, cujas configurações são distribuídas com a Política de Grupo.
７ Observação
Além deste tópico, a documentação da Política de QoS a seguir está disponível.
Introdução com a Política de QoS

Gerenciar Política de QoS
Perguntas frequentes sobre a política de QoS
As políticas de QoS são aplicadas a uma sessão de logon do usuário ou a um

computador como parte de um GPO (objeto Política de Grupo) vinculado a um
contêiner do Active Directory, como um domínio, um site ou uma UO (unidade
organizacional).
O gerenciamento de tráfego de QoS ocorre abaixo da camada do aplicativo, o que

significa que seus aplicativos existentes não precisam ser modificados para se beneficiar
das vantagens fornecidas pelas políticas de QoS.
Sistemas operacionais que dão suporte à

política de QoS
Você pode usar a política de QoS para gerenciar a largura de banda para computadores
ou usuários com os seguintes sistemas operacionais da Microsoft.
Windows Server 2016

Windows 10
Windows 8.1
Windows Server 2012
Windows 8
Windows 7
Windows Server 2008
Windows Vista
Local da Política de QoS no Política de Grupo

No Editor de Gerenciamento Windows Server 2016 Política de Grupo, o caminho para a
Política de QoS para Configuração de Computador é o seguinte.
Política de Domínio Padrão | Configuração do computador | Políticas | Windows

Configurações | QoS baseado em política
Esse caminho é ilustrado na imagem a seguir.
No Editor de Gerenciamento do Windows Server 2016 Política de Grupo, o caminho

para a Política de QoS para Configuração do Usuário é o seguinte.
Política de Domínio Padrão | Configuração do usuário | Políticas | Windows

Configurações | QoS baseado em política
Por padrão, nenhuma política de QoS é configurada.
Por que usar a política de QoS?

À medida que o tráfego aumenta em sua rede, é cada vez mais importante equilibrar o
desempenho da rede com o custo do serviço , mas o tráfego de rede normalmente não
é fácil de priorizar e gerenciar.
Em sua rede, aplicativos críticos e sensíveis à latência devem competir pela largura de
banda de rede em relação ao tráfego de menor prioridade. Ao mesmo tempo, alguns
usuários e computadores com requisitos específicos de desempenho de rede podem
exigir níveis de serviço diferenciados.
Os desafios de fornecer níveis de desempenho de rede econômicos e previsíveis

geralmente aparecem primeiro em conexões wan (rede de ampla área) ou com
aplicativos sensíveis à latência, como voIP (voz sobre IP) e streaming de vídeo. No
entanto, a meta final de fornecer níveis previsíveis de serviço de rede se aplica a
qualquer ambiente de rede (por exemplo, uma rede de área local das Empresas) e a
mais de aplicativos VoIP, como os aplicativos de linha de negócios personalizados da
sua empresa.
O QoS baseado em política é a ferramenta de gerenciamento de largura de banda de

rede que fornece controle de rede com base em aplicativos, usuários e computadores.
Quando você usa a Política de QoS, seus aplicativos não precisam ser gravados para
APIs (interfaces de programação de aplicativo) específicas. Isso oferece a capacidade de
usar o QoS com aplicativos existentes. Além disso, o QoS baseado em política aproveita
sua infraestrutura de gerenciamento existente, pois o QoS baseado em política é
integrado a Política de Grupo.
Definir prioridade de QoS por meio de um

ponto de código de serviços diferenciados
(DSCP)
Você pode criar políticas de QoS que definem a prioridade de tráfego de rede com um
valor DSCP (Ponto de Código de Serviços Diferenciados) que você atribui a diferentes
tipos de tráfego de rede.
O DSCP permite que você aplique um valor (0 a 63) no campo TIPO de Serviço (TOS) no
cabeçalho de um pacote IPv4 e dentro do campo Classe de Tráfego no IPv6.
O valor DSCP fornece classificação de tráfego de rede no nível de IP (Protocolo de

Internet), que os roteadores usam para decidir o comportamento de enfileiramento de
tráfego.
Por exemplo, você pode configurar roteadores para colocar pacotes com valores DSCP
específicos em uma das três filas: alta prioridade, melhor esforço ou menor que o
melhor esforço.
O tráfego de rede crítico, que está na fila de alta prioridade, tem preferência em relação
a outro tráfego.
Limitar o uso de largura de banda de rede por aplicativo

com a taxa de limitação
Você também pode limitar o tráfego de rede de saída de um aplicativo especificando
uma taxa de limitação na Política de QoS.
Uma política de QoS que define limites de limitação determina a taxa de tráfego de
rede de saída. Por exemplo, para gerenciar os custos da WAN, um departamento de TI
pode implementar um contrato de nível de serviço que especifica que um servidor de
arquivos nunca pode fornecer downloads além de uma taxa específica.
Usar a política de QoS para aplicar valores DSCP e taxas

de limitação
Você também pode usar a Política de QoS para aplicar valores DSCP e limitar as taxas de
tráfego de rede de saída ao seguinte:
Enviando o aplicativo e o caminho do diretório
Endereços ou prefixos de endereço IPv4 ou IPv6 de origem e de destino
Protocolo – Protocolo de Controle de Transmissão (TCP) e UDP (User Datagram

Protocol)
Portas de origem e de destino e intervalos de porta (TCP ou UDP)
Grupos específicos de usuários ou computadores por meio da implantação no

Política de Grupo
Usando esses controles, você pode especificar uma política QoS com um valor DSCP de
46 para um aplicativo VoIP, permitindo que os roteadores coloquem pacotes VoIP em
uma fila de baixa latência ou você pode usar uma política de QoS para limitar um
conjunto de tráfego de saída dos servidores a 512 quilobytes por segundo (KBps) ao
enviar da porta TCP 443.
Você também pode aplicar a política de QoS a um aplicativo específico que tenha
requisitos especiais de largura de banda. Para obter mais informações, consulte
Cenários de Política de QoS.
Vantagens da política de QoS

Com a Política de QoS, você pode configurar e impor políticas de QoS que não podem
ser configuradas em roteadores e comutadores. A Política de QoS fornece as seguintes
vantagens.
1. Nível de detalhes: É difícil criar políticas de QoS no nível do usuário em roteadores
ou comutadores, especialmente se o computador do usuário estiver configurado
usando a atribuição de endereço IP dinâmico ou se o computador não estiver
conectado a portas fixas de comutador ou roteador, como é frequentemente o
caso com computadores portáteis. Por outro lado, a Política de QoS facilita a
configuração de uma política de QoS no nível do usuário em um controlador de
domínio e propaga a política para o computador do usuário.
2. Flexibilidade. Independentemente de onde ou como um computador se conecta à

rede, a política de QoS é aplicada – o computador pode se conectar usando WiFi
ou Ethernet de qualquer local. Para políticas de QoS no nível do usuário, a política
de QoS é aplicada em qualquer dispositivo compatível em qualquer local em que o
usuário faça logon.
3. Segurança: Se o departamento de TI criptografar o tráfego dos usuários de ponta

a ponta usando o IPsec (Internet Protocol Security), você não poderá classificar o
tráfego em roteadores com base em qualquer informação acima da camada DE IP
no pacote (por exemplo, uma porta TCP). No entanto, usando a Política de QoS,
você pode classificar pacotes no dispositivo final para indicar a prioridade dos
pacotes no cabeçalho IP antes que as cargas de IP sejam criptografadas e os
pacotes sejam enviados.
4. Desempenho: Algumas funções de QoS, como a limitação, são melhor executadas

quando estão mais próximas da origem. A Política de QoS move essas funções de
QoS mais próximas da origem.
5. Gerenciamento: A Política de QoS aprimora a capacidade de gerenciamento de

rede de duas maneiras:
a. Como ele é baseado em Política de Grupo, você pode usar a Política de QoS
para configurar e gerenciar um conjunto de políticas de QoS de
usuário/computador sempre que necessário e em um computador controlador de
domínio central.
b. A Política de QoS facilita a configuração do usuário/computador fornecendo um

mecanismo para especificar políticas por URL (Uniform Resource Locator) em vez
de especificar políticas com base nos endereços IP de cada um dos servidores em
que as políticas de QoS precisam ser aplicadas. Por exemplo, suponha que sua
rede tenha um cluster de servidores que compartilham uma URL comum. Usando a
Política de QoS, você pode criar uma política com base na URL comum, em vez de
criar uma política para cada servidor no cluster, com cada política com base no
endereço IP de cada servidor.
Para obter o próximo tópico neste guia, consulte Introdução com a Política de QoS.
Introdução com a política de QoS
Você pode usar os tópicos a seguir para começar com a política de QoS (qualidade de
serviço).
Como funciona a política de QoS

Arquitetura de política de QoS
Cenários de política de QoS
Para o primeiro tópico deste guia, consulte política de QoS (qualidade de serviço).
Como funciona a política de QoS
Ao iniciar ou obter configurações atualizadas de usuário ou computador Política de

Grupo configurações para QoS, o processo a seguir ocorre.
1. O Política de Grupo recupera as configurações de usuário ou computador Política

de Grupo configurações do Active Directory.
2. O Política de Grupo de dados informa à extensão de Client-Side QoS que houve

alterações nas políticas de QoS.
3. A extensão de Client-Side QoS envia uma notificação de evento de política de QoS

para o Módulo de Inspeção de QoS.
4. O Módulo de Inspeção de QoS recupera as políticas de QoS de usuário ou

computador e as armazena.
Quando um novo ponto de extremidade da Camada de Transporte (conexão TCP ou

tráfego UDP) é criado, o processo a seguir ocorre.
1. O componente Camada de Transporte da pilha TCP/IP informa o Módulo de

Inspeção de QoS.
2. O Módulo de Inspeção de QoS compara os parâmetros do ponto de extremidade

da Camada de Transporte com as políticas de QoS armazenadas.
3. Se uma correspondência for encontrada, o Módulo de Inspeção de QoS contatará

o Pacer.sys para criar um fluxo, uma estrutura de dados que contém o valor DSCP
e as configurações de contenção de tráfego da política de QoS correspondente. Se
houver várias políticas de QoS que corresponderem aos parâmetros do ponto de
extremidade da Camada de Transporte, a política de QoS mais específica será
usada.
4. Pacer.sys armazena o fluxo e retorna um número de fluxo correspondente ao fluxo

para o Módulo de Inspeção de QoS.
5. O Módulo de Inspeção de QoS retorna o número do fluxo para a Camada de

Transporte.
6. A Camada de Transporte armazena o número de fluxo com o ponto de
extremidade da Camada de Transporte.
Quando um pacote correspondente a um ponto de extremidade da Camada de

Transporte marcado com um número de fluxo é enviado, o processo a seguir ocorre.
1. A Camada de Transporte marca internamente o pacote com o número de fluxo.
2. A camada de rede Pacer.sys para o valor DSCP correspondente ao número de fluxo

do pacote.
3. Pacer.sys retorna o valor DSCP para a Camada de Rede.
4. A Camada de Rede altera o campo IPv4 TOS ou o campo Classe de Tráfego IPv6
para o valor DSCP especificado por Pacer.sys e, para pacotes IPv4, calcula a caixa
de verificação final do header IPv4.
5. A Camada de Rede entrega o pacote para a Camada de Enquadramento.
6. Como o pacote foi marcado com um número de fluxo, a Camada de

Enquadramento entrega o pacote para Pacer.sys NDIS 6.x.
7. Pacer.sys usa o número de fluxo do pacote para determinar se o pacote precisa ser
throttled e, se for o caso, agenda o pacote para envio.
8. Pacer.sys entrega o pacote imediatamente (se não houver nenhuma interroção de

tráfego) ou conforme agendado (se houver uma throttling de tráfego) para o NDIS
6.x para transmissão pelo adaptador de rede apropriado.
Esses processos de QoS baseados em políticas oferecem as seguintes vantagens.
A inspeção do tráfego para determinar se uma política de QoS se aplica é feita por
ponto de extremidade da Camada de Transporte, em vez de por pacote.
Não há nenhum impacto no desempenho para o tráfego que não corresponder a

uma política de QoS.
Os aplicativos não precisam ser modificados para aproveitar o serviço diferenciado

baseado em DSCP ou a throttling de tráfego.
As políticas de QoS podem ser aplicadas ao tráfego protegido com IPsec.
Para o próximo tópico neste guia, consulte Arquitetura de política de QoS.
Para o primeiro tópico deste guia, consulte Política de QoS (Qualidade de Serviço).
Arquitetura de política de QoS
Você pode usar este tópico para saber mais sobre a arquitetura da Política de QoS.
A figura a seguir mostra a arquitetura do QoS baseado em política.
A arquitetura do QoS baseado em política consiste nos seguintes componentes:
Política de Grupo Serviço de Cliente. Um serviço de Windows que gerencia

configurações de usuário e computador Política de Grupo configurações.
Política de Grupo motor. Um componente do Serviço de Cliente Política de Grupo

que recupera as configurações do usuário e do computador Política de Grupo
configurações do Active Directory após a inicialização e verifica periodicamente as
alterações (por padrão, a cada 90 minutos). Se forem detectadas alterações, o
mecanismo de Política de Grupo recuperará as novas configurações de Política de
Grupo. O mecanismo de Política de Grupo processa os GPOs de entrada e informa
a Extensão do Lado do Cliente do QoS quando as políticas de QoS são atualizadas.
Extensão do lado do cliente QoS. Um componente do serviço cliente Política de

Grupo que aguarda uma indicação do mecanismo de Política de Grupo de que as
políticas de QoS foram alteradas e informa o Módulo de Inspeção de QoS.
Pilha TCP/IP. A pilha TCP/IP que inclui suporte integrado para IPv4 e IPv6 e dá
suporte Windows Plataforma de Filtragem.
Inspeção de QoS. Componente do módulo A na pilha TCP/IP que aguarda por

indicações de alterações de política de QoS da Extensão do Lado do Cliente do
QoS, recupera as configurações de política do QoS e interage com a Camada de
Transporte e Pacer.sys para marcar internamente o tráfego que corresponde às
políticas de QoS.
NDIS 6.x. Uma interface padrão entre drivers de rede no modo kernel e o sistema
operacional em sistemas operacionais Windows Servidor e Cliente. O NDIS 6.x dá
suporte a filtros leves, que é um modelo de driver simplificado para drivers
intermediários NDIS e miniportores que proporcionam melhor desempenho.
NPI (Interface do Provedor de Rede) do QoS. Uma interface para drivers no modo
kernel interagirem com Pacer.sys.
Pacer.sys. Um driver de filtro leve NDIS 6.x que controla o agendamento de

pacotes para QoS baseado em política e para o tráfego de aplicativos que usam as
APIs de QoS Genérico (GQoS) e controle de tráfego (TC). Pacer.sys substituído
Psched.sys no Windows Server 2003 e Windows XP. Pacer.sys é instalado com o
componente Agendador de Pacotes QoS das propriedades de uma conexão de
rede ou adaptador.
Para o próximo tópico neste guia, consulte Cenários de Política de QoS.
Para obter o primeiro tópico neste guia, consulte Política de Qualidade de Serviço (QoS).
Cenários de política de QoS
Você pode usar este tópico para analisar cenários hipotéticos que demonstram como,
quando e por que usar a Política de QoS.
Os dois cenários neste tópico são:
1. Priorizar o tráfego de rede para um aplicativo de linha de negócios

2. Priorizar o tráfego de rede para um aplicativo de servidor HTTP
７ Observação
Algumas seções deste tópico contêm etapas gerais que você pode executar para
executar as ações descritas. Para obter instruções mais detalhadas sobre como
gerenciar a política de QoS, consulte Gerenciar política de QoS.
Cenário 1: Priorizar o tráfego de rede para um

aplicativo de linha de negócios
Nesse cenário, um departamento de IT tem várias metas que podem ser feitas usando a
Política de QoS:
Forneça melhor desempenho de rede para aplicativos críticos.

Forneça melhor desempenho de rede para um conjunto chave de usuários
enquanto eles estão usando um aplicativo específico.
Verifique se o aplicativo de Backup de dados de toda a empresa não impede o
desempenho da rede usando muita largura de banda ao mesmo tempo.
O departamento de IT decide configurar a Política de QoS para priorizar aplicativos

específicos usando valores DSCP (Ponto de Código do Serviço de Diferenciação) para
classificar o tráfego de rede e configurar seus roteadores para fornecer tratamento
preferencial para o tráfego de prioridade mais alta.
７ Observação
Para obter mais informações sobre o DSCP, consulte a seção Definir prioridade de
QoS por meio de um ponto de código Serviços Diferenciados no tópico Política de
QoS (qualidade de serviço).
Além dos valores DSCP, as políticas de QoS podem especificar uma taxa de aceleração.
A limitação tem o efeito de limitar todo o tráfego de saída que corresponde à Política
de QoS a uma taxa de envio específica.
Configuração de política de QoS

Com três metas separadas para realizar, o administrador de IT decide criar três políticas
de QoS diferentes.
Política de QoS para servidores de aplicativos LOB

O primeiro aplicativo crítico para o qual o departamento de IT cria uma Política de Qo
Enterprise S é um aplicativo ERP (planejamento de recursos) de toda a empresa. O
aplicativo ERP é hospedado em vários computadores que estão executando Windows
Server 2016. Nesse Active Directory Domain Services, esses computadores são membros
de uma UO (unidade da organização) que foi criada para servidores de aplicativos lob
(linha de negócios). O componente do lado do cliente para o aplicativo ERP é instalado
em computadores que estão executando Windows 10 e Windows 8.1.
No Política de Grupo, um administrador de IT seleciona o GPO (objeto Política de

Grupo) ao qual a política de QoS será aplicada. Usando o assistente de política de QoS,
o administrador de IT cria uma política de QoS chamada "Política lob do servidor" que
especifica um valor DSCP de alta prioridade de 44 para todos os aplicativos, qualquer
endereço IP, TCP e UDP e número da porta.
A política de QoS é aplicada somente aos servidores LOB vinculando o GPO à UO que
contém apenas esses servidores, por meio da ferramenta Console de Gerenciamento de
Política de Grupo (GPMC). Essa política de LOB do servidor inicial aplica o valor DSCP de
alta prioridade sempre que o computador envia o tráfego de rede. Essa política de QoS
pode ser editada posteriormente (na ferramenta Editor de Objeto de Política de Grupo)
para incluir os números de porta do aplicativo ERP, que limita a política a ser aplicada
somente quando o número da porta especificado é usado.
Política de QoS para o grupo financeiro
Embora muitos grupos dentro da empresa acessem o aplicativo ERP, o grupo financeiro
depende desse aplicativo ao lidar com clientes, e o grupo requer um desempenho
consistentemente alto do aplicativo.
Para garantir que o grupo financeiro possa dar suporte a seus clientes, a política de QoS
deve classificar o tráfego desses usuários como de alta prioridade. No entanto, a política
não deve ser aplicada quando os membros do grupo financeiro usam aplicativos
diferentes do aplicativo ERP.
Por isso, o departamento de IT define uma segunda política de QoS chamada "Política
lob do cliente" na ferramenta Editor de Objeto de Política de Grupo que aplica um valor
DSCP de 60 quando o grupo de usuários financeiros executa o aplicativo ERP.
Política de QoS para um aplicativo de backup

Um aplicativo de backup separado está em execução em todos os computadores. Para
garantir que o tráfego do aplicativo de backup não use todos os recursos de rede
disponíveis, o departamento de IT cria uma política de dados de backup. Essa política de
backup especifica um valor DSCP de 1 com base no nome executável do aplicativo de
backup, que é backup.exe.
Um terceiro GPO é criado e implantado para todos os computadores cliente no

domínio. Sempre que o aplicativo de backup envia dados, o valor DSCP de baixa
prioridade é aplicado, mesmo se ele se origina de computadores no departamento
financeiro.
７ Observação
O tráfego de rede sem uma Política de QoS envia com um valor DSCP de 0.
Políticas de cenário
A tabela a seguir resume as políticas de QoS para esse cenário.
Nome Valor Taxa de Aplicado às Descrição

de DSCP aceleração unidades da
política organização
[Sem 0 Nenhum [Sem implantação] Melhor esforço (padrão) para tráfego

política] não classificado.
Dados 1 Nenhum Todos os clientes Aplica um valor DSCP de baixa

de prioridade para esses dados em massa.
backup
Nome Valor Taxa de Aplicado às Descrição
de DSCP aceleração unidades da
política organização
LOB do 44 Nenhum UO do computador Aplica DSCP de alta prioridade para

servidor para servidores ERP tráfego de servidor ERP
LOB do 60 Nenhum Grupo de usuários Aplica DSCP de alta prioridade para

cliente financeiros tráfego de cliente ERP
７ Observação
Os valores DSCP são representados na forma decimal.
Com as políticas de QoS definidas e aplicadas usando Política de Grupo, o tráfego de

rede de saída recebe o valor DSCP especificado pela política. Os roteadores fornecem
tratamento diferencial com base nesses valores DSCP usando a fila. Para esse
departamento de IT, os roteadores são configurados com quatro filas: alta prioridade,
prioridade intermediária, melhor esforço e baixa prioridade.
Quando o tráfego chega ao roteador com valores DSCP de "Política lob do servidor" e
"política lob do cliente", os dados são colocados em filas de alta prioridade. O tráfego
com um valor DSCP de 0 recebe um nível de serviço de melhor esforço. Pacotes com um
valor DSCP de 1 (do aplicativo de backup) recebem tratamento de baixa prioridade.
Pré-requisitos para priorizar um aplicativo de linha de

negócios
Para concluir essa tarefa, certifique-se de atender aos seguintes requisitos:
Os computadores envolvidos estão executando sistemas operacionais compatíveis

com QoS.
Os computadores envolvidos são membros de um domínio Active Directory

Domain Services (AD DS) para que possam ser configurados usando Política de
Grupo.
As redes TCP/IP são configuradas com roteadores configurados para DSCP (RFC
2474). Para obter mais informações, consulte RFC 2474 .
Os requisitos de credenciais administrativas são atendidos.
Para concluir essa tarefa, você deve ser capaz de criar e implantar Política de Grupo
Objetos.
Configurando o ambiente de teste para priorizar um aplicativo de

linha de negócios
Para configurar o ambiente de teste, conclua as tarefas a seguir.
Crie um AD DS domínio com clientes e usuários agrupados em unidades da

organização. Para obter instruções sobre como implantar AD DS, consulte o Guia
de rede principal.
Configure os roteadores para enfil de forma diferencial com base em valores DSCP.
Por exemplo, o valor DSCP 44 entra em uma fila "Platinum" e todos os outros são
ponderados com fila justa.
７ Observação
Você pode exibir valores DSCP usando capturas de rede com ferramentas como
Monitor de Rede. Depois de executar uma captura de rede, você pode observar o
campo TOS nos dados capturados.
Etapas para priorizar um aplicativo de linha de negócios

Para priorizar um aplicativo de linha de negócios, conclua as seguintes tarefas:
1. Crie e vincule um GPO (objeto Política de Grupo) com uma política de QoS.
2. Configure os roteadores para tratar diferencialmente um aplicativo de linha de

negócios (usando en fila) com base nos valores DSCP selecionados. Os
procedimentos dessa tarefa variam dependendo do tipo de roteadores que você
tem.
Cenário 2: Priorizar o tráfego de rede para um

aplicativo de servidor HTTP
No Windows Server 2016, a QoS baseada em políticas inclui o recurso Políticas baseadas
em URL. As Políticas de URL permitem que você gerencie a largura de banda para
servidores HTTP.
Muitos Enterprise aplicativos são desenvolvidos e hospedados em servidores Web
Serviços de Informações da Internet (IIS), e os aplicativos Web são acessados de
navegadores em computadores cliente.
Nesse cenário, suponha que você gerencie um conjunto de servidores IIS que
hospedam vídeos de treinamento para todos os funcionários da sua organização. Seu
objetivo é garantir que o tráfego desses servidores de vídeo não sobrecarregará sua
rede e garantir que o tráfego de vídeo seja diferenciado do tráfego de voz e dados na
rede.
A tarefa é semelhante à tarefa no Cenário 1. Você projetará e definirá as configurações

de gerenciamento de tráfego, como o valor DSCP para o tráfego de vídeo e a taxa de
limite da mesma maneira que faria para os aplicativos de linha de negócios. Mas ao
especificar o tráfego, em vez de fornecer o nome do aplicativo, você só insinuou a URL à
qual seu aplicativo de servidor HTTP responderá: por exemplo, https://hrweb/training.
７ Observação
Você não pode usar políticas de QoS baseadas em URL para priorizar o tráfego de
rede para computadores que executam sistemas operacionais Windows que foram
lançados antes do Windows 7 e Windows Server 2008 R2.
Regras de precedência para políticas baseadas em URL

Todas as URLs a seguir são válidas e podem ser especificadas na Política de QoS e
aplicadas simultaneamente a um computador ou um usuário:
https://video
https://training.hr.mycompany.com
https://10.1.10.249:8080/tech
https://*/ebooks
Mas qual deles receberá precedência? As regras são simples. As políticas baseadas em
URL são priorizadas em uma ordem de leitura da esquerda para a direita. Portanto, da
prioridade mais alta para a prioridade mais baixa, os campos de URL são:
1. Esquema de URL
2. Host de URL
3. Porta de URL
4. Caminho da URL
Os detalhes são os seguinte:
1. Esquema de URL
https:// tem uma prioridade mais alta do que https:// .
2. Host de URL
Da prioridade mais alta para a mais baixa, elas são:
1. Nome do host
2. Endereço IPv6
3. Endereço IPv4
4. Curinga
No caso do nome do host, um nome de host com mais elementos pontilhados (mais
profundidade) tem uma prioridade mais alta do que um nome de host com menos
elementos pontilhados. Por exemplo, entre os seguintes nomes de host:
video.internal.training.hr.mycompany.com (profundidade = 6)
selfguide.training.mycompany.com (profundidade = 4)
treinamento (profundidade = 1)
biblioteca (profundidade = 1)
video.internal.training.hr.mycompany.com tem a prioridade mais alta e

selfguide.training.mycompany.com tem a próxima prioridade mais alta. O
treinamento e a biblioteca compartilham a mesma prioridade mais baixa.
3. Porta de URL
Um número de porta específico ou implícito tem uma prioridade mais alta do que uma
porta curinga.
4. Caminho da URL
Como um nome de host, um caminho de URL pode consistir em vários elementos.
Aquele com mais elementos sempre tem uma prioridade mais alta do que aquela com
menos. Por exemplo, os seguintes caminhos são listados por prioridade:
1. /ebooks/tech/windows/networking/qos
2. /ebooks/tech/windows/
3. /ebooks
4. /
Se um usuário optar por incluir todos os subdireários e arquivos seguindo um caminho

de URL, esse caminho de URL terá uma prioridade mais baixa do que teria se a escolha
não fosse feita.
Um usuário também pode optar por especificar um endereço IP de destino em uma

política baseada em URL. O endereço IP de destino tem uma prioridade mais baixa do
que qualquer um dos quatro campos de URL descritos anteriormente.
Política de exemplo
Uma política Deple é especificada pela ID do protocolo, endereço IP de origem, porta
de origem, endereço IP de destino e porta de destino. Uma política de Instância sempre
tem uma precedência maior do que qualquer política baseada em URL.
Se uma política Deplor já estiver aplicada a um usuário, uma nova política baseada em
URL não causará conflitos em nenhum dos computadores cliente desse usuário.
Para o próximo tópico neste guia, consulte Gerenciar política de QoS.
Gerenciar política de QoS
Você pode usar este tópico para saber mais sobre como usar o assistente de Política de
QoS para criar, editar ou excluir uma Política de QoS.
７ Observação
Além deste tópico, a documentação de gerenciamento de política de QoS a seguir

está disponível.
Erros e eventos de política de QoS
Em Windows sistemas operacionais, a Política de QoS combina a funcionalidade da QoS

baseada em padrões com a capacidade de gerenciamento de Política de Grupo. A
configuração dessa combinação facilita a aplicação de políticas de QoS para Política de
Grupo Objetos. Windows inclui um Assistente de Política de QoS para ajudá-lo a realizar
as tarefas a seguir.
Criar uma política de QoS
Exibir, editar ou excluir uma política de QoS
Criar uma política de QoS

Antes de criar uma política de QoS, é importante entender os dois principais controles
de QoS usados para gerenciar o tráfego de rede:
Valor DSCP
Taxa de aceleração
Priorizando o tráfego com DSCP

Conforme o exemplo anterior de aplicativo de linha de negócios, você pode definir a
prioridade do tráfego de rede de saída usando Especificar Valor DSCP para configurar
uma política de QoS com um valor DSCP específico.
Conforme descrito em RFC 2474, o DSCP permite que os valores de 0 a 63 sejam
especificados dentro do campo TOS de um pacote IPv4 e dentro do campo Classe de
Tráfego em IPv6. Os roteadores de rede usam o valor DSCP para classificar pacotes de
rede e enfilá-los adequadamente.
７ Observação
Por padrão, Windows tráfego tem um valor DSCP de 0.
O número de filas e seu comportamento de priorização devem ser planejados como

parte da estratégia de QoS de sua organização. Por exemplo, sua organização pode
optar por ter cinco filas: tráfego sensível à latência, tráfego de controle, tráfego
comercialmente crítico, tráfego de melhor esforço e tráfego de transferência de dados
em massa.
Acelerando o tráfego
Juntamente com valores DSCP, a limitação é outro controle fundamental para gerenciar
a largura de banda da rede. Conforme mencionado anteriormente, você pode usar a
configuração Especificar Taxa de Aceleração para configurar uma política de QoS com
uma taxa de aceleração específica para o tráfego de saída. Usando a limitação, uma
política de QoS limita o tráfego de rede de saída a uma taxa de limitação especificada. A
aceleração e a marcação de DSCP podem ser usadas juntas para gerenciar o tráfego de
maneira eficiente.
７ Observação
Por padrão, a caixa de seleção Especificar Taxa de Aceleração não está marcada.
Para criar uma política de QoS, edite as configurações de um GPO (objeto Política de
Grupo) de dentro da ferramenta Console de Gerenciamento de Política de Grupo
(GPMC). O GPMC abre o Editor de Objeto de Política de Grupo.
Os nomes das políticas de QoS devem ser exclusivos. Como as políticas são aplicadas a
servidores e usuários finais depende de onde a política de QoS é armazenada no Editor
de Objeto de Política de Grupo:
Uma política de QoS em Configuração do Computador\Windows

Configurações\Política de QoS se aplica aos computadores, independentemente
do usuário que está conectado no momento. Normalmente, você usa políticas de
QoS baseadas no computador em servidores.
Uma política de QoS em Configuração do Usuário\Windows Configurações\Política
de QoS se aplica aos usuários depois que eles fazem logona, independentemente
de qual computador eles fizeram logona.
Para criar uma nova política de QoS com o assistente de Política de

QoS
No Editor de Objeto de Política de Grupo, clique com o botão direito do mouse

em qualquer um dos nós da Política de QoS e clique em Criar uma nova política.
Página 1 do assistente – Perfil de Política

Na primeira página do assistente de Política de QoS, você pode especificar um nome de
política e configurar como o QoS controla o tráfego de rede de saída.
Para configurar a página Perfil da Política do Assistente de QoS

Baseado em Política
1. Em Nome da política, digite um nome para a política de QoS. O nome deve

identificar exclusivamente a política.
2. Opcionalmente, use Especificar Valor DSCP para habilitar a marcação DSCP e

configure um valor DSCP entre 0 e 63.
3. Como opção, use Especificar Taxa de Aceleração para habilitar a aceleração de

tráfego e configurar a taxa de aceleração. O valor da taxa de aceleração deve ser
maior que 1 e você pode especificar as unidades KBps (quilobytes por segundo)
ou MBps (megabytes por segundo).
Página 2 do Assistente – Nome do Aplicativo

Na segunda página do assistente de Política de QoS, você pode aplicar a política a
todos os aplicativos, a um aplicativo específico, conforme identificado por seu nome
executável, a um caminho e ao nome do aplicativo ou aos aplicativos de servidor HTTP
que lidam com solicitações para uma URL específica.
Todos os aplicativos especificam que as configurações de gerenciamento de

tráfego na primeira página do assistente de Política de QoS se aplicam a todos os
aplicativos.
Somente aplicativos com esse nome executável especificam que as configurações
de gerenciamento de tráfego na primeira página do assistente de Política de QoS
são para um aplicativo específico. O nome do arquivo executável deve terminar
com a extensão de nome de arquivo .exe.
Somente aplicativos de servidor HTTP que respondem a solicitações para essa

URL especificam que as configurações de gerenciamento de tráfego na primeira
página do assistente de Política de QoS se aplicam somente a determinados
aplicativos de servidor HTTP.
Como opção, você pode inserir o caminho do aplicativo. Para especial um caminho de
aplicativo, inclua o caminho com o nome do aplicativo. O caminho pode incluir variáveis
de ambiente. Por exemplo, %ProgramFiles%\Caminho do Meu
Aplicativo\MeuAplicativo.exe ou c:\arquivos de programas\caminho do meu
aplicativo\meuaplicativo.exe.
７ Observação
O caminho do aplicativo não pode incluir um caminho que seja resolvido para um
link simbólico.
A URL deve estar em conformidade com o RFC 1738 , na forma de . Você pode usar
um curinga, ‘*' , <hostname> para e/ <port> ou , por exemplo, https://training.\*/,
https://\*.\* , mas o curinga não pode denotar uma substring de <hostname> ou
<port> .
Em outras palavras, nem https://my\*site/ nem https://\*training\*/ é válido.
Opcionalmente, você pode verificar Incluir subdireários e arquivos para executar a

correspondência em todos os subdireários e arquivos após uma URL. Por exemplo, se
essa opção estiver marcada e a URL for https://training , a Política de QoS considerará
solicitações para https://training/video uma boa combinação.
Para configurar a página Nome do Aplicativo do assistente de

Política de QoS
1. Nesta política de QoS a ser aplicada, selecione Todos os aplicativos ou Somente

aplicativos com esse nome executável.
2. Se você selecionar Somente aplicativos com este nome executável, especifique o

nome de um executável que termine com a extensão de nome de arquivo .exe.
Página 3 do assistente – Endereços IP

Na terceira página do assistente de Política de QoS, você pode especificar condições de
endereço IP para a política de QoS, incluindo o seguinte:
Todos os endereços IPv4 ou IPv6 de origem ou endereços IPv4 ou IPv6 de origem

específicos
Todos os endereços IPv4 ou IPv6 de destino ou endereços IPv4 ou IPv6 de destino

específicos
Se você selecionar Somente para o seguinte endereço IP de origem ou Somente para

o seguinte endereço IP de destino, será necessário digitar uma das seguintes opções:
Um endereço IPv4, como 192.168.1.1
Um prefixo de endereço IPv4 usando a notação de comprimento de prefixo de

rede, como 192.168.1.0/24
Um endereço IPv6, como 3ffe:ffff::1
Um prefixo de endereço IPv6, como 3ffe:ffff::/48
Se você selecionar Somente para o endereço IP de origem a seguir e Somente para o

endereço IP de destino a seguir, os endereços ou prefixos de endereço deverão ser
baseados em IPv4 ou IPv6.
Se você especificou a URL para aplicativos de servidor HTTP na página anterior do

assistente, observará que o endereço IP de origem para a política de QoS nessa página
do assistente está es cinza.
Isso é verdadeiro porque o endereço IP de origem é o endereço do servidor HTTP e não

é configurável aqui. Por outro lado, você ainda pode personalizar a política
especificando o endereço IP de destino. Isso possibilita que você crie políticas diferentes
para clientes diferentes usando os mesmos aplicativos de servidor HTTP.
Para configurar a página Endereços IP do assistente de Política de

QoS
1. Em Esta política de QoS se aplica a (origem), selecione Qualquer endereço IP de
origem ou Somente para o endereço de origem IP a seguir.
2. Se você selecionou Somente o endereço de origem IP a seguir, especifique um
endereço ou prefixo IPv4 ou IPv6.
3. Em Esta política de QoS se aplica a (destino), selecione Qualquer endereço de

destino ou Somente para o endereço de destino IP a seguir.
4. Se você selecionou Somente para o endereço de destino IP a seguir, especifique

um endereço ou prefixo IPv4 ou IPv6 que corresponda ao tipo de endereço ou
prefixo especificado para o endereço de origem.
Página 4 do Assistente – Protocolos e Portas

Na quarta página do assistente de Política de QoS, você pode especificar os tipos de
tráfego e as portas que são controladas pelas configurações na primeira página do
assistente. É possível especificar:
Tráfego TCP, tráfego UDP ou os dois
Todas as portas de origem, um intervalo de portas de origem ou uma porta de

origem específica
Todas as portas de destino, um intervalo de portas de destino ou uma porta de

destino específica
Para configurar a página Protocolos e Portas do assistente de

Política de QoS
1. Em Selecionar o protocolo ao qual esta política de QoS se aplica, selecione TCP,
UDP ou TCP e UDP.
2. Em Especifique o número da porta de origem, selecione De qualquer porta de

origem ou Deste número de porta de origem.
3. Se você selecionou Desse número da porta de origem, digite um número da

porta entre 1 e 65535.
Opcionalmente, você pode especificar um intervalo de portas, no formato

"Baixo:Alto", em que Baixo e Alto representam os limites inferiores e os limites
superiores do intervalo de portas, inclusive. Baixo e Alto devem ser um número
entre 1 e 65535. Não são permitidos espaços entre o caractere de dois pontos (:) e
os números.
4. Em Especifique o número da porta de destino, selecione Para qualquer porta de
destino ou Para este número de porta de destino.
5. Se você selecionou Para este número de porta de destino na etapa anterior, digite
um número de porta entre 1 e 65535.
Para concluir a criação da nova política de QoS, clique em Concluir na página

Protocolos e Portas do assistente de Política de QoS. Quando concluída, a nova política
de QoS é listada no painel de detalhes do Editor de Objeto de Política de Grupo.
Para aplicar as configurações de política de QoS a usuários ou computadores, vincule o

GPO no qual as políticas de QoS estão localizadas a um contêiner Active Directory
Domain Services, como um domínio, um site ou uma UO (unidade organizacional).
Exibir, editar ou excluir uma política de QoS

As páginas do assistente de Política de QoS descritas anteriormente correspondem às
páginas de propriedades exibidas quando você exibe ou edita as propriedades de uma
política.
Para exibir as propriedades de uma política de QoS

Clique com o botão direito do mouse no nome da política no painel de detalhes
do Editor de Objeto de Política de Grupo e clique em Propriedades.
O Editor de Objeto de Política de Grupo exibe a página de propriedades com as

seguintes guias:
Perfil da Política
Nome do Aplicativo
Endereços IP
Protocolos e portas
Para editar uma política de QoS

Clique com o botão direito do mouse no nome da política no painel de Editor de
Objeto de Política de Grupo e clique em Editar política existente.
O Editor de Objeto de Política de Grupo exibe a caixa de diálogo Editar uma

política de QoS existente.
Para excluir uma política de QoS
Clique com o botão direito do mouse no nome da política no painel de detalhes
do Editor de Objeto de Política de Grupo e clique em Excluir política.
Relatório do GPMC da Política de QoS

Depois de aplicar várias políticas de QoS em sua organização, pode ser útil ou
necessário revisar periodicamente como as políticas são aplicadas. Um resumo das
políticas de QoS para um usuário ou computador específico pode ser exibido usando
relatórios do GPMC.
Para executar o Assistente Política de Grupo resultados para um

relatório de políticas de QoS
No GPMC, clique com o botão direito do mouse no nó Política de Grupo
Resultados e selecione a opção de menu para o Assistente Política de Grupo
Resultados.
Depois Política de Grupo resultados são gerados, clique na guia Configurações dados.
Na guia Configurações, as políticas de QoS podem ser encontradas nos nós
"Configuração do Computador\Windows Configurações\Política de QoS" e
"Configuração do Usuário\Windows Configurações\Política de QoS".
Na guia Configurações, as políticas de QoS são listadas por seus nomes de política de
QoS com seu valor DSCP, taxa de aceleração, condições de política e GPO vencedor
listados na mesma linha..
A Política de Grupo de resultados identifica exclusivamente o GPO vencedor. Quando

vários GPOs têm políticas de QoS com o mesmo nome de política de QoS, o GPO com a
maior precedência de GPO é aplicado. Esse é o GPO vencedor. Políticas de QoS
conflitantes (identificadas pelo nome da política) anexadas a um GPO de prioridade
mais baixa não são aplicadas. Observe que as prioridades de GPO definem quais
políticas de QoS são implantadas no site, no domínio ou na UO, conforme apropriado.
Após a implantação, em um nível de usuário ou computador, as Regras de Precedência
de Política de QoS determinam qual tráfego é permitido e bloqueado.
O valor DSCP da política de QoS, a taxa de aceleração e as condições da política

também são visíveis Editor de Objeto de Política de Grupo (GPOE)
Configurações avançadas para usuários remotos e em
roaming
Com a Política de QoS, o objetivo é gerenciar o tráfego na rede de uma empresa. Em
cenários móveis, os usuários podem estar enviando tráfego na rede corporativa ou fora
dele. Como as políticas de QoS não são relevantes enquanto estão fora da rede da
empresa, as políticas de QoS são habilitadas somente em interfaces de rede conectadas
à empresa para Windows 8, Windows 7 ou Windows Vista.
Por exemplo, um usuário pode conectar seu computador portátil à rede da empresa por
meio da VPN (rede virtual privada) de uma cafeteira. Para VPN, o interface de rede física
(como sem fio) não terá políticas de QoS aplicadas. No entanto, a interface VPN terá
políticas de QoS aplicadas porque se conecta à empresa. Se o usuário entrar
posteriormente na rede de outra empresa que não tenha uma relação de confiança AD
DS, as políticas de QoS não serão habilitadas.
Observe que esses cenários móveis não se aplicam a cargas de trabalho de servidor. Por
exemplo, um servidor com vários adaptadores de rede pode ficar na borda da rede de
uma empresa. O departamento de IT pode optar por fazer com que as políticas de QoS
reduzam o tráfego que efeça a empresa; no entanto, esse adaptador de rede que envia
esse tráfego de saída não se conecta necessariamente à rede corporativa. Por esse
motivo, as políticas de QoS estão sempre habilitadas em todos os interfaces de rede de
um computador que executa Windows Server 2012.
７ Observação
A habilitação seletiva só se aplica às políticas de QoS e não às configurações

avançadas de QoS discutidas a seguir neste documento.
Configurações avançadas de QoS

As configurações avançadas de QoS fornecem controles adicionais para que os
administradores de IT gerenciem o consumo de rede do computador e as marcações
DSCP. As configurações avançadas de QoS se aplicam somente no nível do computador,
enquanto as políticas de QoS podem ser aplicadas nos níveis do computador e do
usuário.
Para definir configurações avançadas de QoS

1. Clique em Configuração do Computador e clique Windows Configurações em
Política de Grupo.
2. Clique com o botão direito do mouse em Política de QoS e clique em QoS

avançado Configurações.
A figura a seguir mostra as duas guias avançadas de configurações de QoS:

Tráfego TCP de entrada e Substituição de Marcação DSCP.
７ Observação
As configurações avançadas Configurações QoS são configurações de Política de

Grupo computador.
Configurações avançadas de QoS: tráfego TCP de entrada
O Tráfego TCP de entrada controla o consumo de largura de banda TCP no lado do

receptor, enquanto as políticas de QoS afetam o tráfego TCP e UDP de saída.
Ao definir um nível de taxa de transferência inferior na guia Tráfego TCP de Entrada, o

TCP limitará o tamanho da janela de recebimento TCP anunciada. O efeito dessa
configuração aumentará as taxas de transferência e a utilização de link para conexões
TCP com larguras de banda ou latências mais altas (produto de atraso de largura de
banda). Por padrão, os computadores que executam Windows Server 2012, Windows 8,
Windows Server 2008 R2, Windows Server 2008 e Windows Vista são definidos como o
nível máximo de taxa de transferência.
A janela de recebimento TCP foi alterada no Windows Server 2012, Windows 8,

Windows Server 2008 R2, Windows Server 2008 e Windows Vista de versões anteriores
do Windows. As versões anteriores do Windows limitava a janela do lado de
recebimento do TCP a um máximo de 64 KB (quilobytes), enquanto Windows Server
2012, Windows 8, Windows Server 2008 R2, Windows Server 2008 e Windows Vista
tamanho dinâmico da janela do lado do recebimento de até 16 MB (megabytes). No
controle tráfego TCP de entrada, você pode controlar o nível de produtividade de
entrada definindo o valor máximo para o qual a janela de recebimento TCP pode
crescer. Os níveis correspondem aos valores máximos a seguir.
Nível de produtividade de entrada Máximo
0 64 KB
1 256 KB
Nível de produtividade de entrada Máximo
2 1 MB
3 16 MB
O tamanho real da janela pode ser um valor igual ou menor que o máximo,
dependendo das condições de rede.
Para definir a janela do lado de recebimento do TCP
1. No Editor de Objeto de Política de Grupo, clique em Política de Computador

Local, clique em Windows Configurações, clique com o botão direito do mouse em
Política de QoS e clique em QoS avançado Configurações.
2. Em TCP Recebendo Produtividade, selecione Configurar A produtividade de

recebimento de TCP e, em seguida, selecione o nível de produtividade que você
deseja.
3. Vincule o GPO à UO.
Configurações avançadas de QoS: Substituição de marcação DSCP
A Substituição de Marcação DSCP restringe a capacidade dos aplicativos de especificar

ou "marcar" valores DSCP diferentes daqueles especificados nas políticas de QoS.
Especificando que os aplicativos têm permissão para definir valores DSCP, os aplicativos
podem definir valores DSCP diferentes de zero.
Ao especificar Ignorar, os aplicativos que usam APIs de QoS terão seus valores DSCP
definidos como zero e somente as políticas de QoS poderão definir valores DSCP.
Por padrão, computadores que executam Windows Server 2016, Windows 10, Windows
Server 2012 R2, Windows 8.1, Windows Server 2012, Windows 8, Windows Server 2008
R2, Windows Server 2008 e Windows Vista permitem que os aplicativos especifiquem
valores DSCP; aplicativos e dispositivos que não usam as APIs de QoS não são
substituídos.
Multimídia sem fio e valores DSCP
A Wi-Fi Alliance estabeleceu uma certificação para WMM (Multimídia Sem Fio) que
define quatro categorias de acesso (WMM_AC) para priorizar o tráfego de rede
transmitido em uma rede Wi-Fi sem fio. As categorias de acesso incluem (na ordem da
prioridade mais alta para a mais baixa): voz, vídeo, melhor esforço e plano de fundo;
respectivamente abreviado como VO, VI, BE e BK. A especificação do WMM define quais
valores DSCP correspondem a cada uma das quatro categorias de acesso:
Valor DSCP Categoria de acesso do WMM
48-63 Voz (VO)
32-47 Vídeo (VI)
24-31, 0-7 Melhor esforço (BE)
8-23 Plano de fundo (BK)
Você pode criar políticas de QoS que usam esses valores DSCP para garantir que
computadores portáteis com adaptadores sem fio Wi-Fi Certified™ para WMM recebam
tratamento priorizado quando associados ao Wi-Fi Certified para pontos de acesso
wmm.
Regras de precedência de política de QoS

Semelhante às prioridades do GPO, as políticas de QoS têm regras de precedência para
resolver conflitos quando várias políticas de QoS se aplicam a um conjunto específico
de tráfego. Para o tráfego TCP ou UDP de saída, apenas uma política de QoS pode ser
aplicada por vez, o que significa que as políticas de QoS não têm um efeito cumulativo,
como onde as taxas de aceleração seriam somadas.
Em geral, a política de QoS com as condições mais correspondentes vence. Quando

várias políticas de QoS se aplicam, as regras se enquadram em três categorias: nível de
usuário versus nível de computador; aplicativo versus o exemplo de rede; e entre o
exemplo de rede.
Por exemplo, queremos dizer o endereço IP de origem, o endereço IP de destino, a porta

de origem, a porta de destino e o protocolo (TCP/UDP).
A política de QoS no nível do usuário tem precedência sobre a política de QoS no

nível do computador
Essa regra facilita muito o gerenciamento de GPOs de QoS pelos administradores de

rede, especialmente para políticas baseadas em grupo de usuários. Por exemplo, se o
administrador de rede quiser definir uma política de QoS para um grupo de usuários,
ele poderá apenas criar e distribuir um GPO para esse grupo. Eles não precisam se
preocupar com quais computadores esses usuários estão conectados e se esses
computadores terão políticas de QoS conflitantes definidas, porque, se houver um
conflito, a política no nível do usuário sempre terá precedência.
７ Observação
Uma política de QoS no nível do usuário só é aplicável ao tráfego gerado por esse
usuário. Outros usuários de um computador específico e o próprio computador
não estarão sujeitos a nenhuma política de QoS definida para esse usuário.
Especificidade do aplicativo e precedência sobre aple de rede
Quando várias políticas de QoS corresponderem ao tráfego específico, a política mais

específica será aplicada. Entre as políticas que identificam aplicativos, uma política que
inclui o caminho do arquivo do aplicativo de envio é considerada mais específica do que
outra política que identifica apenas o nome do aplicativo (sem caminho). Se várias
políticas com aplicativos ainda se aplicarem, as regras de precedência usarão o exemplo
de rede para encontrar a melhor combinação.
Como alternativa, várias políticas de QoS podem se aplicar ao mesmo tráfego

especificando condições não sobrepostas. Entre as condições de aplicativos e a
plataforma de rede, a política que especifica o aplicativo é considerada mais específica e
é aplicada.
Por exemplo, policy_A especifica apenas um nome de aplicativo (app.exe) e policy_B

especifica o endereço IP de destino 192.168.1.0/24. Quando essas políticas de QoS
estão em conflito (app.exe envia o tráfego para um endereço IP dentro do intervalo de
192.168.4.0/24), policy_A é aplicado.
Mais especificidade tem precedência dentro do exemplo de rede
Para conflitos de política dentro da rede, a política com as condições mais

correspondentes tem precedência. Por exemplo, suponha policy_C especifica o
endereço IP de origem "any", o endereço IP de destino 10.0.0.1, a porta de origem
"any", a porta de destino "any" e o protocolo "TCP".
Em seguida, suponha policy_D especifica o endereço IP de origem "any", o endereço IP

de destino 10.0.0.1, a porta de origem "any", a porta de destino 80 e o protocolo "TCP".
Em seguida, policy_C e policy_D as conexões com o destino 10.0.0.1:80. Como a Política
de QoS aplica a política com as condições de correspondência mais específicas, policy_D
tem precedência neste exemplo.
No entanto, as políticas de QoS podem ter um número igual de condições. Por exemplo,
várias políticas podem especificar apenas uma parte (mas não a mesma) da rede. Entre a
instância de rede, a ordem a seguir é de precedência mais alta a inferior:
Endereço IP de origem
Endereço IP de destino
Porta de origem
Porta de destino
Protocolo (TCP ou UDP)
Dentro de uma condição específica, como endereço IP, um endereço IP mais específico
é tratado com maior precedência; por exemplo, um endereço IP 192.168.4.1 é mais
específico do que 192.168.4.0/24.
Projete suas políticas de QoS o mais especificamente possível para simplificar a

capacidade da sua organização de entender quais políticas estão em vigor.
Para o próximo tópico neste guia, consulte Erros e eventos de política de QoS.
Mensagens de evento e erro de política
de QoS
A seguir estão as mensagens de erro e de evento associadas à Política de QoS.
Mensagens informativas
Veja a seguir uma lista de mensagens informativas da Política de QoS.
Atributo Valor
MessageId 16500
Gravidade Informativo
SymbolicName EVENT_EQOS_INFO_MACHINE_POLICY_REFRESH_NO_CHANGE
Idioma Inglês
Message Políticas de QoS do computador atualizadas com êxito. Nenhuma alteração

detectada.
Atributo Valor
MessageId 16501
SymbolicName EVENT_EQOS_INFO_MACHINE_POLICY_REFRESH_WITH_CHANGE
Idioma Inglês
Message Políticas de QoS do computador atualizadas com êxito. Alterações de política

detectadas.
Atributo Valor
MessageId 16502
SymbolicName EVENT_EQOS_INFO_USER_POLICY_REFRESH_NO_CHANGE
Atributo Valor
Idioma Inglês
Message Políticas de QoS do usuário atualizadas com êxito. Nenhuma alteração

detectada.
Atributo Valor
MessageId 16503
SymbolicName EVENT_EQOS_INFO_USER_POLICY_REFRESH_WITH_CHANGE
Idioma Inglês
Message Políticas de QoS do usuário atualizadas com êxito. Alterações de política

detectadas.
Atributo Valor
MessageId 16504
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_NOT_CONFIGURED
Idioma Inglês
Message A Configuração avançada de QoS para o nível de taxa de transferência TCP de

entrada foi atualizada com êxito. O valor de configuração não é especificado
por nenhuma política de QoS. O padrão do computador local será aplicado.
Atributo Valor
MessageId 16505
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_OFF
Idioma Inglês

entrada foi atualizada com êxito. O valor da configuração é Nível 0 (taxa de
transferência mínima).
Atributo Valor
Atributo Valor
MessageId 16506
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_HIGHLY_RESTRICTED
Idioma Inglês

entrada foi atualizada com êxito. O valor da configuração é Nível 1.
Atributo Valor
MessageId 16507
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_RESTRICTED
Idioma Inglês

entrada foi atualizada com êxito. O valor da configuração é Nível 2.
Atributo Valor
MessageId 16508
SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_NORMAL
Idioma Inglês

entrada foi atualizada com êxito. O valor da configuração é Nível 3
(produtividade máxima).
Atributo Valor
MessageId 16509
SymbolicName EVENT_EQOS_INFO_APP_MARKING_NOT_CONFIGURED
Idioma Inglês
Atributo Valor
Message A Configuração avançada de QoS para marcação DSCP substitui as

substituições atualizadas com êxito. O valor de configuração não é especificado.
Os aplicativos podem definir valores DSCP independentemente das políticas de
QoS.
Atributo Valor
MessageId 16510
SymbolicName EVENT_EQOS_INFO_APP_MARKING_IGNORED
Idioma Inglês

substituições atualizadas com êxito. As solicitações de marcação DSCP do
aplicativo serão ignoradas. Somente políticas de QoS podem definir valores
DSCP.
Atributo Valor
MessageId 16511
SymbolicName EVENT_EQOS_INFO_APP_MARKING_ALLOWED
Idioma Inglês

substituições atualizadas com êxito. Os aplicativos podem definir valores DSCP
independentemente das políticas de QoS.
Atributo Valor
MessageId 16512
SymbolicName EVENT_EQOS_INFO_LOCAL_SETTING_DONT_USE_NLA
Idioma Inglês
Message A aplicação seletiva de políticas de QoS com base na categoria de rede de

domínio foi desabilitada. As políticas de QoS serão aplicadas a todos os
interfaces de rede.
Mensagens de aviso
A seguir está uma lista de mensagens de aviso da Política de QoS.
Atributo Valor
MessageId 16600
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_TEST_1
Idioma Inglês
Message EQOS: ***Testing***[, com uma cadeia de caracteres] "%2".
Atributo Valor
MessageId 16601
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_TEST_2
Idioma Inglês
Message EQOS: ***Testing***[, com duas cadeias de caracteres, string1 is] "%2"[, string2
is] "%3".
Atributo Valor
MessageId 16602
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_VERSION
Idioma Inglês
Message A política de QoS do computador "%2" tem um número de versão inválido. Essa
política não será aplicada.
Atributo Valor
MessageId 16603
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_VERSION
Atributo Valor
Idioma Inglês
Message A política de QoS do usuário "%2" tem um número de versão inválido. Essa
política não será aplicada.
Atributo Valor
MessageId 16604
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_PROFILE_NOT_SPECIFIED
Idioma Inglês
Message A política de QoS do computador "%2" não especifica um valor DSCP ou uma
taxa de aceleração. Essa política não será aplicada.
Atributo Valor
MessageId 16605
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_PROFILE_NOT_SPECIFIED
Idioma Inglês
Message A política de QoS do usuário "%2" não especifica um valor DSCP ou uma taxa
de aceleração. Essa política não será aplicada.
Atributo Valor
MessageId 16606
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_QUOTA_EXCEEDED
Idioma Inglês
Message Excedeu o número máximo de políticas de QoS do computador. A política de

QoS "%2" e as políticas de QoS do computador subsequentes não serão
aplicadas.
Atributo Valor
MessageId 16607
Atributo Valor
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_QUOTA_EXCEEDED
Idioma Inglês
Message Excedeu o número máximo de políticas de QoS do usuário. A política de QoS

"%2" e as políticas de QoS de usuário subsequentes não serão aplicadas.
Atributo Valor
MessageId 16608
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_CONFLICT
Idioma Inglês
Message A política de QoS do computador "%2" potencialmente está em conflito com

outras políticas de QoS. Consulte a documentação para ver as regras sobre qual
política será aplicada.
Atributo Valor
MessageId 16609
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_CONFLICT
Idioma Inglês
Message A política de QoS do usuário "%2" potencialmente está em conflito com outras
políticas de QoS. Consulte a documentação para ver as regras sobre qual
política será aplicada.
Atributo Valor
MessageId 16610
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_NO_FULLPATH_APPNAME
Idioma Inglês
Atributo Valor
Message A política de QoS do computador "%2" foi ignorada porque o caminho do

aplicativo não pode ser processado. O caminho do aplicativo pode ser inválido,
conter uma letra de unidade inválida ou conter uma unidade mapeada de rede.
Atributo Valor
MessageId 16611
Gravidade Aviso
SymbolicName EVENT_EQOS_WARNING_USER_POLICY_NO_FULLPATH_APPNAME
Idioma Inglês
Message A política de QoS do usuário "%2" foi ignorada porque o caminho do aplicativo
não pode ser processado. O caminho do aplicativo pode ser inválido, conter
uma letra de unidade inválida ou conter uma unidade mapeada de rede.
Mensagens de erro
Veja a seguir uma lista de mensagens de erro da Política de QoS.
Atributo Valor
MessageId 16700
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_REFERESH
Idioma Inglês
Message Falha na atualização das políticas de QoS do computador. Código de erro: "%2".
Atributo Valor
MessageId 16701
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_USER_POLICY_REFERESH
Idioma Inglês
Message Falha na atualização das políticas de QoS do usuário. Código de erro: "%2".
Atributo Valor
MessageId 16702
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_OPENING_MACHINE_POLICY_ROOT_KEY
Idioma Inglês
Message Falha na QoS ao abrir a chave raiz no nível do computador para políticas de
QoS. Código de erro: "%2".
Atributo Valor
MessageId 16703
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_OPENING_USER_POLICY_ROOT_KEY
Idioma Inglês
Message Falha na QoS ao abrir a chave raiz no nível do usuário para políticas de QoS.
Código de erro: "%2".
Atributo Valor
MessageId 16704
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_KEYNAME_TOO_LONG
Idioma Inglês
Message Uma política de QoS de computador excede o comprimento máximo de nome

permitido. A política incorreta está listada na chave raiz da política de QoS no
nível da máquina, com o índice "%2".
Atributo Valor
MessageId 16705
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_USER_POLICY_KEYNAME_TOO_LONG
Idioma Inglês
Atributo Valor
Message Uma política de QoS de usuário excede o comprimento máximo de nome

permitido. A política incorreta está listada na chave raiz de política de QoS de
nível de usuário, com o índice "%2".
Atributo Valor
MessageId 16706
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_KEYNAME_SIZE_ZERO
Idioma Inglês
Message Uma política de QoS de computador tem um nome de comprimento zero. A

política incorreta está listada na chave raiz da política de QoS no nível da
máquina, com o índice "%2".
Atributo Valor
MessageId 16707
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_USER_POLICY_KEYNAME_SIZE_ZERO
Idioma Inglês
Message Uma política de QoS de usuário tem um nome de comprimento zero. A política
incorreta está listada na chave raiz de política de QoS de nível de usuário, com
o índice "%2".
Atributo Valor
MessageId 16708
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_OPENING_MACHINE_POLICY_SUBKEY
Idioma Inglês
Message Falha do QoS ao abrir a subchave do registro para uma política de QoS do
computador. A política está listada na chave raiz da política de QoS no nível da
máquina, com o índice "%2".
Atributo Valor
Atributo Valor
MessageId 16709
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_OPENING_USER_POLICY_SUBKEY
Idioma Inglês
Message Falha de QoS ao abrir a subchave do registro para uma política de QoS de
usuário. A política está listada na chave raiz de política de QoS de nível de
usuário, com o índice "%2".
Atributo Valor
MessageId 16710
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_PROCESSING_MACHINE_POLICY_FIELD
Idioma Inglês
Message Falha de QoS ao ler ou validar o campo "%2" para a política de QoS do
computador "%3".
Atributo Valor
MessageId 16711
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_PROCESSING_USER_POLICY_FIELD
Idioma Inglês
Message Falha de QoS ao ler ou validar o campo "%2" para a política de QoS de usuário
"%3".
Atributo Valor
MessageId 16712
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_SETTING_TCP_AUTOTUNING
Idioma Inglês
Atributo Valor
Message Falha na QoS ao ler ou definir o nível de produtividade TCP de entrada, código
de erro: "%2".
Atributo Valor
MessageId 16713
Gravidade Erro
SymbolicName EVENT_EQOS_ERROR_SETTING_APP_MARKING
Idioma Inglês
Message Falha na QoS ao ler ou definir a configuração de substituição de marcação

DSCP, código de erro: "%2".
Para o próximo tópico neste guia, consulte Perguntas frequentes sobre a política de
QoS.
Perguntas frequentes sobre a
política de QoS
Perguntas frequentes
Aplica-se a: Windows Server 2016
A seguir estão as perguntas frequentes – e respostas para essas perguntas – para a

Política de QoS.
Qual sistema operacional meu

controlador de domínio precisa estar
em execução para usar a Política de
QoS?
Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server
2008 R2 ou Windows Server 2008
Quais sistemas operacionais suportam a

aplicação da Política de QoS para o
usuário ou computador?
Você pode aplicar políticas de QoS a usuários ou computadores que executam Windows
Server 2016, Windows 10, Windows Server 2012 R2, Windows 8.1, Windows Server 2012,
Windows 8, Windows Server 2008 R2, Windows Server 2008 e Windows Vista.
As políticas de QoS se aplicam ao

remetente ou ao destinatário do
tráfego?
As políticas de QoS devem ser aplicadas no computador de envio para afetar o tráfego
de saída. Para afetar o tráfego bidirecional de dois computadores, as políticas de QoS
precisam ser aplicadas a ambos os computadores.
O que acontece se políticas de QoS
conflitantes são implantadas no mesmo
computador?
Se várias políticas se aplicarem, a política de QoS mais específica tem precedência. Por
exemplo, uma política que declara um endereço de host (192.168.4.12) é aplicada em
vez de um endereço de rede menos específico (192.168.0.0/16). Se uma política de nível
de computador e de usuário tiver a mesma especificidade, a política de QoS no nível do
usuário será aplicada em vez da política de QoS no nível do computador.
A Política de QoS está habilitada por

padrão?
Não, a Política de QoS não está habilitada por padrão. Você deve criar políticas de QoS
manualmente para habilitar o QoS. Para obter mais informações, consulte Gerenciar
política de QoS.
Rede definida pelo software (SDN)
Saiba mais sobre os recursos, a tecnologia e a implantação da Rede definida pelo
software (SDN).
Sobre a rede definida pelo software
ｅ VISÃO GERAL
Visão geral da rede definida pelo software (SDN)
Segurança para SDN
ｈ NOVIDADES
Novidades na SDN para o Windows Server 2019
ｐ CONCEITO
Principais componentes da arquitetura da SDN
ｑ VIDEO
Mecânica da SDN da Microsoft
Introdução
ｂ COMEÇAR AGORA
Planejar uma infraestrutura SDN
Implantar uma infraestrutura SDN
Gerenciar uma infraestrutura SDN
ｅ VISÃO GERAL
Solucionar problemas e diagnosticar uma infraestrutura SDN
Recursos de aprendizagem sobre SDN

ｄ TREINAMENTO
Solucionar problemas de definição de configurações de largura de banda de VPN de Gateway

RAS da SDN no VMM
Folha de dados da rede definida pelo software da Microsoft

Tecnologias SDN
Os tópicos nesta seção fornecem informações técnicas e visão geral sobre as

tecnologias de Rede Definida pelo Software incluídas no Windows Server.
Controlador de rede
O controlador de rede fornece um ponto de automação centralizado e programável
para gerenciar, configurar, monitorar e solucionar problemas de infraestrutura de rede
física e virtual em seu datacenter. Com o controlador de rede, você pode automatizar a
configuração da infraestrutura de rede em vez de executar a configuração manual de
dispositivos e serviços de rede.
O controlador de rede é um servidor altamente disponível e escalonável e fornece duas

APIs (interfaces de programação de aplicativo):
1. API de southbound – permite que o controlador de rede se comunique com a

rede.
2. API de northbound – permite que você se comunique com o controlador de rede.
Você pode usar Windows PowerShell, a API rest (Transferência de Estado

Representacional) ou um aplicativo de gerenciamento para gerenciar a seguinte
infraestrutura de rede física e virtual:
VMs e comutadores virtuais do Hyper-V

Comutadores de rede física
Roteadores de rede física
Software de firewall
Gateways de VPN, incluindo Gateways Multitenant do RAS (Serviço de Acesso
Remoto)
Balanceadores de Carga

A HNV (Virtualização de Rede Hyper-V) ajuda você a abstrair seus aplicativos e cargas
de trabalho da rede física usando redes virtuais. Redes virtuais fornecem o isolamento
multilocatário necessário durante a execução em uma malha de rede física
compartilhada, aumentando assim a utilização de recursos. Para garantir que você possa
realizar seus investimentos existentes, você pode configurar redes virtuais na
engrenagem de rede existente. Além disso, as redes virtuais são compatíveis com VLANs
(redes locais) virtuais.
Comutador Virtual do Hyper-V

O Com switch virtual do Hyper-V é um comando de rede Ethernet de camada 2 baseado
em software que está disponível no Gerenciador do Hyper-V depois de instalar a função
de servidor Hyper-V. O comutador inclui funcionalidades programaticamente
gerenciadas e extensíveis para conectar máquinas virtuais a redes físicas e a redes
virtuais. Além disso, o Com switch virtual do Hyper-V fornece imposição de política para
níveis de segurança, isolamento e serviço.
Você também pode implantar o Comutamento Virtual do Hyper-V com SET

(Comutamento Inserido) e RDMA (Acesso Remoto Direto à Memória). Para obter mais
informações, consulte a seção Remote Direct Memory Access (RDMA) e Switch
Embedded Teaming (SET) neste tópico.
IDNS (Serviço DNS Interno) para SDN

As VMs (máquinas virtuais) hospedadas e os aplicativos exigem que o DNS se
comunique em suas redes e com recursos externos na Internet. Com o iDNS, você pode
fornecer aos locatários serviços de resolução de nomes DNS para recursos isolados, de
namespace local e da Internet.

Dispositivos de hardware, como balanceadores de carga, firewalls, roteadores e
comutadores, estão se tornando cada vez mais dispositivos virtuais. A Microsoft tem
redes virtualizadas, comutadores, gateways, NATs, balanceadores de carga e firewalls.
Essa "virtualização da função de rede" é uma progressão natural de virtualização do
servidor e de virtualização de rede. As soluções de virtualização estão rapidamente
emergentes e criando um novo mercado. Eles continuam a gerar interesse e ganhar
força em plataformas de virtualização e serviços de nuvem.
As seguintes tecnologias de Virtualização de Função de Rede estão disponíveis.
SLB (software Load Balancer) e NAT (Conversão de Endereços de Rede).

Aprimora a taxa de transferência dando suporte ao Retorno do Servidor Direto no
qual o tráfego de rede de retorno pode ignorar o multiplexador de Balanceamento
de Carga. Para obter mais detalhes, consulte Balanceamento de carga de software
/(SLB/) para SDN.
Firewall do datacenter. Forneça ACLs (listas de controle de acesso granulares),

permitindo que você aplique políticas de firewall no nível da interface da VM ou
no nível da sub-rede. Para obter mais detalhes, consulte Visão geral do Firewall do
Datacenter.
Gateway RAS para SDN. Roteia o tráfego de rede entre a rede física e os recursos
de rede da VM, independentemente do local. Você pode roteá-lo no mesmo local
físico ou em muitos locais diferentes. Para obter mais detalhes, consulte Gateway
RAS para SDN.
Acesso Remoto Direto à Memória (RDMA) e

Agrupamento incorporado do comutador (SET)
No Windows Server 2016, você pode habilitar o RDMA em adaptadores de rede que
estão vinculados a um Comando Virtual hyper-V com ou sem SET (Switch Embedded
Teaming). Isso permite que você use menos adaptadores de rede quando quiser usar
RDMA e SET ao mesmo tempo.
SET é uma solução alternativa de NIC Teaming que você pode usar em ambientes que
incluem o Hyper-V e a pilha SDN (Rede Definida pelo Software) no Windows Server
2016. SET integra algumas das funcionalidades de NIC Teaming no Com switch virtual
do Hyper-V.
SET permite agrupar entre um e oito adaptadores de rede Ethernet físicos em um ou

mais adaptadores de rede virtual baseados em software. Esses adaptadores de rede
virtual oferecem desempenho rápido e tolerância a falhas no caso de uma falha do
adaptador de rede.
Todos os adaptadores de rede membro SET devem ser instalados no
mesmo host físico do Hyper-V a ser colocado em uma equipe.
Além disso, você pode usar comandos do Windows PowerShell para habilitar o DCB
(Data Center Bridging), criar um Comu switch virtual do Hyper-V com uma vNIC (NIC
virtual) RDMA e criar um comu switch virtual do Hyper-V com vNICs SET e RDMA. Para
obter mais informações, consulte Remote Direct Memory Access (RDMA) e Switch
Embedded Teaming (SET).
BGP (Border Gateway Protocol)

Border Gateway Protocol (BGP) é um protocolo de roteamento dinâmico que aprende
automaticamente rotas entre sites que usam conexões VPN site a site. Portanto, o BGP
reduz a configuração manual de roteadores. Quando você configura o Gateway de RAS,
o BGP permite gerenciar o roteamento de tráfego de rede entre as redes de VM dos
locatários e sites remotos.
SLB (balanceamento de carga do software)

para SDN
Os CSPs (Provedores de Serviços de Nuvem) e as empresas que implantam o SDN
podem usar o SLB (Balanceamento de Carga de Software) para distribuir de maneira
equilibrada o tráfego de rede do cliente de locatário e locatário entre os recursos de
rede virtual. O SLB do Windows Server permite que vários servidores hospedem a
mesma carga de trabalho, fornecendo alta disponibilidade e escalabilidade.
Contêineres do Windows Server

Windows Contêineres de Servidor são um método leve de virtualização do sistema
operacional que separa aplicativos ou serviços de outros serviços em execução no
mesmo host de contêiner. Cada contêiner tem seu próprio sistema operacional,
processos, sistema de arquivos, registro e endereços IP, que você pode conectar a redes
virtuais.
System Center
Implante e gerencie a infraestrutura de SDN com o VMM (Gerenciamento de Máquinas
Virtuais)e Operations Manager. Com o VMM, você provisiona e gerencia os recursos
necessários para criar e implantar máquinas virtuais e serviços em nuvens privadas. Com
o Operations Manager, você monitora serviços, dispositivos e operações em toda a
empresa para identificar problemas para ação imediata.
Introduzido em Windows Server 2012, o HNV (Hyper-V Network Virtualization) permite

a virtualização de redes de clientes sobre uma infraestrutura de rede física
compartilhada. Com o mínimo de alterações necessárias na malha de rede física, o HNV
dá aos provedores de serviços a agilidade para implantar e migrar cargas de trabalho de
locatário em qualquer lugar entre as três nuvens: a nuvem do provedor de serviços, a
nuvem privada ou a nuvem pública Microsoft Azure.
Para obter mais informações, consulte estes tópicos:
Visão geral da virtualização de rede Hyper-V no Windows Server 2016
Novidades na Virtualização de Rede do Hyper-V no Windows Server 2016
Você sabia que o Microsoft Azure fornece uma funcionalidade semelhante na

nuvem? Saiba mais sobre Soluções de Virtualização do Microsoft Azure .
Criar uma solução de virtualização híbrida no Microsoft Azure:
- Conexão uma rede local para o Azure via VPN site a site e estender o Active
Directory para uma VM DC iaaS no Azure |
Visão geral da Virtualização de Rede
Hyper-V no Windows Server
No Windows Server e Virtual Machine Manager, a Microsoft fornece uma solução de

virtualização de rede de ponta a ponta. Há cinco componentes principais que compõem
a solução de virtualização de rede da Microsoft:
Windows Pacote do Azure para Windows Server fornece um portal voltado para
locatários para criar redes virtuais e um portal administrativo para gerenciar redes
virtuais.
Virtual Machine Manager (VMM) fornece gerenciamento centralizado da malha

de rede.
O Controlador de Rede da Microsoft fornece um ponto de automação

centralizado e programável para gerenciar, configurar, monitorar e solucionar
problemas de infraestrutura de rede virtual e física em seu datacenter.
A Virtualização de Rede Hyper-V oferece a infraestrutura necessária para

virtualizar o tráfego da rede.
Os gateways de Virtualização de Rede Hyper-V fornecem conexões entre redes

virtuais e físicas.
Este tópico apresenta conceitos e explica os principais benefícios e funcionalidades da

Virtualização de Rede Hyper-V (uma parte da solução geral de virtualização de rede) no
Windows Server 2016. Ele explica como a virtualização de rede beneficia as nuvens
privadas para consolidação de carga de trabalho corporativa e os provedores de serviço
de nuvem pública de IaaS (Infraestrutura como Serviço).
Para obter mais detalhes técnicos sobre a virtualização de rede Windows Server 2016,
consulte Detalhes técnicos de virtualização de rede hyper-V Windows Server 2016.
Você quis dizer
Visão geral da Virtualização de Rede Hyper-V ( Windows Server 2012 R2 )
Visão geral do Hyper-V

Visão geral do Comutador Virtual do Hyper-V
Descrição do recurso
A Virtualização de Rede Hyper-V fornece "redes virtuais" (chamadas de rede VM) para
máquinas virtuais semelhantes a como a virtualização de servidor (hipervisor) fornece
"máquinas virtuais" para o sistema operacional. A virtualização de rede separa redes
virtuais da infraestrutura de rede física e remove as restrições da atribuição de
endereços IP hierárquicos e de VLAN do provisionamento de máquinas virtuais. Essa
flexibilidade facilita a migração de clientes para nuvens IaaS e torna mais eficiente o
gerenciamento da infraestrutura pelos hosters e administradores do datacenter,
mantendo ainda o isolamento multilocatário, os requisitos de segurança e o suporte à
sobreposição de endereços IP de máquinas virtuais.
Os clientes desejam estender diretamente seus datacenters para a nuvem. Atualmente,

existem desafios técnicos para a criação dessas arquiteturas de nuvem híbridas
integradas. Um dos maiores obstáculos que os clientes enfrentam é a reutilação de suas
topologias de rede existentes (sub-redes, endereços IP, serviços de rede e assim por
diante) na nuvem e ponte entre seus recursos locais e seus recursos de nuvem. A
Virtualização de Rede Hyper-V oferece o conceito de uma Rede VM independente da
rede física subjacente. Com esse conceito de Rede VM, composta de uma ou mais Sub-
redes Virtuais, a localização física exata da rede física das máquinas virtuais ligadas a
uma rede virtual é separada da topologia da rede virtual. Como resultado, os clientes
podem mover facilmente suas sub-redes virtuais para a nuvem preservando seus
endereços IP e sua topologia existente na nuvem, de forma que os serviços existentes
continuam funcionando independentemente da localização física das sub-redes. Ou
seja, a Virtualização de Rede Hyper-V permite uma nuvem híbrida integrada.
Além da nuvem híbrida, muitas organizações estão consolidando seus datacenters e

criando nuvens privadas para obter internamente o benefício das arquiteturas em
nuvem em termos de eficiência e escalabilidade. A Virtualização de Rede Hyper-V
permite maior flexibilidade e eficiência para nuvens privadas, desacoplando a topologia
de rede de uma unidade de negócios (tornando-a virtual) da topologia de rede física
real. Assim, as unidades de negócios podem facilmente compartilhar uma nuvem
privada interna, ao mesmo tempo em que ficam isoladas umas das outras e continuam
a manter as topologias de rede existentes. A equipe de operações do datacenter tem
flexibilidade para implantar e mover dinamicamente cargas de trabalho em qualquer
lugar do datacenter sem interrupções do servidor, fornecendo eficiências operacionais
melhores e, no geral, um datacenter mais eficiente.
Para proprietários de carga de trabalho, o principal benefício é que agora eles podem
mover suas "topologias" de carga de trabalho para a nuvem sem alterar seus endereços
IP ou reescrevê-los. Por exemplo, o aplicativo LOB típico de três camadas é composto de
uma camada de front-end, uma camada de lógica de negócios e uma camada de banco
de dados. Por meio da política, a Virtualização de Rede Hyper-V permite que o cliente
carregue todas as partes das três camadas na nuvem, mantendo a topologia de
roteamento e os endereços IP dos serviços (ou seja, os endereços IP da máquina virtual),
sem a necessidade de alterar os aplicativos.
Para proprietários de infraestrutura, a flexibilidade adicional no posicionamento de

máquinas virtuais torna possível mover cargas de trabalho em qualquer lugar dos
datacenters sem alterar o as máquinas virtuais ou reconfigurar as redes. Por exemplo, a
Virtualização de Rede Hyper-V permite a migração ao vivo entre sub-redes, de forma
que uma máquina virtual pode migrar ao vivo em qualquer lugar do datacenter sem
uma interrupção do serviço. Anteriormente, a migração ao vivo era limitada à mesma
sub-rede, restringindo os locais onde as máquinas virtuais podiam ficar localizadas. A
migração ao vivo entre sub-redes permite que os administradores consolidem cargas de
trabalho com base em requisitos de recursos dinâmicos, eficiência de energia e também
possam acomodar a manutenção da infraestrutura sem interromper o tempo de
atividade da carga de trabalho do cliente.
Aplicações práticas
Com o sucesso dos datacenters virtualizados, as organizações de TI e os provedores de
hospedagem (provedores que fornecem aluguéis de servidores físicos ou colocação)
começaram a oferecer infraestruturas virtualizadas mais flexíveis que facilitam a oferta
de instâncias de servidor por demanda a seus clientes. Essa nova classe de serviços é
chamada de IaaS (Infraestrutura como Serviço). Windows Server 2016 fornece todos os
recursos de plataforma necessários para permitir que os clientes empresariais criem
nuvens privadas e transiram para um modelo operacional de TI como serviço. Windows
Server 2016 também permite que os hosters criem nuvens públicas e ofereçam soluções
de IaaS para seus clientes. Quando combinada com Virtual Machine Manager e
Windows Azure Pack para gerenciar a política de Virtualização de Rede Hyper-V, a
Microsoft fornece uma solução de nuvem poderosa.
Windows Server 2016 Virtualização de Rede Hyper-V fornece aos hosters de nuvem
melhor flexibilidade e escalabilidade para gerenciar máquinas virtuais para obter maior
utilização de recursos.
Um cenário IaaS que tem máquinas virtuais de diferentes divisões organizacionais

(nuvem dedicada) ou diferentes clientes (nuvem hospedada) exige um isolamento
seguro. A solução atual, VLANs (redes locais virtuais), pode apresentar desvantagens
significativas nesse cenário.
Vlans
Atualmente, as VLANs são o mecanismo que a maioria das organizações usa para dar
suporte à reutilização de espaço de endereço e ao isolamento de locatário. Uma VLAN
usa a marcação explícita (VLAN ID) nos cabeçalhos de quadros Ethernet e depende dos
comutadores Ethernet para impor o isolamento e restringir o tráfego aos nós da rede
com a mesma ID da VLAN. As principais desvantagens das VLANs são as descritas a
seguir:
Risco aumentado de uma interrupção inadvertida devido à trabalhosa

reconfiguração de comutadores de produção sempre que máquinas virtuais ou os
limites de isolamento se movem no datacenter dinâmico.
Escalabilidade limitada porque existe um máximo de 4094 VLANS e os

comutadores típicos não dão suporte a mais de 1000 IDs de VLAN.
Limitadas a uma única sub-rede de IPs, o que restringe o número de nós em uma
única VLAN e o posicionamento de máquinas virtuais com base em localizações
físicas. Embora as VLANs possam ser expandidas entre sites, a VLAN inteira deve
estar na mesma sub-rede.
Atribuição de endereço IP
Além das desvantagens apresentadas pelas VLANs, a atribuição de endereço IP da

máquina virtual apresenta problemas, que incluem:
As localizações físicas na infraestrutura de rede do datacenter determinam os

endereços IP das máquinas virtuais. Como resultado, a mudança para a nuvem
normalmente exige a alteração dos endereços IP das cargas de trabalho de
serviços.
As políticas são associadas a endereços IP, como regras de firewall, descoberta de

recursos e serviços de diretório etc. A alteração de endereços IP exige a
atualização de todas as políticas associadas.
A implantação de máquinas virtuais e o isolamento do tráfego dependem da

topologia.
Quando os administradores de rede do datacenter planejam o layout físico do

datacenter, devem tomar decisões sobre onde as sub-redes serão posicionadas e
roteadas fisicamente. Essas decisões se baseiam na tecnologia de IP e Ethernet, que
afeta os possíveis endereços IP permitidos para máquinas virtuais em execução em um
determinado servidor ou um blade conectado a um rack específico no datacenter.
Quando uma máquina virtual é provisionada e posicionada no datacenter, ela deve estar
de acordo com essas opções e restrições referentes ao endereço IP. Portanto,
normalmente, os administradores do datacenter atribuem endereços IP novos às
máquinas virtuais.
O problema desse requisito é que, além de ser um endereço, há informações semânticas

associadas a um endereço IP. Por exemplo, uma sub-rede pode conter determinados
serviços ou estar em uma localização física distinta. É comum que regras de firewall,
políticas de controle de acesso e associações de segurança IPsec estejam associados a
endereços IP. A alteração dos endereços IP exige que os proprietários das máquinas
virtuais ajustem todas as políticas baseadas no endereço IP original. Essa sobrecarga
com a renumeração é tão grande que muitas empresas optam por implantar somente
serviços novos na nuvem, abandonando os aplicativos herdados.
A Virtualização de Rede Hyper-V separa as redes virtuais das máquinas virtuais do

cliente da infraestrutura de rede física. Como resultado, as máquinas virtuais do cliente
podem manter seus endereços IP originais, e os administradores do datacenter podem
provisionar as máquinas virtuais do cliente em qualquer lugar do datacenter sem
precisar reconfigurar endereços IP físicos ou IDs da VLAN. A próxima seção resume as
principais funcionalidades.
Funcionalidade importante
Veja a seguir uma lista das principais funcionalidades, benefícios e funcionalidades da
Virtualização de Rede Hyper-V Windows Server 2016:
Habilita o posicionamento flexível da carga de trabalho – Isolamento de rede e

rea utilização de endereço IP sem VLANs
A Virtualização de Rede Hyper-V dissocia as redes virtuais do cliente da

infraestrutura de rede física dos hosters, fornecendo liberdade para
posicionamentos de carga de trabalho dentro dos datacenters. O posicionamento
da carga de trabalho de máquinas virtuais não é mais limitado pelos requisitos de
atribuição de endereços IP ou isolamento da VLAN da rede física, pois é imposto
com hosts Hyper-V baseados em políticas de virtualização multilocatário definidas
pelo software.
Agora as máquinas virtuais de diferentes clientes com endereços IP sobrepostos

podem ser implantadas no mesmo servidor host, sem exigir a trabalhosa
configuração da VLAN ou violar a hierarquia de endereços IP. Isso pode agilizar a
migração de cargas de trabalho do cliente em provedores de hospedagem IaaS
compartilhados, permitindo que os clientes migrem essas cargas de trabalho sem
modificações, inclusive deixando os endereços IP das máquinas virtuais
inalterados. Para o provedor de hospedagem, o suporte a numerosos clientes que
desejam estender seus espaços de endereços de rede existentes para o datacenter
IaaS compartilhado é um exercício complexo de configuração e manutenção de
VLANs isoladas para cada cliente, a fim de garantir a coexistência de espaços de
endereços possivelmente sobrepostos. Com a Virtualização de Rede Hyper-V, o
suporte a endereços sobrepostos é facilitado e exige menos reconfiguração da
rede pelo provedor de hospedagem.
Além disso, a manutenção e as atualizações da infraestrutura física podem ser

feitas sem causar um tempo de inatividade das cargas de trabalho do cliente. Com
a Virtualização de Rede Hyper-V, as máquinas virtuais em um determinado host,
rack, sub-rede, VLAN ou em todo o cluster podem ser migradas sem exigir a
alteração do endereço IP físico ou uma reconfiguração de grande porte.
Habilita migrações mais fáceis de cargas de trabalho para uma nuvem IaaS
compartilhada
Com a Virtualização de Rede Hyper-V, as configurações de endereços IP e

máquinas virtuais permanecem inalteradas. Isso permite que as organizações de TI
migrem mais facilmente as cargas de trabalho de seus datacenters para um
provedor de hospedagem IaaS compartilhado, com reconfiguração mínima da
carga de trabalho ou das ferramentas e políticas de sua infraestrutura. Nos casos
em que há conectividade entre dois datacenters, os administradores de TI podem
continuar a usar suas ferramentas sem precisar reconfigurá-las.
Habilita a migração ao vivo entre sub-redes
A migração ao vivo de cargas de trabalho de máquina virtual tradicionalmente tem

sido limitada à mesma sub-rede IP ou VLAN porque a passagem de sub-redes
exigia que o sistema operacional convidado da máquina virtual alterava seu
endereço IP. Essa alteração de endereço interrompe a comunicação existente e os
serviços em execução na máquina virtual. Com a Virtualização de Rede Hyper-V, as
cargas de trabalho podem ser migradas ao vivo de servidores que executam o
Windows Server 2016 em uma sub-rede para servidores que executam Windows
Server 2016 em uma sub-rede diferente sem alterar os endereços IP da carga de
trabalho. A Virtualização de Rede Hyper-V garante que as alterações de localização
das máquinas virtuais devido à migração ao vivo sejam atualizadas e sincronizadas
entre os hosts que têm comunicação contínua com as máquinas virtuais migradas.
Habilita o gerenciamento mais fácil da administração de rede e de servidores

separados
O posicionamento da carga de trabalho do servidor é simplificado porque a
migração e o posicionamento de cargas de trabalho são independentes das
configurações da rede física subjacente. Os administradores de servidores podem
se concentrar no gerenciamento de serviços e servidores, e os administradores de
rede podem se concentrar no gerenciamento geral do tráfego e da infraestrutura
de rede. Assim, os administradores de servidores do datacenter podem implantar e
migrar máquinas virtuais sem precisar alterar os endereços IP das máquinas
virtuais. As sobrecarga é reduzida porque a Virtualização de Rede Hyper-V permite
que o posicionamento de máquinas virtuais ocorra de maneira independente da
topologia de rede, reduzindo a necessidade de os administradores de rede se
envolverem com os posicionamentos que podem alterar os limites do isolamento.
Simplifica a rede e melhora a utilização de recursos de servidor/rede
A rigidez das VLANs e a dependência do posicionamento de máquinas virtuais em

uma infraestrutura de rede física resulta no superprovisionamento e na
subutilização. Com a quebra dessa dependência, a maior flexibilidade do
posicionamento da carga de trabalho de máquinas virtuais pode simplificar o
gerenciamento de rede e melhorar a utilização de recurso de servidor e de rede.
Observe que a Virtualização de Rede Hyper-V dá suporte a VLANs no contexto do
datacenter físico. Por exemplo, um datacenter pode requerer que todo o tráfego
da Virtualização de Rede Hyper-V esteja em uma VLAN específica.
É compatível com a infraestrutura existente e a tecnologia emergente
A virtualização de rede Hyper-V pode ser implantada no datacenter atual, ainda

que seja compatível com as tecnologias de "rede plana" do datacenter emergente.
por exemplo, HNV em Windows Server 2016 dá suporte ao formato de

encapsulamento VXLAN e ao OVSDB (Open vSwitch Database Management
Protocol) como a Interface SouthBound (SBI).
Fornece interoperabilidade e prontidão do ecossistema
A Virtualização de Rede Hyper-V dá suporte a várias configurações de

comunicação com recursos existentes, como conectividade entre locais, SAN (rede
de área de armazenamento), acesso a recursos não virtualizados etc. A Microsoft
tem o compromisso de trabalhar com parceiros de ecossistema para dar suporte e
aperfeiçoar a experiência da Virtualização de Rede Hyper-V em termos de
desempenho, escalabilidade e gerenciabilidade.
Configuração baseada em política

as políticas de virtualização de rede no Windows Server 2016 são configuradas
através do controlador de rede da Microsoft. o controlador de rede tem uma API
northbound RESTful e Windows PowerShell interface para configurar a política.
Para obter mais informações sobre o controlador de rede da Microsoft, consulte
controlador de rede.
Requisitos de software
a virtualização de rede Hyper-v usando o controlador de rede da Microsoft requer
Windows Server 2016 e a função Hyper-v.
Confira também
para saber mais sobre a virtualização de rede Hyper-V no Windows Server 2016
consulte os links a seguir:
Tipo de conteúdo Referências
Recursos da - Blog da arquitetura de nuvem privada
comunidade -Faça perguntas: cloudnetfb@microsoft.com
RFC -VXLAN- RFC 7348
Tecnologias - Controlador de rede
relacionadas - visão geral da virtualização de rede Hyper-V (Windows Server 2012

R2)
Virtualização de Rede Hyper-V detalhes
técnicos no servidor Windows
A virtualização de servidores permite que várias instâncias do servidor sejam executadas

simultaneamente em um único host físico, mas as instâncias do servidor são isoladas
umas das outras. Cada máquina virtual opera essencialmente como se fosse o único
servidor em execução no computador físico.
A virtualização de rede fornece uma funcionalidade semelhante, na qual várias redes

virtuais (potencialmente com endereços IP sobrepostos) são executadas na mesma
infraestrutura de rede física e cada rede virtual opera como se fosse a única rede virtual
em execução na infraestrutura de rede compartilhada. A figure 1 exibe essa relação.
Figura 1: Virtualização do servidor x virtualização da rede
Conceitos da Virtualização de Rede Hyper-V

Em Virtualização de Rede Hyper-V (HNV), um cliente ou locatário é definido como o
"proprietário" de um conjunto de sub-redes IP implantadas em uma empresa ou
datacenter. Um cliente pode ser uma empresa ou empresa com vários departamentos
ou unidades de negócios em um datacenter privado que exigem isolamento de rede ou
um locatário em um data center público hospedado por um provedor de serviços. Cada
cliente pode ter uma ou mais redes virtuais no datacenter e cada rede virtual consiste
em uma ou mais sub-redes virtuais.
Há duas implementações HNV que estarão disponíveis em Windows Server 2016:

HNVv1 e HNVv2.
HNVv1
O HNVv1 é compatível com Windows Server 2012 R2 e System Center VMM (2012
R2 Virtual Machine Manager). A configuração do HNVv1 depende do
gerenciamento do WMI e dos cmdlets Windows PowerShell (facilitados por meio
de System Center VMM) para definir as configurações de isolamento e a CA
(Endereço do Cliente) – rede virtual – para mapeamentos e roteamento de
Endereço Físico (PA). Nenhum recurso adicional foi adicionado ao HNVv1 em
Windows Server 2016 e nenhum novo recurso está planejado.
Set Teaming e HNV V1 não são compatíveis com a plataforma.
o Para usar gateways NVGRE ha, os usuários precisam usar a equipe LBFO ou
nenhuma equipe. Ou
o Usar gateways implantados pelo controlador de rede com o comutador em

equipe SET.
HNVv2
Um número significativo de novos recursos estão incluídos no HNVv2, que é

implementado usando a extensão de encaminhamento da VFP (Plataforma de
Filtragem Virtual) do Azure no Comutador Hyper-V. O HNVv2 é totalmente
integrado ao Microsoft Azure Stack, que inclui o novo Controlador de Rede na
Pilha SDN (Rede Definida por Software). A política de rede virtual é definida por
meio do Controlador de Rede da Microsoft usando uma API RESTful NorthBound
(NB) e inserida em um Agente host por meio de várias Interfaces southbound (SBI),
incluindo OVSDB. A política de programas do Host Agent na extensão VFP do
Comutador Hyper-V em que ela é imposta.
） Importante
Este tópico se concentra no HNVv2.
Rede virtual
Cada rede virtual consiste em uma ou mais sub-redes virtuais. Uma rede virtual
forma um limite de isolamento em que as máquinas virtuais dentro de uma rede
virtual só podem se comunicar entre si. Tradicionalmente, esse isolamento era
imposto usando VLANs com um intervalo de endereços IP segregado e ID de
marca 802,1q ou VLAN. Mas com o HNV, o isolamento é imposto usando
encapsulamento NVGRE ou VXLAN para criar redes de sobreposição com a
possibilidade de sobreposição de sub-redes IP entre clientes ou locatários.
Cada rede virtual tem uma RDID (ID de Domínio de Roteamento) exclusiva no host.
Essa RDID é mapeada aproximadamente para uma ID de Recurso para identificar o
recurso REST de rede virtual no Controlador de Rede. O recurso REST de rede
virtual é referenciado usando um namespace URI (Uniform Resource Identifier)
com a ID do Recurso acrescentada.
Sub-redes virtuais
Uma sub-rede virtual implementa a semântica de sub-rede IP de Camada 3 das
máquinas virtuais na mesma sub-rede virtual. A sub-rede virtual forma um
domínio de difusão (semelhante a uma VLAN) e o isolamento é imposto usando o
campo TNI (ID de Rede de Locatário) NVGRE ou VNI (Identificador de Rede
VXLAN).
Cada sub-rede virtual pertence a uma única RDID (rede virtual) e recebe uma VSID
(ID de sub-rede virtual) exclusiva usando a chave TNI ou VNI no cabeçalho de
pacote encapsulado. O VSID deve ser exclusivo dentro do datacenter e está no
intervalo de 4096 a 2^24-2.
Uma das principais vantagens da rede virtual e do domínio de roteamento é que ela
permite que os clientes tragam suas próprias topologias de rede (por exemplo, sub-
redes IP) para a nuvem. A Figura 2 mostra um exemplo em que a Contoso Corp tem
duas redes separadas, o R&D Net e o Sales Net. Como essas redes têm diferentes IDs de
domínio de roteamento, elas não podem interagir entre si. Ou seja, a Contoso R&D Net
é isolada da Contoso Sales Net, embora ambas sejam de propriedade da Contoso Corp.
Contoso R&D Net contém três sub-redes virtuais. Observe que a RDID e a VSID são
exclusivas dentro de um datacenter.
Figura 2: Redes de cliente e sub-redes virtuais
Encaminhamento da Camada 2
Na Figura 2, as máquinas virtuais no VSID 5001 podem ter seus pacotes encaminhados
para máquinas virtuais que também estão no VSID 5001 por meio do Comutador
Hyper-V. Os pacotes de entrada de uma máquina virtual no VSID 5001 são enviados
para um VPort específico no Comutador Hyper-V. As regras de entrada (por exemplo,
encap) e mapeamentos (por exemplo, cabeçalho de encapsulamento) são aplicados
pelo Comutador Hyper-V para esses pacotes. Em seguida, os pacotes são encaminhados
para um VPort diferente no Comutador Hyper-V (se a máquina virtual de destino estiver
anexada ao mesmo host) ou para um comutador Hyper-V diferente em um host
diferente (se a máquina virtual de destino estiver localizada em um host diferente).
Roteamento da Camada 3
Da mesma forma, as máquinas virtuais no VSID 5001 podem ter seus pacotes roteados
para máquinas virtuais no VSID 5002 ou VSID 5003 pelo roteador distribuído HNV que
está presente no VSwitch de cada host Hyper-V. Ao entregar o pacote para o
comutador Hyper-V, o HNV atualiza o VSID do pacote de entrada para o VSID da
máquina virtual de destino. Isso ocorrerá somente se as duas VSIDs estiverem na mesma
RDID. Portanto, adaptadores de rede virtual com RDID1 não podem enviar pacotes para
adaptadores de rede virtual com RDID2 sem percorrer um gateway.
７ Observação
Na descrição do fluxo de pacotes acima, o termo "máquina virtual" realmente

significa o adaptador de rede virtual na máquina virtual. O caso comum é quando
uma máquina virtual tem apenas um único adaptador de rede virtual. Nesse caso,
as palavras "máquina virtual" e "adaptador de rede virtual" podem significar
conceitualmente a mesma coisa.
Cada sub-rede virtual define uma sub-rede IP de Camada 3 e um limite de domínio de
difusão de Camada 2 (L2) de maneira semelhante a uma VLAN. Quando uma máquina
virtual transmite um pacote, o HNV usa a UR (Replicação Unicast) para fazer uma cópia
do pacote original e substituir o IP de destino e MAC pelos endereços de cada VM que
estão no mesmo VSID.
７ Observação
Quando Windows Server 2016 navios, multicasts de transmissão e sub-rede serão

implementados usando a replicação unicast. Não há suporte para roteamento
multicast entre sub-redes e IGMP.
Além de ser um domínio de difusão, a VSID fornece isolamento. Um adaptador de rede

virtual no HNV está conectado a uma porta de comutador Hyper-V que terá regras de
ACL aplicadas diretamente à porta (recurso REST virtualNetworkInterface) ou à VSID
(sub-rede virtual) da qual ela faz parte.
A porta de comutador do Hyper-V deve ter uma regra de ACL aplicada. Essa ACL pode
ser ALLOW ALL, DENY ALL ou ser mais específica para permitir apenas determinados
tipos de tráfego com base na correspondência de 5 tuplas (IP de origem, IP de destino,
porta de origem, porta de destino, protocolo).
７ Observação
As Extensões de Comutador do Hyper-V não funcionarão com o HNVv2 na nova

pilha SDN (Rede Definida por Software). O HNVv2 é implementado usando a
extensão de comutador VFP (Plataforma de Filtragem Virtual) do Azure, que não
pode ser usada em conjunto com qualquer outra extensão de comutador de
terceiros.
Alternar e rotear em Virtualização de Rede

Hyper-V
O HNVv2 implementa a comutação correta da Camada 2 (L2) e a semântica de
roteamento da Camada 3 (L3) para funcionar como um comutador físico ou roteador
funcionaria. Quando uma máquina virtual conectada a uma rede virtual HNV tenta
estabelecer uma conexão com outra máquina virtual na mesma VSID (sub-rede virtual),
ela primeiro precisará aprender o endereço MAC de CA da máquina virtual remota. Se
houver uma entrada ARP para o endereço IP da máquina virtual de destino na tabela
ARP da máquina virtual de origem, o endereço MAC dessa entrada será usado. Se uma
entrada não existir, a máquina virtual de origem enviará uma transmissão ARP com uma
solicitação para que o endereço MAC correspondente ao endereço IP da máquina
virtual de destino seja retornado. O Comutador Hyper-V interceptará essa solicitação e a
enviará para o Agente host. O Agente host procurará em seu banco de dados local um
endereço MAC correspondente para o endereço IP da máquina virtual de destino
solicitado.
７ Observação
O Agente host, atuando como o servidor OVSDB, usa uma variante do esquema
VTEP para armazenar mapeamentos de CA-PA, tabela MAC e assim por diante.
Se um endereço MAC estiver disponível, o Agente host injetará uma resposta ARP e
enviará isso de volta para a máquina virtual. Depois que a pilha de rede da máquina
virtual tiver todas as informações de cabeçalho L2 necessárias, o quadro será enviado
para a porta do Hyper-V correspondente no V-Switch. Internamente, o Comutador
Hyper-V testa esse quadro em relação às regras de correspondência N-tupla atribuídas
à Porta V e aplica determinadas transformações ao quadro com base nessas regras.
Mais importante, um conjunto de transformações de encapsulamento é aplicado para
construir o cabeçalho de encapsulamento usando NVGRE ou VXLAN, dependendo da
política definida no Controlador de Rede. Com base na política programada pelo
Agente host, um mapeamento ca-pa é usado para determinar o endereço IP do host
Hyper-V onde reside a máquina virtual de destino. O Comutador Hyper-V garante que
as regras de roteamento corretas e as marcas VLAN sejam aplicadas ao pacote externo
para que ele atinja o endereço pa remoto.
Se uma máquina virtual conectada a uma rede virtual HNV quiser criar uma conexão
com uma máquina virtual em uma VSID (sub-rede virtual) diferente, o pacote precisará
ser roteado de acordo. O HNV pressupõe uma topologia de estrela em que há apenas
um endereço IP no espaço de AC usado como o próximo salto para alcançar todos os
prefixos IP (ou seja, uma rota/gateway padrão). Atualmente, isso impõe uma limitação a
uma única rota padrão e não há suporte para rotas não padrão.
Roteamento Entre Sub-redes Virtuais

Em uma rede física, uma sub-rede IP é um domínio de Camada 2 (L2), em que
computadores (virtuais e físicos) podem se comunicar diretamente entre si. O domínio
L2 é um domínio de difusão em que as entradas ARP (mapa de endereços IP:MAC) são
aprendidas por meio de solicitações ARP que são transmitidas em todas as interfaces e
as respostas ARP são enviadas de volta para o host solicitante. O computador usa as
informações mac aprendidas com a resposta ARP para construir completamente o
quadro L2, incluindo cabeçalhos Ethernet. No entanto, se um endereço IP estiver em
uma sub-rede L3 diferente, a solicitação ARP não cruzará esse limite L3. Em vez disso,
uma interface de roteador L3 (próximo salto ou gateway padrão) com um endereço IP
na sub-rede de origem deve responder a essas solicitações ARP com seu próprio
endereço MAC.
Na rede Windows padrão, um administrador pode criar rotas estáticas e atribuí-las a um

adaptador de rede. Além disso, um "gateway padrão" geralmente é configurado para
ser o endereço IP do próximo salto em uma interface em que os pacotes destinados à
rota padrão (0.0.0.0/0) são enviados. Os pacotes serão enviados para esse gateway
padrão se não houver rotas específicas. Normalmente, esse é o roteador da rede física.
O HNV usa um roteador interno que faz parte de cada host e tem uma interface em
cada VSID para criar um roteador distribuído para as redes virtuais.
Como o HNV assume uma topologia estrela, o roteador distribuído HNV atua como um
único gateway padrão para todo o tráfego que está entre sub-redes virtuais que fazem
parte da mesma rede VSID. O endereço usado como o gateway padrão é padrão para o
endereço IP mais baixo no VSID e é atribuído ao roteador distribuído HNV. Esse
roteador distribuído permite uma maneira muito eficiente para que todo o tráfego
dentro de uma Rede VSID seja roteado adequadamente porque cada host pode rotear
diretamente o tráfego para o host apropriado sem precisar de um intermediário. Isso é
particularmente verdadeiro quando duas máquinas virtuais na mesma Rede VM, mas em
diferentes Sub-redes Virtuais estão no mesmo host físico. Como você verá mais adiante
nesta seção, o pacote nunca terá que sair do host físico.
Roteamento entre sub-redes de PA

Em contraste com o HNVv1, que alocou um endereço IP de PA para cada VSID (Sub-
rede Virtual), o HNVv2 agora usa um endereço IP de PA por membro da equipe nic de
agrupamento de Switch-Embedded (SET). A implantação padrão pressupõe uma equipe
de duas NIC e atribui dois endereços IP de PA por host. Um único host tem IPs de PA
atribuídos da mesma sub-rede lógica de PA (Provedor) na mesma VLAN. Duas VMs de
locatário na mesma sub-rede virtual podem, de fato, estar localizadas em dois hosts
diferentes que estão conectados a duas sub-redes lógicas de provedor diferentes. O
HNV construirá os cabeçalhos IP externos para o pacote encapsulado com base no
mapeamento CA-PA. No entanto, ele depende da pilha TCP/IP do host para o ARP para
o gateway de PA padrão e, em seguida, cria os cabeçalhos Ethernet externos com base
na resposta ARP. Normalmente, essa resposta ARP vem da interface SVI no comutador
físico ou roteador L3 em que o host está conectado. Portanto, o HNV depende do
roteador L3 para rotear os pacotes encapsulados entre sub-redes lógicas/VLANs do
provedor.
Roteamento Fora de uma Rede Virtual

A maioria das implantações de cliente exigirá a comunicação do ambiente de HNV com
recursos que não fazem parte do ambiente de HNV. São necessários gateways de
Virtualização de Rede para permitir a comunicação entre os dois ambientes. As
infraestruturas que exigem um Gateway HNV incluem Nuvem Privada e Nuvem Híbrida.
Basicamente, os gateways HNV são necessários para o roteamento da Camada 3 entre
redes internas e externas (físicas) (incluindo NAT) ou entre diferentes sites e/ou nuvens
(privadas ou públicas) que usam uma VPN IPSec ou túnel GRE.
Os gateways podem ser fornecidos em diferentes fatores forma físicos. Eles podem ser
criados em Windows Server 2016, incorporados em um comutador TOR (Top of Rack)
atuando como um Gateway VXLAN, acessado por meio de um IP Virtual (VIP) anunciado
por um balanceador de carga, colocado em outros dispositivos de rede existentes ou
pode ser um novo dispositivo de rede autônomo.
Para obter mais informações sobre Windows opções de Gateway RAS, consulte o
Gateway de RAS.
Encapsulamento de Pacote
Cada adaptador de rede virtual da HNV está associado a dois endereços IP:
Endereço do cliente (AC) O endereço IP atribuído pelo cliente, com base em sua
infraestrutura de intranet. Esse endereço permite que o cliente troque o tráfego de
rede com a máquina virtual como se não tivesse sido movido para uma nuvem
pública ou privada. O CA é visível para a máquina virtual e está acessível para o
cliente.
Endereço do Provedor (PA) O endereço IP atribuído pelo provedor de

hospedagem ou pelos administradores do datacenter com base em sua
infraestrutura de rede física. O PA é exibido nos pacotes da rede que são trocados
com o servidor Hyper-V que hospeda a máquina virtual. O PA está visível na rede
física, mas não para a máquina virtual.
Os CAs mantêm a topologia de rede do cliente, que é virtualizada e separada dos

endereços e da topologia de rede física real subjacente, conforme implementado pelos
PAs. O diagrama a seguir mostra a relação conceitual entre os CAs de máquinas virtuais
e os PAs da infraestrutura de rede resultantes da virtualização da rede.
Figura 6: Diagrama conceitual da virtualização de rede na infraestrutura física
No diagrama, as máquinas virtuais do cliente estão enviando pacotes de dados no

espaço de AC, que atravessam a infraestrutura de rede física por meio de suas próprias
redes virtuais ou "túneis". No exemplo acima, os túneis podem ser considerados como
"envelopes" ao redor dos pacotes de dados contoso e fabrikam com rótulos de envio
verde (endereços PA) a serem entregues do host de origem à esquerda para o host de
destino à direita. A chave é como os hosts determinam os "endereços de envio" (PA's)
correspondentes à Contoso e à AC fabrikam, como o "envelope" é colocado em torno
dos pacotes e como os hosts de destino podem desembrulhar os pacotes e entregar
corretamente às máquinas virtuais de destino Contoso e Fabrikam.
Essa analogia simples destacou os principais aspectos da virtualização de rede:
Cada autoridade de certificação de máquina virtual é mapeada para um host físico

PA. Pode haver diversos CAs associados ao mesmo PA.
As máquinas virtuais enviam pacotes de dados nos espaços de AC, que são
colocados em um "envelope" com um par de origem e destino de PA com base no
mapeamento.
Os mapeamentos CA-PA devem permitir que os hosts diferenciem pacotes para

máquinas virtuais do cliente diferentes.
Como resultado, o mecanismo de virtualização da rede consiste em virtualizar os

endereços de rede usados pelas máquinas virtuais. O controlador de rede é responsável
pelo mapeamento de endereço e o agente host mantém o banco de dados de
mapeamento usando o esquema MS_VTEP. A seção a seguir descreve o mecanismo real
de virtualização de endereços.
Virtualização da rede por meio da virtualização
de endereços
O HNV implementa redes de locatário de sobreposição usando o NVGRE
(Encapsulamento Genérico de Virtualização de Rede) ou a VXLAN (Rede de Área Local
EXtensível Virtual). VXLAN é o padrão.
Rede de Área Local EXtensible Virtual (VXLAN)

O protocolo VXLAN (Virtual eXtensible Local Area Network) (RFC 7348 ) foi
amplamente adotado no mercado, com suporte de fornecedores como Cisco, Brocade,
Arista, Dell, HP e outros. O protocolo VXLAN usa UDP como o transporte. A porta de
destino UDP atribuída à IANA para VXLAN é 4789 e a porta de origem UDP deve ser um
hash de informações do pacote interno a ser usado para distribuição de ECMP. Após o
cabeçalho UDP, um cabeçalho VXLAN é acrescentado ao pacote que inclui um campo
reservado de 4 bytes seguido por um campo de 3 bytes para o VNI (Identificador de
Rede VXLAN) - VSID - seguido por outro campo reservado de 1 byte. Após o cabeçalho
VXLAN, o quadro CA L2 original (sem o fcs do quadro Ethernet de AC) é acrescentado.
Encapsulamento de roteamento genérico (NVGRE)

Esse mecanismo de virtualização de rede usa o NVGRE (Encapsulamento de Roteamento
Genérico) como parte do cabeçalho do túnel. Em NVGRE, o pacote da máquina virtual é
encapsulado dentro de outro pacote. O cabeçalho desse novo pacote tem os endereços
IP do PA de origem e de destino, além da ID da Sub-rede Virtual, que é armazenada no
campo Key do cabeçalho do GRE, como mostrado na Figura 7.
Figura 7: Virtualização de rede – encapsulamento NVGRE
A ID da Sub-rede Virtual permite que os hosts identifiquem a máquina virtual do cliente

para qualquer pacote determinado, mesmo que as PA's e as AC's nos pacotes possam se
sobrepor. Isso permite que todas as máquinas virtuais no mesmo host compartilhem um
único PA, como mostrado na Figura 7.
O compartilhamento do PA tem um grande impacto sobre a escalabilidade da rede. O

número de endereços IP e MAC que devem ser aprendidos pela infraestrutura de rede
pode ser reduzido significativamente. Por exemplo, se cada host final tiver uma média
de 30 máquinas virtuais, o número de endereços IP e MAC que precisam ser aprendidos
pela infraestrutura de rede é reduzido por um fator de 30. As IDs de Sub-rede Virtual
inseridas nos pacotes também habilitam a fácil correlação de pacotes com os clientes
reais.
O esquema de compartilhamento de PA para Windows Server 2012 R2 é um PA por

VSID por host. Para Windows Server 2016 o esquema é um PA por membro da equipe
nic.
Com Windows Server 2016 e posteriores, o HNV dá suporte total a NVGRE e VXLAN fora
da caixa; não requer a atualização ou a compra de novos hardwares de rede, como NICs
(adaptadores de rede), comutadores ou roteadores. Isso ocorre porque esses pacotes na
transmissão são pacotes IP regulares no espaço de PA, que é compatível com a
infraestrutura de rede atual. No entanto, para obter o melhor desempenho, use NICs
com suporte com os drivers mais recentes que dão suporte a descarregamentos de
tarefas.
Exemplo de implantação multilocatário
O diagrama a seguir mostra um exemplo de implantação de dois clientes localizados em
um datacenter de nuvem com a relação CA-PA definida pelas políticas de rede.
Figura 8: Exemplo de implantação multilocatário
Considere o exemplo na Figura 8. Antes de migrar para o provedor de hospedagem do

serviço IaaS compartilhado:
A Contoso Corp executava um SQL Server (chamado SQL) no endereço IP 10.1.1.11

e um servidor Web (chamado Web) no endereço IP 10.1.1.12, que usa seu SQL
Server para transações de banco de dados.
A Fabrikam Corp executava um SQL Server, também chamado SQL e atribuiu o

endereço IP 10.1.1.11 e um servidor Web, também chamado Web, e também no
endereço IP 10.1.1.12, que usa seu SQL Server para transações de banco de dados.
Vamos supor que o provedor de serviços de hospedagem tenha criado anteriormente a

rede lógica de PA (provedor) por meio do Controlador de Rede para corresponder à
topologia de rede física. O Controlador de Rede aloca dois endereços IP de PA do
prefixo IP da sub-rede lógica em que os hosts estão conectados. O controlador de rede
também indica a marca VLAN apropriada para aplicar os endereços IP.
Usando o Controlador de Rede, a Contoso Corp e a Fabrikam Corp criam sua rede
virtual e sub-redes que são apoiadas pela rede lógica de provedor (PA) especificada
pelo provedor de serviços de hospedagem. A Contoso Corp e Fabrikam Corp migram
seus respectivos SQL Servers e servidores Web para o serviço IaaS compartilhado do
mesmo provedor de hospedagem onde, coincidentemente, executam as máquinas
virtuais SQL no Host Hyper-V 1 e as máquinas virtuais Web (IIS7) no Host Hyper-V 2.
Todas as máquinas virtuais mantêm seus endereços IP de intranet originais (seus CAs).
Ambas as empresas recebem a seguinte VSID (ID de Sub-rede Virtual) pelo Controlador
de Rede, conforme indicado abaixo. O Agente host em cada um dos hosts Hyper-V
recebe os endereços IP de PA alocados do Controlador de Rede e cria dois vNICs de
host de PA em um compartimento de rede não padrão. Um adaptador de rede é
atribuído a cada um desses vNICs de host em que o endereço IP de PA é atribuído,
conforme mostrado abaixo:
VSID e PAs das máquinas virtuais da Contoso Corp: VSID é 5001, SQL PA é
192.168.1.10, a PA Web é 192.168.2.20
VSID e PAs das máquinas virtuais da Fabrikam Corp: VSID é 6001, SQL PA é
192.168.1.10, a PA Web é 192.168.2.20
O Controlador de Rede canaliza toda a política de rede (incluindo mapeamento de CA-

PA) para o Agente host do SDN que manterá a política em um repositório persistente
(em tabelas de banco de dados OVSDB).
Quando a máquina virtual Da Web da Contoso Corp (10.1.1.12) no Host Hyper-V 2 cria
uma conexão TCP com o SQL Server em 10.1.1.11, o seguinte acontece:
ARPs de VM para o endereço MAC de destino 10.1.1.11
A extensão VFP no vSwitch intercepta esse pacote e o envia para o Agente de Host
do SDN
O Agente de Host do SDN procura em seu repositório de políticas o endereço

MAC para 10.1.1.11
Se um MAC for encontrado, o Agente host injetará uma resposta ARP de volta à
VM
Se um MAC não for encontrado, nenhuma resposta será enviada e a entrada ARP
na VM para 10.1.1.11 será marcada como inacessível.
A VM agora constrói um pacote TCP com os cabeçalhos Ethernet e IP de AC

corretos e o envia para o vSwitch
A extensão de encaminhamento VFP no vSwitch processa esse pacote por meio

das camadas VFP (descritas abaixo) atribuídas à porta vSwitch de origem na qual o
pacote foi recebido e cria uma nova entrada de fluxo na tabela de fluxo unificado
VFP
O mecanismo VFP executa a correspondência de regras ou pesquisa de tabela de

fluxo para cada camada (por exemplo, camada de rede virtual) com base nos
cabeçalhos IP e Ethernet.
A regra correspondente na camada de rede virtual faz referência a um espaço de
mapeamento CA-PA e executa encapsulamento.
O tipo de encapsulamento (VXLAN ou NVGRE) é especificado na camada VNet

junto com o VSID.
No caso de encapsulamento VXLAN, um cabeçalho UDP externo é construído com

o VSID de 5001 no cabeçalho VXLAN.
Um cabeçalho IP externo é construído com o
endereço PA de origem e destino atribuído ao Host Hyper-V 2 (192.168.2.20) e ao
Host Hyper-V 1 (192.168.1.10), respectivamente, com base no repositório de
políticas do Agente de Host do SDN.
Em seguida, esse pacote flui para a camada de roteamento de PA no VFP.
A camada de roteamento de PA no VFP referenciará o compartimento de rede

usado para o tráfego de espaço de PA e uma ID de VLAN e usará a pilha TCP/IP do
host para encaminhar o pacote pa para o Host 1 do Hyper-V corretamente.
Após o recebimento do pacote encapsulado, o Host 1 do Hyper-V recebe o pacote

no compartimento de rede pa e o encaminha para o vSwitch.
O VFP processa o pacote por meio de suas camadas VFP e cria uma nova entrada
de fluxo na tabela de fluxo unificada VFP.
O mecanismo VFP corresponde às regras de entrada na camada de rede virtual e

remove os cabeçalhos Ethernet, IP e VXLAN do pacote encapsulado externo.
Em seguida, o mecanismo VFP encaminha o pacote para a porta vSwitch à qual a

VM de destino está conectada.
Um processo semelhante para o tráfego entre as máquinas virtuais Web e SQL da

Fabrikam Corp usa as configurações de política de HNV para a Fabrikam Corp. Como
resultado, com a HNV, as máquinas virtuais da Fabrikam Corp e da Contoso Corp
interagem como se estivessem em suas intranets originais. Elas nunca podem interagir
entre si, embora estejam usando os mesmos endereços IP.
Os endereços separados (CAs e PAs), as configurações de política dos hosts Hyper-V e a

conversão de endereços entre a AC e a PA para tráfego de máquina virtual de entrada e
saída isolam esses conjuntos de servidores usando a chave NVGRE ou o VNID VLXAN.
Além disso, os mapeamentos de virtualização e a conversão separam a arquitetura da
rede virtual da infraestrutura de rede da rede física. Embora os servidores SQL e Web da
Contoso e SQL e Web da Fabrikam residam em suas próprias sub-redes IP do CA
(10.1.1/24), sua implantação física ocorre em dois hosts em sub-redes PA diferentes,
192.168.1/24 e 192.168.2/24, respectivamente. A implicação é que o provisionamento de
máquinas virtuais entre sub-redes e a migração ao vivo se tornam possíveis com a HNV.
Arquitetura da Virtualização de Rede Hyper-V

No Windows Server 2016, o HNVv2 é implementado usando a VFP (Plataforma de
Filtragem Virtual do Azure), que é uma extensão de filtragem NDIS dentro do
Comutador Hyper-V. O conceito chave do VFP é o de um mecanismo de fluxo de
Match-Action com uma API interna exposta ao Agente de Host do SDN para a política
de rede de programação. O próprio Agente de Host do SDN recebe a política de rede
do Controlador de Rede pelos canais de comunicação OVSDB e WCF SouthBound. Não
só a política de rede virtual (por exemplo, mapeamento ca-pa) é programada usando
VFP, mas políticas adicionais, como ACLs, QoS e assim por diante.
A hierarquia de objetos para a extensão de encaminhamento vSwitch e VFP é a

seguinte:
vSwitch
Gerenciamento de NIC externo
Descarregamentos de hardware nic
Regras de encaminhamento global
Porta
Egress camada de encaminhamento para fixação de cabelo
Listas de espaços para mapeamentos e pools nat
Tabela de Flow Unificada
Camada VFP
tabela Flow
Grupo
Regra
As regras podem referenciar espaços
No VFP, uma camada é criada por tipo de política (por exemplo, Rede Virtual) e é um
conjunto genérico de tabelas de regra/fluxo. Ele não tem nenhuma funcionalidade
intrínseca até que regras específicas sejam atribuídas a essa camada para implementar
essa funcionalidade. Cada camada recebe uma prioridade e as camadas são atribuídas a
uma porta por prioridade crescente. As regras são organizadas em grupos com base
principalmente na direção e na família de endereços IP. Os grupos também recebem
uma prioridade e, no máximo, uma regra de um grupo pode corresponder a um
determinado fluxo.
A lógica de encaminhamento para o vSwitch com extensão VFP é a seguinte:
Processamento de entrada (entrada do ponto de vista do pacote entrando em

uma porta)
Encaminhando
Egress processamento (saída do ponto de vista do pacote saindo de uma porta)
O VFP dá suporte ao encaminhamento interno do MAC para tipos de encapsulamento

NVGRE e VXLAN, bem como encaminhamento externo baseado em VLAN MAC.
A extensão VFP tem um caminho lento e um caminho rápido para a passagem de

pacotes. O primeiro pacote em um fluxo deve percorrer todos os grupos de regras em
cada camada e fazer uma pesquisa de regra que seja uma operação cara. No entanto,
depois que um fluxo for registrado na tabela de fluxo unificada com uma lista de ações
(com base nas regras correspondentes), todos os pacotes subsequentes serão
processados com base nas entradas unificadas da tabela de fluxo.
A política HNV é programada pelo agente host. Cada adaptador de rede de máquina
virtual é configurado com um endereço IPv4. Esses são os CAs que serão usados pelas
máquinas virtuais para se comunicarem entre si e eles são transportados nos pacotes IP
das máquinas virtuais. O HNV encapsula o quadro de AC em um quadro de PA com
base nas políticas de virtualização de rede armazenadas no banco de dados do agente
host.
Figura 9: Arquitetura de HNV
Resumo
Os datacenters baseados em nuvem podem oferecer diversos benefícios, como
escalabilidade aprimorada e melhor utilização de recursos. Para aproveitar esses
possíveis benefícios, é necessária uma tecnologia que basicamente trate dos problemas
de escalabilidade multilocatário em um ambiente dinâmico. A HNV foi projetada para
lidar com essas questões e também para aprimorar a eficiência operacional do
datacenter, separando a topologia da rede virtual para a topologia da rede física. Com
base em um padrão existente, o HNV é executado no datacenter atual e opera com sua
infraestrutura VXLAN existente. Os clientes com HNV agora podem consolidar seus
datacenters em uma nuvem privada ou estender perfeitamente seus datacenters para o
ambiente de um provedor de servidor de hospedagem com uma nuvem híbrida.
Confira também
Para saber mais sobre o HNVv2, confira os seguintes links:
conteúdo
Recursos da - Blog de arquitetura de nuvem privada
comunidade - Faça perguntas: cloudnetfb@microsoft.com
RFC - NVGRE Draft RFC
- VXLAN – RFC 7348
Tecnologias - Para obter Virtualização de Rede Hyper-V detalhes técnicos no Windows Server
relacionadas 2012 R2, consulte Virtualização de Rede Hyper-V detalhes técnicos
- Controlador de Rede
Novidades na Virtualização de Rede
Hyper-V no Windows Server
Este tópico descreve a funcionalidade HNV (Virtualização de Rede) do Hyper-V que é

nova ou alterada no servidor Windows.
Atualizações no HNV
O HNV oferece suporte aprimorado nas seguintes áreas:

melhorado
Comutador Do Hyper-V Novo A política HNV é programável por meio do

programável Controlador de Rede da Microsoft.
Suporte ao encapsulamento Novo O HNV agora dá suporte ao encapsulamento

VXLAN VXLAN.
Interoperabilidade do SLB (Load Novo O HNV é totalmente integrado ao Microsoft

Balancer de software) Software Load Balancer.
Cabeçalhos Ethernet do IEEE em Melhoria de Em conformidade com os padrões de Ethernet

conformidade do IEEE
Comutador Do Hyper-V programável

O HNV é um bloco de construção fundamental da solução SDN (Software Defined
Networking) atualizada da Microsoft e é totalmente integrado à pilha SDN.
O novo Controlador de Rede da Microsoft envia políticas de HNV por push para um
Agente host em execução em cada host usando o Open vSwitch Database Management
Protocol (OVSDB) como a Interface southbound (SBI). O Agente host armazena essa
política usando uma personalização do esquema VTEP e programa regras de fluxo
complexas em um mecanismo de fluxo performante no comutador Hyper-V.
O mecanismo de fluxo dentro do comutador Hyper-V é o mesmo mecanismo usado em

Microsoft Azure ™, o que foi provado em hiperescalo na nuvem pública Microsoft Azure.
Além disso, toda a pilha de SDN por meio do Controlador de Rede e do Provedor de
Recursos de Rede (detalhes em breve) é consistente com Microsoft Azure, trazendo
assim o poder da nuvem pública Microsoft Azure para nossa empresa e clientes do
provedor de serviços de hospedagem.
７ Observação
Para obter mais informações sobre o OVSDB, consulte RFC 7047 .
A opção Hyper-V dá suporte a regras de fluxo sem estado e com estado com base na
simples "ação de correspondência" no mecanismo de fluxo da Microsoft.
Suporte ao encapsulamento VXLAN

O protocolo VXLAN (Rede de Área Local EXtensível Virtual – RFC 7348 ) foi
amplamente adotado no mercado, com suporte de fornecedores como Cisco, Brocade,
Dell, HP e outros. O HNV também agora dá suporte a esse esquema de encapsulamento
usando o modo de distribuição MAC por meio do Controlador de Rede da Microsoft
para programar mapeamentos para endereços IP de rede de sobreposição de locatário
(Endereço do Cliente ou AC) para os endereços IP de rede de subposição física
(Endereço do Provedor ou PA). Há suporte para descarregamentos de tarefas NVGRE e
VXLAN para melhorar o desempenho por meio de drivers de terceiros.
Interoperabilidade do SLB (Load Balancer de software)

Windows Server 2016 inclui um SLB (balanceador de carga de software) com suporte
total para tráfego de rede virtual e interação contínua com o HNV. O SLB é
implementado por meio do mecanismo de fluxo performante no plano de dados v-
Switch e controlado pelos mapeamentos de IP virtual (VIP) /IP dinâmico (IP) do
Cabeçalhos Ethernet do IEEE em conformidade

O HNV implementa cabeçalhos L2 Ethernet corretos para garantir a interoperabilidade
com dispositivos virtuais e físicos de terceiros que dependem de protocolos padrão do
setor. A Microsoft garante que todos os pacotes transmitidos tenham valores
compatíveis em todos os campos para garantir essa interoperabilidade. Além disso, o
suporte para Quadros Jumbo (MTU > 1780) na rede L2 física será necessário para
considerar a sobrecarga de pacote introduzida pelos protocolos de encapsulamento
(NVGRE, VXLAN) ao mesmo tempo em que garante que os Máquinas Virtuais
convidados anexados a um Rede Virtual HNV mantenham uma MTU 1514.
Visão Geral da Virtualização de Rede Hyper-V
Detalhes técnicos da Virtualização de Rede Hyper-V

Serviço DNS interno (iDNS) para SDN
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versões
21H2 e 20H2
Se você trabalha para um CSP (Provedor de Serviços de Nuvem) ou Enterprise que planeja implantar o SDN
(Software Defined Networking) em Windows Server, você pode fornecer serviços DNS para suas cargas de
trabalho de locatário hospedado usando o DNS interno (iDNS), que é integrado ao SDN.
VMs (máquinas virtuais) hospedadas e aplicativos exigem que o DNS se comunique em suas próprias redes e
com recursos externos na Internet. Com o iDNS, você pode fornecer aos locatários serviços de resolução de
nomes DNS para seu espaço de nome local isolado e para recursos da Internet.
Como o serviço iDNS não está acessível por meio de redes virtuais de locatário, exceto por meio do proxy iDNS,
o servidor não está vulnerável a atividades mal-intencionadas em redes de locatário.
Principais recursos
A seguir estão os principais recursos para iDNS.
Fornece serviços de resolução de nomes DNS compartilhados para cargas de trabalho de locatário
Serviço DNS autoritativo para resolução de nomes e registro DNS no espaço de nome do locatário
Serviço DNS recursivo para resolução de nomes de Internet de VMs de locatário.
Se desejado, você pode configurar a hospedagem simultânea de nomes de malha e locatário
Uma solução DNS econômica – os locatários não precisam implantar sua própria infraestrutura DNS
Alta disponibilidade com a integração do Active Directory, que é necessária.
Além desses recursos, se você estiver preocupado em manter seus servidores DNS integrados do AD abertos na
Internet, você poderá implantar servidores iDNS atrás de outro resolvedor recursivo na rede de perímetro.
Como o iDNS é um servidor centralizado para todas as consultas DNS, um CSP ou Enterprise também pode
implementar firewalls DNS de locatário, aplicar filtros, detectar atividades mal-intencionadas e auditar
transações em um local central
Infraestrutura iDNS
A infraestrutura iDNS inclui servidores iDNS e proxy iDNS.
Servidores iDNS
O iDNS inclui um conjunto de servidores DNS que hospedam dados específicos do locatário, como registros de
recursos DNS da VM.
Os servidores iDNS são os servidores autoritativos para suas zonas DNS internas e também atuam como um
resolvedor para nomes públicos quando as VMs de locatário tentam se conectar a recursos externos.
Todos os nomes de host para VMs em Redes Virtuais são armazenados como Registros de Recursos DNS na
mesma zona. Por exemplo, se você implantar iDNS para uma zona chamada contoso.local, os Registros de
Recursos DNS para as VMs nessa rede serão armazenados na zona contoso.local.
Os FQDNs (Nomes de Domínio Totalmente Qualificados) da VM do locatário consistem no nome do
computador e na cadeia de caracteres de sufixo DNS para o Rede Virtual, no formato GUID. Por exemplo, se
você tiver uma VM de locatário chamada TENANT1 que esteja no Rede Virtual contoso, local, o FQDN da VM
será TENANT1. vn-guid.contoso.local, onde vn-guid é a cadeia de caracteres de sufixo DNS para o Rede Virtual.
７ Observação
Se você for um administrador de malha, poderá usar sua infraestrutura CSP ou Enterprise DNS como
servidores iDNS em vez de implantar novos servidores DNS especificamente para uso como servidores
iDNS. Se você implantar novos servidores para iDNS ou usar sua infraestrutura existente, o iDNS depende
do Active Directory para fornecer alta disponibilidade. Portanto, os servidores iDNS devem ser integrados
ao Active Directory.
Proxy iDNS
O proxy iDNS é um serviço de Windows que é executado em cada host e que encaminha o locatário Rede
Virtual tráfego DNS para o servidor iDNS.
A ilustração a seguir mostra caminhos de tráfego DNS de redes virtuais de locatário por meio do proxy iDNS
para o servidor iDNS e a Internet.
Como implantar iDNS
Quando você implanta o SDN em Windows Server 2016 usando scripts, o iDNS é incluído automaticamente em
sua implantação.
Para obter mais informações, consulte os tópicos a seguir.
Noções básicas sobre as etapas de implantação do iDNS

Você pode usar esta seção para entender como o iDNS é instalado e configurado ao implantar o SDN usando
scripts.
Veja a seguir um resumo das etapas necessárias para implantar o iDNS.
７ Observação
Se você implantou o SDN usando scripts, não precisará executar nenhuma dessas etapas. As etapas são
fornecidas somente para fins de solução de problemas e informações.
Etapa 1: Implantar DNS

Você pode implantar um servidor DNS usando o exemplo a seguir Windows PowerShell comando.
PowerShell
Install-WindowsFeature DNS -IncludeManagementTools
Etapa 2: Configurar informações de iDNS no Controlador de Rede

Esse segmento de script é uma chamada REST feita pelo administrador para o Controlador de Rede,
informando-a sobre a configuração da zona iDNS , como o endereço IP do iDNSServer e a zona usada para
hospedar os nomes iDNS.
Url: https://<url>/networking/v1/iDnsServer/configuration
Method: PUT
"properties": {
"connections": [
"managementAddresses": [
"10.0.0.9"
],
"credential": {
"resourceRef": "/credentials/iDnsServer-Credentials"
},
"credentialType": "usernamePassword"
],
"zone": "contoso.local"
７ Observação
Este é um trecho da seção Configuração ConfigureIDns no SDNExpress.ps1. Para obter mais informações,
consulte Implantar uma infraestrutura de rede definida pelo software usando scripts.
Etapa 3: Configurar o serviço proxy iDNS

O Serviço de Proxy iDNS é executado em cada um dos hosts Hyper-V, fornecendo a ponte entre as redes virtuais
dos locatários e a rede física em que os servidores iDNS estão localizados. As seguintes chaves do Registro
devem ser criadas em todos os hosts do Hyper-V.
Porta DNS: Porta fixa 53
Chave do Registro =
HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService"
ValueName = "Port"
ValueData = 53
ValueType = "Dword"
Porta proxy DNS: Porta fixa 53
Chave do Registro =
ValueName = "ProxyPort"
ValueData = 53
ValueType = "Dword"
IP DNS: Endereço IP fixo configurado na interface de rede, caso o locatário opte por usar o serviço iDNS
Chave do Registro =
ValueName = "IP"
ValueData = "169.254.169.254"
ValueType = "String"
Endereço do Mac: Endereço de Controle de Acesso de mídia do servidor DNS
Chave do Registro =
HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService
ValueName = "MAC"
ValueData = "aa-bb-cc-aa-bb-cc"
Endereço do servidor IDNS: Uma lista separada por vírgulas de servidores iDNS.
Chave do Registro: HKLM\SYSTEM\CurrentControlSet\Services\DNSProxy\Parameters

ValueName = "Forwarders"
ValueData = "10.0.0.9"
７ Observação
Este é um trecho da seção Configuração ConfigureIDnsProxy no SDNExpress.ps1. Para obter mais
informações, consulte Implantar uma infraestrutura de rede definida pelo software usando scripts.
Etapa 4: Reiniciar o Serviço do Agente de Host do Controlador de Rede

Você pode usar o comando Windows PowerShell a seguir para reiniciar o Serviço do Agente de Host do
Controlador de Rede.
PowerShell
Restart-Service nchostagent -Force
Para obter mais informações, consulte Restart-Service.
Habilitar regras de firewall para o serviço proxy DNS

Você pode usar o comando Windows PowerShell a seguir para criar uma regra de firewall que permita que
exceções para o proxy se comuniquem com a VM e o servidor iDNS.
PowerShell
Enable-NetFirewallRule -DisplayGroup 'DNS Proxy Firewall'
Para obter mais informações, consulte Enable-NetFirewallRule.
Validar o serviço iDNS

Para validar o Serviço iDNS, você deve implantar uma carga de trabalho de locatário de exemplo.
Para obter mais informações, consulte Criar uma VM e Conexão para um locatário Rede Virtual ou VLAN.
Se quiser que a VM de locatário use o serviço iDNS, você deve deixar a configuração do servidor DNS de
interfaces de rede da VM em branco e permitir que as interfaces usem DHCP.
Depois que a VM com essa interface de rede é iniciada, ela recebe automaticamente uma configuração que
permite que a VM use iDNS e a VM inicia imediatamente a execução da resolução de nomes usando o serviço
iDNS.
Se você configurar a VM de locatário para usar o serviço iDNS deixando o servidor DNS da interface de rede e as
informações alternativas do servidor DNS em branco, o Controlador de Rede fornecerá à VM um endereço IP e
executará um registro de nome DNS em nome da VM com o servidor iDNS.
O Controlador de Rede também informa o proxy iDNS sobre a VM e os detalhes necessários para executar a
resolução de nomes para a VM.
Quando a VM inicia uma consulta DNS, o proxy atua como um encaminhador da consulta do Rede Virtual para o
serviço iDNS.
O proxy DNS também garante que as consultas de VM de locatário estejam isoladas. Se o servidor iDNS for
autoritativo para a consulta, o servidor iDNS responderá com uma resposta autoritativa. Se o servidor iDNS não
for autoritativo para a consulta, ele executará uma recursão DNS para resolver nomes da Internet.
７ Observação
Essas informações estão incluídas na seção Configuration AttachToVirtualNetwork no
SDNExpressTenant.ps1. Para obter mais informações, consulte Implantar uma infraestrutura de rede
definida pelo software usando scripts.
O que é o Controlador de Rede?
Aplica-se a: Azure Stack HCI, versões 22H2, 21H2 e 20H2; Windows Server 2022,
Windows Server 2019 Windows Server 2016
O Controlador de Rede é a base do gerenciamento de SDN (Rede Definida pelo

Software). É uma função de servidor altamente escalonável que fornece um ponto de
automação centralizado e programável para gerenciar, configurar, monitorar e
solucionar problemas de infraestrutura de rede virtual.
Usando o Controlador de Rede, você pode automatizar a configuração e o

gerenciamento da infraestrutura de rede em vez de executar a configuração manual de
dispositivos e serviços de rede.
Como funciona o Controlador de Rede

O Controlador de Rede fornece uma API (interface de programação de aplicativo) que
permite que o Controlador de Rede se comunique e gerencie dispositivos de rede,
serviços e componentes (API southbound) e uma segunda API que permite que os
aplicativos de gerenciamento informem ao Controlador de Rede quais configurações de
rede e serviços eles precisam (API Northbound).
Com a API Southbound, o Controlador de Rede pode gerenciar dispositivos de rede e

serviços de rede e coletar todas as informações necessárias sobre a rede. O Controlador
de Rede monitora continuamente o estado de dispositivos e serviços de rede e garante
que qualquer descompasso de configuração do estado desejado seja corrigido.
A API Northbound do Controlador de Rede é implementada como uma interface REST.

Ele fornece a capacidade de gerenciar sua rede de datacenter de aplicativos de
gerenciamento. Para gerenciamento, os usuários podem usar a API REST diretamente ou
usar Windows PowerShell criadas com base na API REST ou aplicativos de
gerenciamento com uma interface gráfica do usuário, como Windows Admin Center ou
System Center Virtual Machine Manager.
Para saber mais sobre esses cmdlets do PowerShell, confira Referência de

NetworkController .
Recursos do Controlador de Rede

O Controlador de Rede permite que você gerencie recursos de SDN, como redes
virtuais, firewalls, Load Balancer de software e Gateway ras. Veja a seguir alguns de seus
muitos recursos.
Gerenciamento de rede virtual

Esse recurso controlador de rede permite implantar e configurar a Virtualização de Rede
Hyper-V, configurar adaptadores de rede virtual em VMs individuais e armazenar e
distribuir políticas de rede virtual. Com esse recurso, você pode criar redes virtuais e
sub-redes, anexar VMs (máquinas virtuais) a essas redes e habilitar a comunicação entre
VMs na mesma rede virtual.
O Controlador de Rede dá suporte a redes baseadas em VLAN (Rede Local Virtual),

NVGRE (Encapsulamento de Roteamento Genérico de Virtualização de Rede) e VXLAN
(Virtual Extensible Local Area Network).
Gerenciamento do firewall
Esse recurso controlador de rede permite que você configure e gerencie regras de
Controle de Acesso de firewall de permissão/negação para suas VMs de carga de
trabalho para tráfego de rede interno (Leste/Oeste) e externo (Norte/Sul) em seu
datacenter. As regras de firewall são inseridas na porta vSwitch das VMs de carga de
trabalho e, portanto, são distribuídas entre suas cargas de trabalho no datacenter e se
movem junto com suas cargas de trabalho.
Usando a API Northbound, você pode definir as regras de firewall para o tráfego de
entrada e saída das VMs de carga de trabalho. Você também pode configurar cada
regra de firewall para registrar o tráfego que é permitido ou negado pela regra.
Gerenciamento de Load Balancer de software

O software Load Balancer permite que você habilite vários servidores para hospedar a
mesma carga de trabalho, fornecendo alta disponibilidade e escalabilidade. Com o
Software Load Balancer, você pode configurar e gerenciar o balanceamento de carga, a
NAT (conversão de endereços de rede) de entrada e o acesso de saída à Internet para
cargas de trabalho conectadas a redes VLAN tradicionais e redes virtuais.
Gerenciamento de gateway
O Gateway ras (Serviço de Acesso Remoto) permite que você implante, configure e
gerencie VMs que são membros de um pool de gateway, fornecendo conectividade de
rede externa às cargas de trabalho do cliente. Com os gateways, há suporte para os
seguintes tipos de conectividade entre suas redes virtuais e remotas:
Conectividade de gateway de VPN (rede virtual privada) site a site usando IPsec
Conectividade de gateway de VPN site a site usando GRE (Encapsulamento de
Roteamento Genérico)
Funcionalidade de encaminhamento da Camada 3
As conexões de gateway dão suporte ao BGP (Border Gateway Protocol) para

gerenciamento de rotas dinâmicas.
Encadeamento de dispositivos virtuais

Esse recurso controlador de rede permite anexar dispositivos de rede virtual às suas
redes virtuais. Esses dispositivos podem ser usados para firewalls avançados,
balanceamento de carga, detecção e prevenção de intrusões e muitos outros serviços
de rede. Você pode adicionar dispositivos virtuais que executam funções de roteamento
e espelhamento de porta definidas pelo usuário. Com o roteamento definido pelo
usuário, a solução de virtualização é usada como um roteador entre as sub-redes
virtuais na rede virtual. Com o espelhamento de porta, todo o tráfego de rede que está
entrando ou saindo da porta monitorada é duplicado e enviado para uma solução de
virtualização para análise.
Para saber mais sobre rotas definidas pelo usuário, consulte Usar soluções de
virtualização de rede em um Rede Virtual.
Considerações sobre a implantação do

Controlador de Rede
Não implante a função de servidor controlador de rede em hosts físicos. O
Controlador de Rede deve ser implantado em suas próprias VMs dedicadas.
Você pode implantar o Controlador de Rede em ambientes de domínio e não

domínio. Em ambientes de domínio, o Controlador de Rede autentica usuários e
dispositivos de rede usando Kerberos; em ambientes que não são de domínio,
você deve implantar certificados para autenticação.
É essencial que as implantações do Controlador de Rede forneçam alta

disponibilidade e a capacidade de escalar ou reduzir verticalmente com facilidade
as necessidades do datacenter. Use pelo menos três VMs para fornecer alta
disponibilidade para o aplicativo controlador de rede.
Para obter alta disponibilidade e escalabilidade, o Controlador de Rede depende

do Service Fabric. O Service Fabric fornece uma plataforma de sistemas
distribuídos para criar aplicativos escalonáveis, confiáveis e facilmente gerenciados.
Saiba mais sobre o Controlador de Rede como um Aplicativo do Service Fabric.
Próximas etapas
Para obter informações relacionadas, consulte também:
Planejar a implantação do Controlador de Rede

Implantar controlador de rede usando o Windows PowerShell
SDN no Azure Stack HCI e no Windows Server
Alta disponibilidade do controlador de
rede
Você pode usar este tópico para saber mais sobre a configuração de alta disponibilidade
e escalabilidade do Controlador de Rede para SDN (Rede Definida pelo Software).
Ao implantar o SDN em seu datacenter, você pode usar o Controlador de Rede para
implantar, monitorar e gerenciar centralmente muitos elementos de rede, incluindo
Gateways RAS, Balanceadores de Carga de Software, políticas de rede virtual para
comunicação de locatário, políticas de Firewall do Datacenter, QoS (Qualidade de
Serviço) para políticas de SDN, políticas de rede híbrida e muito mais.
Como o Controlador de Rede é a pedra angular do gerenciamento de SDN, é

fundamental que as implantações do Controlador de Rede forneçam alta
disponibilidade e a capacidade de escalar ou reduzir facilmente os nós do Controlador
de Rede com suas necessidades de datacenter.
Embora você possa implantar o Controlador de Rede como um único cluster de

máquina, para alta disponibilidade e failover, você deve implantar o Controlador de
Rede em um cluster de vários computadores com um mínimo de três computadores.
７ Observação
Você pode implantar o Controlador de Rede em computadores de servidor ou em

VMs (máquinas virtuais) que estão executando Windows Server 2016 edição do
Datacenter. Se você implantar o Controlador de Rede em VMs, as VMs deverão
estar em execução em hosts Hyper-V que também estão executando o Datacenter
Edition. O Controlador de Rede não está disponível na edição Windows Server 2016
Standard.
Controlador de rede como um aplicativo de

Service Fabric
Para obter alta disponibilidade e escalabilidade, o Controlador de Rede depende de
Service Fabric. Service Fabric fornece uma plataforma de sistemas distribuídos para criar
aplicativos escalonáveis, confiáveis e facilmente gerenciados.
Como plataforma, Service Fabric fornece a funcionalidade necessária para a criação de

um sistema distribuído escalonável. Ele fornece hospedagem de serviço em várias
instâncias do sistema operacional, sincronizando informações de estado entre
instâncias, elegendo um líder, detecção de falhas, balanceamento de carga e muito
mais.
７ Observação
Para obter informações sobre Service Fabric no Azure, consulte Visão geral do
Azure Service Fabric.
Quando você implanta o Controlador de Rede em vários computadores, o Controlador

de Rede é executado como um único aplicativo Service Fabric em um cluster Service
Fabric. Você pode formar um cluster Service Fabric conectando um conjunto de
instâncias do sistema operacional.
O aplicativo Controlador de Rede é composto por vários serviços de Service Fabric com
estado. Cada serviço é responsável por uma função de rede, como gerenciamento de
rede física, gerenciamento de rede virtual, gerenciamento de firewall ou gerenciamento
de gateway.
Cada serviço Service Fabric tem uma réplica primária e duas réplicas secundárias. A
réplica de serviço primário processa solicitações, enquanto as duas réplicas de serviço
secundárias fornecem alta disponibilidade em circunstâncias em que a réplica primária
está desabilitada ou indisponível por algum motivo.
A ilustração a seguir mostra um controlador de rede Service Fabric cluster com cinco
computadores. Quatro serviços são distribuídos entre as cinco máquinas: Serviço de
Firewall, Serviço de Gateway, Serviço de Balanceamento de Carga de Software (SLB) e
serviço de Vnet (rede virtual). Cada um dos quatro serviços inclui uma réplica de serviço
primário e duas réplicas de serviço secundárias.
Vantagens de usar Service Fabric
A seguir estão as principais vantagens para usar Service Fabric para clusters do
Alta disponibilidade e escalabilidade

Como o Controlador de Rede é o núcleo de uma rede de datacenter, ele deve ser
resiliente à falha e ser escalonável o suficiente para permitir alterações ágeis em redes
de datacenter ao longo do tempo. Os seguintes recursos fornecem estas habilidades:
Failover rápido. Service Fabric fornece failover extremamente rápido. Várias

réplicas de serviço secundário ativas estão sempre disponíveis. Se uma instância
do sistema operacional ficar indisponível devido a uma falha de hardware, uma das
réplicas secundárias será promovida imediatamente à réplica primária.
Agilidade da escala. Você pode dimensionar facilmente e rapidamente esses
serviços confiáveis de algumas instâncias até milhares de instâncias e, em seguida,
fazer backup para algumas instâncias, dependendo das suas necessidades de
recursos.
Armazenamento persistente
O aplicativo Controlador de Rede tem requisitos de armazenamento grandes para sua
configuração e estado. O aplicativo também deve ser utilizável em interrupções
planejadas e não planejadas. Para essa finalidade, Service Fabric fornece um Key-Value
Store (KVS) que é um repositório replicado, transacional e persistente.
Modularidade
O Controlador de Rede foi projetado com uma arquitetura modular, com cada um dos
serviços de rede, como o serviço de redes virtuais e o serviço de firewall, integrados
como serviços individuais.
Essa arquitetura de aplicativo oferece os seguintes benefícios.
1. A modularidade do Controlador de Rede permite o desenvolvimento

independente de cada um dos serviços com suporte, conforme as necessidades
evoluem. Por exemplo, o serviço balanceamento de carga de software pode ser
atualizado sem afetar nenhum dos outros serviços ou a operação normal do
2. A modularidade do Controlador de Rede permite a adição de novos serviços,
conforme a rede evolui. Novos serviços podem ser adicionados ao Controlador de
Rede sem afetar os serviços existentes.
７ Observação
Em Windows Server 2016, não há suporte para a adição de serviços de terceiros ao

Service Fabric modularidade usa esquemas de modelo de serviço para maximizar a

facilidade de desenvolvimento, implantação e manutenção de um aplicativo.
Opções de implantação do controlador de rede

Para implantar o Controlador de Rede usando System Center Virtual Machine Manager
(VMM), consulte Configurar um controlador de rede SDN na malha do VMM.
Para implantar o Controlador de Rede usando scripts, consulte Implantar uma

infraestrutura de rede definida pelo software usando scripts.
Para implantar o Controlador de Rede usando Windows PowerShell, consulte Implantar

o Controlador de Rede usando Windows PowerShell
Para obter mais informações sobre o Controlador de Rede, consulte Controlador de

Rede.
Instalar a função de servidor do
controlador de rede usando
Gerenciador do Servidor
Este tópico fornece instruções sobre como instalar a função de servidor controlador de
rede usando Gerenciador do Servidor.
） Importante
Não implante a função de servidor controlador de rede em hosts físicos. Para

implantar o Controlador de Rede, você deve instalar a função de servidor
controlador de rede em uma VM (máquina virtual) do Hyper-V instalada em um
host Hyper-V. Depois de instalar o Controlador de Rede em VMs em três hosts
Hyper-V diferentes, você deve habilitar os hosts Hyper-V para SDN (Rede Definida
por Software) adicionando os hosts ao Controlador de Rede usando o comando
Windows PowerShell New-NetworkControllerServer. Ao fazer isso, você está
habilitando o software SDN Load Balancer funcionar. Para obter mais informações,
consulte New-NetworkControllerServer.
Depois de instalar o Controlador de Rede, você deve usar comandos Windows

PowerShell para configuração adicional do Controlador de Rede. Para obter mais
informações, consulte Implantar Controlador de Rede usando Windows PowerShell.
Para instalar o Controlador de Rede

Avançar.
2. Em Selecionar Tipo de Instalação, mantenha a configuração padrão e clique em

Avançar.
3. Em Selecionar Servidor de Destino, escolha o servidor onde você deseja instalar o

Controlador de Rede e clique em Avançar.
4. Em Selecionar Funções de Servidor, em Funções, clique em Controlador de Rede.
5. A caixa de diálogo Adicionar recursos necessários para o Controlador de Rede é

aberta. Clique em Adicionar Recursos.
6. Em Selecionar Funções de Servidor, clique em Avançar.

7. Em Selecionar Recursos, clique em Avançar.
8. No Controlador de Rede , clique em Avançar.
9. Em Confirmar seleções de instalação, examine suas escolhas. A instalação do

Controlador de Rede requer que você reinicie o computador após a execução do
assistente. Por isso, clique em Reiniciar o servidor de destino automaticamente,
se necessário. A caixa de diálogo Adicionar Funções e Assistente de Recursos é
aberta. Clique em Sim.
10. Em Confirmar seleções de instalação, clique em Instalar.
11. A função de servidor controlador de rede é instalada no servidor de destino e, em

seguida, o servidor é reiniciado.
12. Depois que o computador for reiniciado, faça logon no computador e verifique a
instalação do Controlador de Rede exibindo Gerenciador do Servidor.
Consulte Também
Controlador de rede
Etapas de pós-implantação para
Controlador de Rede
Ao instalar o Controlador de Rede, você pode escolher implantações Kerberos ou não

Kerberos.
Para implantações não Kerberos, você deve configurar certificados.
Configurar certificados para implantações não

Kerberos
Se os computadores ou máquinas virtuais (VMs) para o Controlador de Rede e o cliente
de gerenciamento não ingressarem no domínio, você deverá configurar a autenticação
baseada em certificado concluindo as etapas a seguir.
Crie um certificado no Controlador de Rede para Autenticação do computador. O

nome da assunto do certificado deve ser o mesmo que o nome DNS do
computador ou da VM do Controlador de Rede.
Crie um certificado no cliente de gerenciamento. Esse certificado deve ser confiável

para o Controlador de Rede.
Registrar um certificado no computador ou VM do Controlador de Rede. O

certificado deve atender aos requisitos a seguir.
A finalidade da Autenticação do Servidor e a finalidade da Autenticação do

Cliente devem ser configuradas nas extensões uso aprimorado de chave (EKU)
ou Políticas de Aplicativo. O identificador de objeto para Autenticação de
Servidor é 1.3.6.1.5.5.7.3.1. O identificador de objeto para Autenticação de
Cliente é 1.3.6.1.5.5.7.3.2.
O nome da assunto do certificado deve ser resolvido para:
O endereço IP do computador ou VM do Controlador de Rede, se o

Controlador de Rede for implantado em um único computador ou VM.
O endereço IP REST, se o Controlador de Rede for implantado em vários
computadores, várias VMs ou ambos.
Esse certificado deve ser confiável para todos os clientes REST. O certificado
também deve ser confiável pelo MUX (Multiplexador de Balanceamento de
Carga de Software) (SLB) e pelos computadores host de southbound
gerenciados pelo Controlador de Rede.
O certificado pode ser inscrito por uma AC (Autoridade de Certificação) ou

pode ser um certificado auto-assinado. Certificados auto-assinados não são
recomendados para implantações de produção, mas são aceitáveis para
ambientes de laboratório de teste.
O mesmo certificado deve ser provisionado em todos os nós do Controlador de

Rede. Depois de criar o certificado em um nó, você pode exportar o certificado
(com chave privada) e importá-lo em outros nós.
Para obter mais informações, consulte Controlador de Rede.

Você pode usar este tópico para saber mais sobre a Virtualização de Funções de Rede,
que permite implantar dispositivos de rede virtual, como o Firewall do Datacenter, o
Gateway RAS multilocatário e o MUX (Balanceamento de Carga de Software).
７ Observação
Além deste tópico, a documentação da Virtualização da Função de Rede a seguir

está disponível.
Visão geral do firewall do datacenter

Gateway de RAS para SDN
SLB (balanceamento de carga do software) para SDN
Nos datacenters definidos pelo software de hoje, as funções de rede que estão sendo
executadas por dispositivos de hardware (como balanceadores de carga, firewalls,
roteadores, comutadores e assim por diante) estão cada vez mais virtualizadas como
dispositivos virtuais. Essa "virtualização da função de rede" é uma progressão natural de
virtualização do servidor e de virtualização de rede. Os dispositivos virtuais estão
surgindo rapidamente e criando um novo mercado. Eles continuam gerando interesse e
ganhando força nas plataformas de virtualização e nos serviços de nuvem.
A Microsoft incluiu um gateway autônomo como uma solução de virtualização

começando com Windows Server 2012 R2. Para obter mais informações, consulte
Gateway do Windows Server. Agora, com Windows Server 2016 a Microsoft continua a
expandir e investir no mercado de virtualização de funções de rede.
Benefícios da solução de virtualização

Uma solução virtual é dinâmica e fácil de alterar porque é uma máquina virtual pré-
criada e personalizada. Pode ser uma ou mais máquinas virtuais empacotadas,
atualizadas e mantidas como uma unidade. Junto com o SDN (rede definida pelo
software), você obtém a agilidade e a flexibilidade necessárias na infraestrutura baseada
em nuvem atual. Por exemplo:
O SDN apresenta a rede como um recurso dinâmico e em pool.
O SDN facilita o isolamento do locatário.
O SDN maximiza a escala e o desempenho.
Os dispositivos virtuais permitem a expansão contínua da capacidade e a

mobilidade da carga de trabalho.
Os dispositivos virtuais minimizam a complexidade operacional.
Os dispositivos virtuais permitem que os clientes adquiram, implantem e

gerenciem facilmente soluções pré-integradas.
Os clientes podem mover facilmente a solução de virtualização para qualquer

lugar na nuvem.
Os clientes podem dimensionar os dispositivos virtuais para cima ou para baixo

dinamicamente com base na demanda.
Para obter mais informações sobre o SDN da Microsoft, consulte Rede Definida pelo
Software.
Quais funções de rede estão sendo virtualizadas?

O marketplace para funções de rede virtualizadas está crescendo rapidamente. As
seguintes funções de rede estão sendo virtualizadas:
Segurança
Firewall
Antivírus
DDoS (Negação Distribuída de Serviço)
IPS/IDS (Sistema de Detecção de Intrusões/Sistema de Detecção de Intrusões)
Otimizadores de aplicativo/WAN
Edge
Gateway site a site
Gateways L3
Roteadores
Comutadores
NAT
Balanceadores de carga (não necessariamente na borda)
Proxy HTTP
Por que a Microsoft é uma ótima plataforma

para dispositivos virtuais
A plataforma da Microsoft foi projetada para ser uma ótima plataforma para criar e
implantar dispositivos virtuais. Eis o motivo:
A Microsoft fornece funções de rede virtualizadas principais com Windows Server

2016.
Você pode implantar uma solução de virtualização do fornecedor de sua escolha.
Você pode implantar, configurar e gerenciar seus dispositivos virtuais com o

Controlador de Rede da Microsoft que vem com Windows Server 2016. Para obter
mais informações sobre o Controlador de Rede, consulte Controlador de Rede.
O Hyper-V pode hospedar os principais sistemas operacionais convidados de que

você precisa.
Virtualização de função de rede no Windows

Server 2016
Funções de dispositivos virtuais fornecidas pela Microsoft
Os seguintes dispositivos virtuais são fornecidos com Windows Server 2016:
Balanceador de carga de software
Um balanceador de carga de camada 4 que opera em escala de datacenter. Essa é uma

versão semelhante do balanceador de carga do Azure que foi implantada em escala no
ambiente do Azure. Para obter mais informações sobre o microsoft software Load
Balancer, consulte SLB (Balanceamento de Carga de Software) para SDN. Para obter
mais informações sobre Microsoft Azure Serviços de Balanceamento de Carga, consulte
Microsoft Azure Serviços de Balanceamento de Carga .
Gateway. O Gateway ras fornece todas as combinações das seguintes funções de

gateway.
Gateway site a site
O Gateway ras fornece um gateway multilocatário compatível com BGP (Border

Gateway Protocol) que permite que seus locatários acessem e gerenciem seus
recursos por meio de conexões VPN site a site de sites remotos e que permite o
fluxo de tráfego de rede entre recursos virtuais nas redes físicas de nuvem e
locatário. Para obter mais informações sobre o Gateway ras, consulte a Alta
Disponibilidade do Gateway de RAS e o Gateway ras.
Gateway de encaminhamento
O Gateway ras roteia o tráfego entre redes virtuais e a rede física do provedor de
hospedagem. Por exemplo, se os locatários criarem uma ou mais redes virtuais e
precisarem de acesso a recursos compartilhados na rede física no provedor de
hospedagem, o gateway de encaminhamento poderá rotear o tráfego entre a rede
virtual e a rede física para fornecer aos usuários que trabalham na rede virtual os
serviços necessários. Para obter mais informações, consulte a Alta Disponibilidade
do Gateway ras e o gateway RAS.
Gateways de túnel GRE
Os túneis baseados em GRE permitem a conectividade entre redes virtuais de

locatário e redes externas. Como o protocolo GRE é leve e o suporte para GRE está
disponível na maioria dos dispositivos de rede, ele se torna uma opção ideal para
túnel em que a criptografia de dados não é necessária. O suporte a GRE em túneis
Site a Site (S2S) resolve o problema de encaminhamento entre redes virtuais de
locatário e redes externas de locatário usando um gateway multilocatário. Para
obter mais informações sobre túneis GRE, consulte Túnel GRE em Windows Server
2016.
Plano de controle de roteamento com BGP
O Controle de Roteamento de HNV (Virtualização de Rede Hyper-V) é a entidade lógica

centralizada no plano de controle, que carrega todas as rotas do plano endereço do
cliente e aprende dinamicamente e atualiza os roteadores distribuídos do Gateway ras
na rede virtual. Para obter mais informações, consulte a Alta Disponibilidade do
Gateway ras e o gateway RAS.
Firewall multilocatário distribuído
O firewall protege a camada de rede de redes virtuais. As políticas são impostas na

porta SDN-vSwitch de cada VM de locatário. Ele protege todos os fluxos de tráfego:
leste-oeste e norte-sul. As políticas são enviadas por push pelo portal do locatário e o
Controlador de Rede as distribui para todos os hosts aplicáveis. Para obter mais
informações sobre o firewall multilocatário distribuído, consulte Visão geral do Firewall
do Datacenter.
O que é o Firewall do Datacenter?
O Firewall do Datacenter é uma camada de rede, cinco tuplas (protocolo, números de

porta de origem e destino, endereços IP de origem e destino), firewall SDN (Rede
Definida pelo Software) com estado e multilocatário. O Firewall do Datacenter protege
os fluxos de tráfego leste-oeste e norte-sul na camada de rede de redes virtuais e redes
VLAN tradicionais.
Como funciona o Firewall do Datacenter

Habilite e configure o Firewall do Datacenter criando NSGs (grupos de segurança de
rede) que são aplicados a uma sub-rede ou a um adaptador de rede. As políticas de
firewall são impostas na porta vSwitch de cada VM (máquina virtual) de locatário. As
políticas são enviadas por push pelo portal do locatário e o Controlador de Rede as
distribui para todos os hosts aplicáveis.
Os administradores de locatários podem instalar e configurar políticas de firewall para

ajudar a proteger suas redes contra tráfego indesejado proveniente de redes de Internet
e intranet.
O administrador do provedor de serviços ou o administrador de locatários podem
gerenciar políticas de Firewall do Datacenter por meio do Controlador de Rede e das
APIs norte. Você também pode configurar e gerenciar políticas de Firewall do
Datacenter usando Windows Admin Center.
Vantagens para provedores de serviços de

nuvem
O Firewall do Datacenter oferece as seguintes vantagens para CSPs:
Uma solução de firewall altamente escalonável, gerenciável e diagnosticável

baseada em software que pode ser oferecida aos locatários
Liberdade para mover VMs de locatário para hosts de computação diferentes sem
interromper políticas de firewall de locatário
Implantado como um firewall do agente host da porta vSwitch
As VMs de locatário obtêm as políticas atribuídas ao firewall do agente host

vSwitch
As regras de firewall são configuradas em cada porta vSwitch,

independentemente do host real que executa a VM
Oferece proteção para VMs de locatário independente do sistema operacional
convidado do locatário
Vantagens para locatários

O Firewall do Datacenter oferece as seguintes vantagens para locatários:
Capacidade de definir regras de firewall para ajudar a proteger cargas de trabalho

voltadas para a Internet e cargas de trabalho internas em redes
Capacidade de definir regras de firewall para ajudar a proteger o tráfego entre

VMs na mesma sub-rede de Camada 2 (L2), bem como entre VMs em diferentes
sub-redes L2
Capacidade de definir regras de firewall para ajudar a proteger e isolar o tráfego

de rede entre redes locais de locatário e suas redes virtuais no provedor de
serviços
Capacidade de aplicar políticas de firewall a redes VLAN tradicionais e redes

virtuais baseadas em sobreposição
Próximas etapas
Usar o Firewall do Datacenter para configurar ACLs com o Windows Admin Center
Usar o Firewall do Datacenter para configurar ACLs com o PowerShell
Módulo do Learn: Implementar Load Balancer de Software e Firewall do Datacenter
no Azure Stack HCI
O que é o Gateway ras (Serviço de
Acesso Remoto) para rede definida pelo
software?
O Gateway ras é um roteador bgp (border gateway protocol) baseado em software

projetado para CSPs (provedores de serviços de nuvem) e empresas que hospedam
redes virtuais multilocatários usando a HNV (Virtualização de Rede Hyper-V). Você pode
usar o Gateway ras para rotear o tráfego de rede entre uma rede virtual e outra rede,
local ou remota.
O Gateway ras requer o Controlador de Rede, que executa a implantação de pools de

gateway, configura conexões de locatário em cada gateway e alterna fluxos de tráfego
de rede para um gateway em espera em caso de falha de gateway.
７ Observação
Multilocatário é a capacidade de uma infraestrutura de nuvem dar suporte às

cargas de trabalho de máquina virtual (VM) de vários locatários, mas isolá-las umas
das outras, enquanto todas as cargas de trabalho são executadas na mesma
infraestrutura. As várias cargas de trabalho de um locatário individual podem se
interconectar e serem gerenciadas remotamente, mas esses sistemas não
interconectam com as cargas de trabalho de outros locatários, nem outros
locatários podem gerenciá-las remotamente.
Recursos
O Gateway ras oferece uma série de recursos para VPN (rede virtual privada), túnel,
encaminhamento e roteamento dinâmico.
VPN IPsec site a site

Esse recurso de Gateway ras permite que você conecte duas redes em locais físicos
diferentes na Internet usando uma conexão VPN (rede virtual privada) site a site (S2S).
Essa é uma conexão criptografada usando o protocolo VPN IKEv2.
Para CSPs que hospedam muitos locatários em seu datacenter, o Gateway ras fornece
uma solução de gateway multilocatário que permite que os locatários acessem e
gerenciem seus recursos por meio de conexões VPN site a site de sites remotos. O
Gateway ras permite o fluxo de tráfego de rede entre os recursos virtuais em seu
datacenter e sua rede física.
Túneis GRE site a site

Túneis baseados em GRE (Encapsulamento de Roteamento Genérico) permitem a
conectividade entre redes virtuais de locatário e redes externas. Como o protocolo GRE
é leve e o suporte para GRE está disponível na maioria dos dispositivos de rede, é uma
opção ideal para túnel em que a criptografia de dados não é necessária.
O suporte a GRE em túneis S2S resolve o problema de encaminhamento entre redes

virtuais de locatário e redes externas de locatário usando um gateway multilocatário.
Encaminhamento de camada 3
O encaminhamento L3 (Camada 3) permite a conectividade entre a infraestrutura física
no datacenter e a infraestrutura virtualizada na nuvem de virtualização de Rede Hyper-
V. Usando a conexão de encaminhamento L3, as VMs de rede de locatário podem se
conectar a uma rede física por meio do gateway SDN, que já está configurado em um
ambiente de SDN (rede definida por software). Nesse caso, o gateway SDN atua como
um roteador entre a rede virtual e a rede física.
Roteamento dinâmico com BGP

O BGP reduz a necessidade de configuração de roteamento manual em roteadores,
porque ele é um protocolo de roteamento dinâmico e aprende rotas entre sites
conectados usando conexões VPN site a site automaticamente. Se sua organização tiver
vários sites conectados usando roteadores habilitados para BGP, como o Gateway ras, o
BGP permitirá que os roteadores calculem e usem automaticamente rotas válidas entre
si em caso de interrupção ou falha de rede.
O Refletor de Rota BGP incluído no Gateway ras fornece uma alternativa à topologia de
malha completa do BGP necessária para a sincronização de rotas entre roteadores. Para
obter mais informações, consulte O que é o refletor de rota?
Como funciona o Gateway ras

O Gateway ras roteia o tráfego de rede entre a rede física e os recursos de rede de VM,
independentemente do local. Você pode rotear o tráfego de rede no mesmo local físico
ou em muitos locais diferentes.
Você pode implantar o Gateway ras em pools de alta disponibilidade que usam vários
recursos ao mesmo tempo. Os pools de gateway contêm várias instâncias do Gateway
ras para alta disponibilidade e failover.
Você pode escalar ou reduzir facilmente um pool de gateway adicionando ou

removendo VMs de gateway no pool. A remoção ou adição de gateways não
interrompe os serviços fornecidos por um pool. Você também pode adicionar e remover
pools inteiros de gateways. Para obter mais informações, consulte Alta disponibilidade
do Gateway de RAS.
Cada pool de gateways fornece redundância M+N. Isso significa que o número 'M' de
VMs de gateway ativas é suportado pelo número 'N' de VMs de gateway em espera. A
redundância M+N oferece mais flexibilidade para determinar o nível de confiabilidade
necessário ao implantar o Gateway de RAS.
Você pode atribuir um único endereço IP público a todos os pools ou a um subconjunto

de pools. Isso reduz consideravelmente o número de endereços IP públicos que você
deve usar, pois é possível que todos os locatários se conectem à nuvem em um único
endereço IP.
Próximas etapas
Arquitetura de implantação do gateway ras

Visão geral do Controlador de Rede
Planejar a implantação do Controlador de Rede
Arquitetura de implantação do Gateway
de RAS
Você pode usar este tópico para saber mais sobre a implantação do CSP (Provedor de
Serviços de Nuvem) do Gateway ras, incluindo pools de Gateway ras, refletores de rota e
implantação de vários gateways para locatários individuais.
As seções a seguir fornecem breves visões gerais de alguns dos novos recursos do
Gateway ras para que você possa entender como usar esses recursos no design da
implantação do gateway.
Além disso, uma implantação de exemplo é fornecida, incluindo informações sobre o

processo de adição de novos locatários, sincronização de rotas e roteamento de plano
de dados, failover do gateway e do Refletor de Rota e muito mais.
Usando novos recursos do gateway RAS para projetar sua implantação
Implantação de exemplo
Adicionando novos locatários e o emparelhamento de EBGP de Espaço de

Endereço do Cliente (CA)
Sincronização de rotas e roteamento de plano de dados
Como o controlador de rede responde ao gateway RAS e ao failover do refletor de

rota
Vantagens de usar novos recursos do gateway RAS
Usando novos recursos do gateway RAS para

projetar sua implantação
O Gateway ras inclui vários novos recursos que mudam e melhoram a maneira como
você implanta sua infraestrutura de gateway em seu datacenter.
Refletor de rota BGP
A funcionalidade do BgP (Border Gateway Protocol) Route Reflector agora está incluída
no Gateway ras e fornece uma alternativa à topologia de malha completa bgp que
normalmente é necessária para sincronização de rotas entre roteadores. Com a
sincronização completa da malha, todos os roteadores BGP devem se conectar com
todos os outros roteadores na topologia de roteamento. No entanto, quando você usa
o Refletor de Rota, o Refletor de Rota é o único roteador que se conecta com todos os
outros roteadores, chamados clientes do Refletor de Rota BGP, simplificando assim a
sincronização de rotas e reduzindo o tráfego de rede. O Refletor de Rota aprende todas
as rotas, calcula as melhores rotas e redistribui as melhores rotas para seus clientes BGP.
Para obter mais informações, consulte o que há de novo no Gateway ras.
Gateway Pools
Em Windows Server 2016, você pode criar muitos pools de gateway de tipos diferentes.
Os pools de gateway contêm muitas instâncias do Gateway ras e roteiam o tráfego de
rede entre redes físicas e virtuais.
Para obter mais informações, consulte o que há de novo no Gateway ras e alta
disponibilidade do gateway RAS.
Escalabilidade do pool de gateway

Você pode dimensionar facilmente um pool de gateway para cima ou para baixo
adicionando ou removendo VMs de gateway no pool. A remoção ou adição de
gateways não interrompe os serviços fornecidos por um pool. Você também pode
adicionar e remover pools inteiros de gateways.
Redundância do pool de gateway M+N

Cada pool de gateway é redundante em M+N. Isso significa que um número 'M' de VMs
de gateway ativo é feito com backup por um número 'N' de VMs de gateway em espera.
A redundância M+N fornece mais flexibilidade para determinar o nível de confiabilidade
necessário ao implantar o Gateway ras.
Implantação de exemplo
A ilustração a seguir fornece um exemplo com o emparelhamento eBGP sobre conexões
VPN site a site configuradas entre dois locatários, Contoso e Woodgrove, e o datacenter
CSP da Fabrikam.
Neste exemplo, a Contoso requer largura de banda de gateway adicional, levando à

decisão de design da infraestrutura de gateway para encerrar o site da Contoso Los
Angeles na GW3 em vez de GW2. Por isso, as conexões VPN da Contoso de diferentes
sites terminam no datacenter CSP em dois gateways diferentes.
Ambos os gateways, GW2 e GW3, foram os primeiros Gateways RAS configurados pelo
Controlador de Rede quando o CSP adicionou os locatários da Contoso e woodgrove à
sua infraestrutura. Por isso, esses dois gateways são configurados como Refletores de
Rota para esses clientes correspondentes (ou locatários). GW2 é o Refletor de Rota
contoso, e GW3 é o Refletor de Rota woodgrove - além de ser o ponto de encerramento
do Gateway ras CSP para a conexão VPN com o site da Contoso Los Angeles HQ.
７ Observação
Um Gateway ras pode rotear o tráfego de rede virtual e física para até cem
locatários diferentes, dependendo dos requisitos de largura de banda de cada
locatário.
Como Refletores de Rota, GW2 envia rotas de espaço da Contoso CA para o Controlador
de Rede, e GW3 envia rotas de espaço de AC do Woodgrove para o Controlador de
Rede.
O Controlador de Rede envia por push as políticas de Virtualização de Rede hyper-V

para as redes virtuais Contoso e Woodgrove, bem como políticas RAS para os Gateways
ras e políticas de balanceamento de carga para os Multiplexers (MUXes) configurados
como um pool de Balanceamento de Carga de Software.
Adicionando novos locatários e o

emparelhamento de espaço eBGP (Endereço do
Cliente)
Ao assinar um novo cliente e adicionar o cliente como um novo locatário em seu
datacenter, você pode usar o processo a seguir, grande parte dos quais é executado
automaticamente pelos roteadores eBGP do Controlador de Rede e do Gateway ras.
1. Provisione uma nova rede virtual e cargas de trabalho de acordo com os requisitos
do locatário.
2. Se necessário, configure a conectividade remota entre o locatário remoto

Enterprise site e sua rede virtual no datacenter. Quando você implanta uma
conexão VPN site a site para o locatário, o Controlador de Rede seleciona
automaticamente uma VM do Gateway ras disponível no pool de gateway
disponível e configura a conexão.
3. Ao configurar a VM do Gateway ras para o novo locatário, o Controlador de Rede

também configura o Gateway ras como um Roteador BGP e o designa como o
Refletor de Rota para o locatário. Isso é verdadeiro mesmo em circunstâncias em
que o Gateway ras serve como um gateway ou como gateway e Refletor de Rota,
para outros locatários.
4. Dependendo se o roteamento de espaço de AUTORIDADE está configurado para

usar redes configuradas estaticamente ou roteamento bgp dinâmico, o
Controlador de Rede configura as rotas estáticas correspondentes, os vizinhos BGP
ou ambos na VM do Gateway ras e no Refletor de Rota.
７ Observação
Depois que o Controlador de Rede tiver configurado um Gateway ras e o

Refletor de Rota para o locatário, sempre que o mesmo locatário exigir
uma nova conexão VPN site a site, o Controlador de Rede verificará a
capacidade disponível nesta VM do Gateway ras. Se o gateway original
puder atender à capacidade necessária, a nova conexão de rede também
será configurada na mesma VM do Gateway ras. Se a VM do Gateway
ras não puder lidar com capacidade adicional, o Controlador de Rede
selecionará uma nova VM de Gateway ras disponível e configurará a
nova conexão nela. Essa nova VM do Gateway ras associada ao locatário
torna-se o cliente do Refletor de Rota do Refletor de Rota de Gateway
ras de locatário original.
Como os pools de Gateway ras estão por trás de SLBs (Balanceadores de

Carga de Software), os endereços VPN site a site dos locatários usam um
único endereço IP público, chamado de ENDEREÇO IP virtual (VIP), que é
traduzido pelos SLBs em um endereço IP interno do datacenter,
chamado de ENDEREÇO IP dinâmico (DIP), para um Gateway RAS que
roteia o tráfego para o locatário Enterprise. Esse mapeamento de
endereço IP público para privado pelo SLB garante que os túneis VPN
site a site sejam estabelecidos corretamente entre os sites de Enterprise
e os Gateways de RAS CSP e Refletores de Rota.
Para obter mais informações sobre SLB, VIPs e DIPs, consulte SLB
(Balanceamento de Carga de Software) para SDN.
5. Depois que o túnel VPN site a site entre o site Enterprise e o gateway RAS do
datacenter CSP for estabelecido para o novo locatário, as rotas estáticas associadas
aos túneis serão provisionadas automaticamente nos lados Enterprise e CSP do
túnel.
6. Com o roteamento BGP de espaço de AC, o emparelhamento eBGP entre os sites

de Enterprise e o Refletor de Rota do Gateway do RAS CSP também é estabelecido.
Sincronização de rotas e roteamento de plano

de dados
Depois que o emparelhamento eBGP é estabelecido entre Enterprise sites e o Refletor
de Rota do Gateway de RAS CSP, o Refletor de Rota aprende todas as rotas Enterprise
usando o roteamento bgp dinâmico. O Refletor de Rota sincroniza essas rotas entre
todos os clientes do Refletor de Rota para que todos eles sejam configurados com o
mesmo conjunto de rotas.
O Refletor de Rota também atualiza essas rotas consolidadas, usando a sincronização de

rotas, para o Controlador de Rede. Em seguida, o Controlador de Rede converte as rotas
nas políticas de Virtualização de Rede do Hyper-V e configura a Rede de Malha para
garantir que o roteamento de caminho de dados de ponta a ponta seja provisionado.
Esse processo torna a rede virtual do locatário acessível no locatário Enterprise sites.
Para roteamento do Plano de Dados, os pacotes que chegam às VMs do Gateway ras
são roteados diretamente para a rede virtual do locatário, pois as rotas necessárias
agora estão disponíveis com todas as VMs do Gateway RAS participantes.
Da mesma forma, com as políticas de Virtualização de Rede do Hyper-V em vigor, a

rede virtual do locatário roteia pacotes diretamente para as VMs do Gateway ras (sem
precisar saber sobre o Refletor de Rota) e, em seguida, para os sites de Enterprise pelos
túneis VPN site a site.
Além disso. retornar o tráfego da rede virtual do locatário para o locatário remoto
Enterprise site ignora os SLBs, um processo chamado Retorno do Servidor Direto (DSR).
Como o controlador de rede responde ao

gateway RAS e ao failover do refletor de rota
A seguir estão dois cenários de failover possíveis : um para clientes do Refletor de Rota
de Gateway ras e outro para refletores de rota de gateway ras - incluindo informações
sobre como o Controlador de Rede lida com o failover para VMs em qualquer
configuração.
Falha de VM de um cliente do refletor de rota BGP do

gateway RAS
O Controlador de Rede executa as seguintes ações quando um cliente do Refletor de
Rota do Gateway ras falha.
７ Observação
Quando um Gateway ras não é um Refletor de Rota para a infraestrutura BGP de

um locatário, ele é um cliente do Refletor de Rota na infraestrutura BGP do
locatário.
O Controlador de Rede seleciona uma VM de Gateway RAS em espera disponível e

provisiona a nova VM do Gateway ras com a configuração da VM do Gateway ras
com falha.
O Controlador de Rede atualiza a configuração de SLB correspondente para

garantir que os túneis VPN site a site de sites de locatários para o Gateway RAS
com falha sejam estabelecidos corretamente com o novo Gateway ras.
O Controlador de Rede configura o cliente do Refletor de Rota BGP no novo

gateway.
O Controlador de Rede configura o novo cliente do Refletor de Rota BGP do

Gateway de RAS como ativo. O Gateway ras inicia imediatamente o
emparelhamento com o Refletor de Rota do locatário para compartilhar
informações de roteamento e habilitar o emparelhamento eBGP para o site de
Enterprise correspondente.
Falha de VM para um refletor de rota BGP do gateway

RAS
O Controlador de Rede executa as seguintes ações quando um Refletor de Rota BGP do
Gateway de RAS falha.
O Controlador de Rede seleciona uma VM de Gateway RAS em espera disponível e

provisiona a nova VM do Gateway ras com a configuração da VM do Gateway ras
com falha.
O Controlador de Rede configura o Refletor de Rota na nova VM do Gateway ras e

atribui à nova VM o mesmo endereço IP que foi usado pela VM com falha,
fornecendo assim a integridade da rota, apesar da falha da VM.
O Controlador de Rede atualiza a configuração de SLB correspondente para

garantir que os túneis VPN site a site de sites de locatários para o Gateway RAS
com falha sejam estabelecidos corretamente com o novo Gateway ras.
O Controlador de Rede configura a nova VM do Refletor de Rota BGP do Gateway

de RAS como ativa.
O Refletor de Rota imediatamente se torna ativo. O túnel VPN site a site para o
Enterprise é estabelecido e o Refletor de Rota usa o emparelhamento eBGP e troca
rotas com os roteadores do site Enterprise.
Após a seleção de rotas BGP, o Refletor de Rota BGP do Gateway de RAS atualiza
os clientes do Refletor de Rota de Locatário no datacenter e sincroniza rotas com o
Controlador de Rede, disponibilizando o Caminho de Dados de Ponta a Ponta para
tráfego de locatário.
Vantagens de usar novos recursos do gateway
RAS
A seguir estão algumas das vantagens de usar esses novos recursos do Gateway ras ao
projetar sua implantação do Gateway ras.
Escalabilidade do Gateway ras
Como você pode adicionar quantas VMs de Gateway RAS precisar para pools de
Gateway ras, você pode dimensionar facilmente sua implantação do Gateway ras para
otimizar o desempenho e a capacidade. Ao adicionar VMs a um pool, você pode
configurar esses Gateways RAS com conexões VPN site a site de qualquer tipo (IKEv2,
L3, GRE), eliminando gargalos de capacidade sem tempo de inatividade.
Gerenciamento simplificado de gateway de site Enterprise
Quando seu locatário tem vários sites de Enterprise, o locatário pode configurar todos
os sites com um endereço IP VPN site a site remoto e um único endereço IP de vizinho
remoto – seu VIP do Refletor de Rota BGP do Datacenter RAS do CSP para esse
locatário. Isso simplifica o gerenciamento de gateway para seus locatários.
Correção rápida da falha do gateway
Para garantir uma resposta de failover rápida, você pode configurar o tempo do
parâmetro Keepalive BGP entre as rotas de borda e o roteador de controle para um
intervalo de tempo curto, como menor ou igual a dez segundos. Com esse curto
intervalo de manter vivo, se um roteador de borda BGP do Gateway RAS falhar, a falha
será detectada rapidamente e o Controlador de Rede seguirá as etapas fornecidas nas
seções anteriores. Essa vantagem pode reduzir a necessidade de um protocolo de
detecção de falha separado, como o protocolo BFD (Detecção de Encaminhamento
Bidirecional).
Alta disponibilidade do Gateway de RAS
Você pode usar este tópico para saber mais sobre configurações de alta disponibilidade
para o SDN (Gateway Multilocatário de RAS para Rede Definida por Software).
Visão geral do gateway RAS
Visão geral dos pools de gateway
Visão geral da implantação do gateway ras
Integração do gateway ras com o controlador de rede
Visão geral do gateway RAS

Se sua organização for um CSP (Provedor de Serviços de Nuvem) ou um Enterprise com
vários locatários, você poderá implantar o Gateway ras no modo multilocatário para
fornecer roteamento de tráfego de rede de e para redes virtuais e físicas, incluindo a
Internet.
Você pode implantar o Gateway ras no modo multilocatário como um gateway de borda
para rotear o tráfego de rede do cliente locatário para redes virtuais e recursos de
locatário.
Ao implantar várias instâncias de VMs do Gateway ras que fornecem alta

disponibilidade e failover, você está implantando um pool de gateway. Em Windows
Server 2012 R2, todas as VMs do gateway formaram um único pool, o que dificultava
um pouco a separação lógica da implantação do gateway. Windows Server 2012
gateway R2 ofereceu uma implantação de redundância 1:1 para as VMs de gateway, o
que resultou na subutilização da capacidade disponível para conexões VPN S2S (site a
site).
Esse problema é resolvido em Windows Server 2016, que fornece vários Pools de
Gateway – que podem ser de diferentes tipos para separação lógica. O novo modo de
redundância M+N permite uma configuração de failover mais eficiente.
Para obter mais informações de visão geral sobre o Gateway de RAS, consulte o
Gateway de RAS.
Visão geral dos pools de gateway

Em Windows Server 2016, você pode implantar gateways em um ou mais pools.
A ilustração a seguir mostra diferentes tipos de pools de gateway que fornecem

roteamento de tráfego entre redes virtuais.
Cada pool tem as propriedades a seguir.
Cada pool é redundante em M+N. Isso significa que um número 'M' de VMs de
gateway ativas é apoiado por um número 'N' de VMs de gateway em espera. O
valor de N (gateways em espera) é sempre menor ou igual a M (gateways ativos).
Um pool pode executar qualquer uma das funções de gateway individuais -

Internet Key Exchange versão 2 (IKEv2) S2S, Camada 3 (L3) e GRE (Encapsulamento
de Roteamento Genérico) - ou o pool pode executar todas essas funções.
Você pode atribuir um único endereço IP público a todos os pools ou a um

subconjunto de pools. Isso reduz consideravelmente o número de endereços IP
públicos que você deve usar, pois é possível que todos os locatários se conectem à
nuvem em um único endereço IP. A seção abaixo sobre alta disponibilidade e
balanceamento de carga descreve como isso funciona.
Você pode dimensionar facilmente um pool de gateway para cima ou para baixo
adicionando ou removendo VMs de gateway no pool. A remoção ou adição de
gateways não interrompe os serviços fornecidos por um pool. Você também pode
adicionar e remover pools inteiros de gateways.
As conexões de um único locatário podem ser encerradas em vários pools e vários
gateways em um pool. No entanto, se um locatário tiver conexões terminadas em
um pool de gateway de tipo All , ele não poderá assinar outros pools de gateway
de tipo individual ou tipo All .
Os pools de gateway também oferecem flexibilidade para habilitar cenários adicionais:
Pools de locatário único – você pode criar um pool para uso por um locatário.
Se você estiver vendendo serviços de nuvem por meio de canais de parceiro

(revendedor), poderá criar conjuntos separados de pools para cada revendedor.
Vários pools podem fornecer a mesma função de gateway, mas capacidades

diferentes. Por exemplo, você pode criar um pool de gateway que dá suporte a
conexões IKEv2 S2S de alta taxa de transferência e alta taxa de transferência.
Visão geral da implantação do gateway ras

A ilustração a seguir demonstra uma implantação típica do CSP (Provedor de Serviços
de Nuvem) do Gateway ras.
Com esse tipo de implantação, os pools de gateway são implantados por trás de um
SLB (Software Load Balancer), que permite que o CSP atribua um único endereço IP
público para toda a implantação. Várias conexões de gateway de um locatário podem
ser encerradas em vários pools de gateway e também em vários gateways dentro de um
pool. Isso é ilustrado por meio de conexões IKEv2 S2S no diagrama acima, mas o
mesmo é aplicável a outras funções de gateway também, como gateways L3 e GRE.
Na ilustração, o dispositivo BGP MT é um Gateway Multilocatário RAS com BGP. O BGP

multilocatário é usado para roteamento dinâmico. O roteamento de um locatário é
centralizado – um único ponto, chamado refletor de rota (RR), manipula o
emparelhamento BGP para todos os sites de locatário. A RR em si é distribuída em
todos os gateways em um pool. Isso resulta em uma configuração em que as conexões
de um locatário (caminho de dados) terminam em vários gateways, mas o RR para o
locatário (ponto de emparelhamento BGP – caminho de controle) está em apenas um
dos gateways.
O roteador BGP é separado no diagrama para descrever esse conceito de roteamento

centralizado. A implementação do BGP do gateway também fornece roteamento de
trânsito, o que permite que a nuvem atue como um ponto de trânsito para roteamento
entre dois sites de locatário. Esses recursos BGP são aplicáveis a todas as funções de
gateway.
Integração do gateway ras com o controlador

de rede
O Gateway ras é totalmente integrado ao Controlador de Rede no Windows Server
2016. Quando o Gateway ras e o controlador de rede são implantados, o Controlador de
Rede executa as seguintes funções.
Implantação dos pools de gateway
Configuração de conexões de locatário em cada gateway
Alternar fluxos de tráfego de rede para um gateway em espera em caso de falha

no gateway
As seções a seguir fornecem informações detalhadas sobre o Gateway de RAS e o

Provisionamento e balanceamento de carga de conexões de gateway (IKEv2, L3 e

GRE)
Alta disponibilidade para IKEv2 S2S
Alta disponibilidade para GRE
Alta disponibilidade para gateways de encaminhamento L3
Provisionamento e balanceamento de carga de conexões

de gateway (IKEv2, L3 e GRE)
Quando um locatário solicita uma conexão de gateway, a solicitação é enviada ao
Controlador de Rede. O Controlador de Rede é configurado com informações sobre
todos os pools de gateway, incluindo a capacidade de cada pool e cada gateway em
cada pool. O Controlador de Rede seleciona o pool e o gateway corretos para a
conexão. Essa seleção se baseia no requisito de largura de banda para a conexão. O
Controlador de Rede usa um algoritmo "melhor ajuste" para escolher conexões com
eficiência em um pool. O ponto de emparelhamento BGP para a conexão também será
designado no momento se essa for a primeira conexão do locatário.
Depois que o Controlador de Rede seleciona um Gateway ras para a conexão, o

Controlador de Rede provisiona a configuração necessária para a conexão no gateway.
Se a conexão for uma conexão S2S IKEv2, o Controlador de Rede também provisionará
uma regra NAT (Conversão de Endereços de Rede) no pool de SLB; essa regra NAT no
pool de SLB direciona as solicitações de conexão do locatário para o gateway
designado. Os locatários são diferenciados pelo IP de origem, que deve ser exclusivo.
７ Observação
Conexões L3 e GRE ignoram o SLB e se conectam diretamente com o Gateway RAS

designado. Essas conexões exigem que o roteador de ponto de extremidade
remoto (ou outro dispositivo de terceiros) deve estar configurado corretamente
para se conectar ao Gateway ras.
Se o roteamento BGP estiver habilitado para a conexão, o emparelhamento BGP será

iniciado pelo Gateway de RAS e as rotas serão trocadas entre gateways de nuvem e
locais. As rotas aprendidas pelo BGP (ou que são rotas estaticamente configuradas se o
BGP não for usado) são enviadas para o Controlador de Rede. Em seguida, o
Controlador de Rede encaminha as rotas para os hosts Hyper-V nos quais as VMs de
locatário estão instaladas. Neste ponto, o tráfego de locatário pode ser roteado para o
site local correto. O Controlador de Rede também cria políticas de Virtualização de Rede
Hyper-V associadas que especificam locais de gateway e as encaminha para os hosts
Hyper-V.
Alta disponibilidade para IKEv2 S2S

Um Gateway ras em um pool consiste em conexões e emparelhamento BGP de
locatários diferentes. Cada pool tem gateways ativos 'M' e gateways de espera 'N'.
O Controlador de Rede lida com a falha dos gateways da maneira a seguir.
O Controlador de Rede constantemente pinga os gateways em todos os pools e

pode detectar um gateway com falha ou falha. O Controlador de Rede pode
detectar os seguintes tipos de falhas do Gateway ras.
Falha na VM do Gateway ras
Falha do host Hyper-V no qual o Gateway RAS está em execução
Falha no serviço do Gateway de RAS
O Controlador de Rede armazena a configuração de todos os gateways ativos

implantados. A configuração consiste em configurações de conexão e
configurações de roteamento.
Quando um gateway falha, ele afeta as conexões de locatário no gateway, bem

como as conexões de locatário que estão localizadas em outros gateways, mas
cuja RR reside no gateway com falha. O tempo de inatividade das últimas
conexões é menor que o anterior. Quando o Controlador de Rede detecta um
gateway com falha, ele executa as tarefas a seguir.
Remove as rotas das conexões afetadas dos hosts de computação.
Remove as políticas de Virtualização de Rede do Hyper-V nesses hosts.
Seleciona um gateway em espera, converte-o em um gateway ativo e configura

o gateway.
Altera os mapeamentos NAT no pool de SLB para apontar conexões para o

novo gateway.
Simultaneamente, à medida que a configuração aparece no novo gateway ativo, as

conexões IKEv2 S2S e o emparelhamento BGP são restabelecidas. As conexões e o
emparelhamento BGP podem ser iniciados pelo gateway de nuvem ou pelo
gateway local. Os gateways atualizam suas rotas e as enviam para o Controlador
de Rede. Depois que o Controlador de Rede aprende as novas rotas descobertas
pelos gateways, o Controlador de Rede envia as rotas e as políticas de
Virtualização de Rede Hyper-V associadas aos hosts Hyper-V em que residem as
VMs dos locatários afetados pela falha. Essa atividade do Controlador de Rede é
semelhante à circunstância de uma nova configuração de conexão, apenas ela
ocorre em uma escala maior.
Alta disponibilidade para GRE

O processo de resposta de failover do Gateway de RAS pelo Controlador de Rede -
incluindo detecção de falha, cópia da conexão e configuração de roteamento para o
gateway de espera, failover do roteamento BGP/estático das conexões afetadas
(incluindo a retirada e o redirecionamento de rotas em hosts de computação e
emparelhamento BGP) e reconfiguração de políticas de Virtualização de Rede Hyper-V
em hosts de computação - é o mesmo para gateways e conexões GRE. No entanto, o
restagerenciamento de conexões GRE ocorre de forma diferente e a solução de alta
disponibilidade para GRE tem alguns requisitos adicionais.
No momento da implantação do gateway, cada VM do Gateway ras recebe um DIP

(endereço IP dinâmico). Além disso, cada VM de gateway também recebe um VIP
(endereço IP virtual) para alta disponibilidade gre. Os VIPs são atribuídos somente a
gateways em pools que podem aceitar conexões GRE e não a pools não GRE. Os VIPs
atribuídos são anunciados na parte superior dos comutadores TOR (rack) usando BGP, o
que anuncia ainda mais os VIPs na rede física da nuvem. Isso torna os gateways
acessíveis dos roteadores remotos ou dispositivos de terceiros em que reside a outra
extremidade da conexão GRE. Esse emparelhamento BGP é diferente do
emparelhamento BGP no nível do locatário para a troca de rotas de locatário.
No momento do provisionamento de conexão GRE, o Controlador de Rede seleciona

um gateway, configura um ponto de extremidade GRE no gateway selecionado e
retorna o endereço VIP do gateway atribuído. Esse VIP é configurado como o endereço
do túnel GRE de destino no roteador remoto.
Quando um gateway falha, o Controlador de Rede copia o endereço VIP do gateway

com falha e outros dados de configuração para o gateway de espera. Quando o
gateway de espera se torna ativo, ele anuncia o VIP para sua opção TOR e mais adiante
na rede física. Os roteadores remotos continuam a conectar túneis GRE ao mesmo VIP e
a infraestrutura de roteamento garante que os pacotes sejam roteados para o novo
gateway ativo.
Alta disponibilidade para gateways de encaminhamento

L3
Um gateway de encaminhamento do Hyper-V Network Virtualization L3 é uma ponte
entre a infraestrutura física no datacenter e a infraestrutura virtualizada na nuvem de
Virtualização de Rede hyper-V. Em um gateway de encaminhamento L3 multilocatário,
cada locatário usa sua própria rede lógica marcada por VLAN para conectividade com a
rede física do locatário.
Quando um novo locatário cria um novo gateway L3, o Gateway do Controlador de

Rede Service Manager seleciona uma VM de gateway disponível e configura uma nova
interface de locatário com um endereço IP de espaço de CA (Endereço do Cliente)
altamente disponível (na rede lógica marcada pela VLAN do locatário). O endereço IP é
usado como o endereço IP par no gateway remoto (rede física) e é o Próximo Salto para
alcançar a rede de Virtualização de Rede Hyper-V do locatário.
Ao contrário das conexões de rede IPsec ou GRE, a opção TOR não aprenderá a rede
marcada dinamicamente pela VLAN do locatário. O roteamento para a rede marcada
por VLAN do locatário precisa ser configurado na opção TOR e em todos os
comutadores e roteadores intermediários entre a infraestrutura física e o gateway para
garantir a conectividade de ponta a ponta. Veja a seguir um exemplo de configuração
de Rede Virtual CSP, conforme descrito na ilustração abaixo.
Rede Sub-rede ID DA VLAN Gateway Padrão
Rede Lógica Contoso L3 10.127.134.0/24 1001 10.127.134.1
Woodgrove L3 Logical Network 10.127.134.0/24 1002 10.127.134.1
A seguir estão as configurações de gateway de locatário de exemplo, conforme descrito

na ilustração abaixo.
Nome do locatário Endereço IP do gateway L3 ID DA VLAN Endereço IP do par
Contoso 10.127.134.50 1001 10.127.134.55
Woodgrove 10.127.134.60 1002 10.127.134.65
Veja a seguir a ilustração dessas configurações em um datacenter CSP.

As falhas de gateway, a detecção de falhas e o processo de failover de gateway no
contexto de um gateway de encaminhamento L3 são semelhantes aos processos para
gateways IKEv2 e GRE RAS. As diferenças estão na maneira como os endereços IP
externos são tratados.
Quando o estado da VM do gateway se torna não íntegro, o Controlador de Rede

seleciona um dos gateways em espera no pool e provisiona novamente as conexões de
rede e o roteamento no gateway de espera. Ao mover as conexões, o endereço IP de
espaço de AUTORIDADE altamente disponível do gateway de encaminhamento L3
também é movido para a nova VM do gateway, juntamente com o endereço IP BGP do
espaço de AC do locatário.
Como o endereço IP de emparelhamento L3 é movido para a nova VM de gateway

durante o failover, a infraestrutura física remota é novamente capaz de se conectar a
esse endereço IP e, posteriormente, alcançar a carga de trabalho de Virtualização de
Rede hyper-V. Para roteamento dinâmico BGP, à medida que o endereço IP BGP de
espaço de AC é movido para a nova VM de gateway, o Roteador BGP remoto pode
restabelecer o emparelhamento e aprender todas as rotas de Virtualização de Rede
hyper-V novamente.
７ Observação
Você deve configurar separadamente os comutadores TOR e todos os roteadores

intermediários para usar a rede lógica marcada pela VLAN para comunicação de
locatário. Além disso, o failover L3 é restrito apenas aos racks configurados dessa
forma. Por isso, o pool de gateway L3 deve ser configurado com cuidado e a
configuração manual deve ser concluída separadamente.
O que é o SLB (Balanceador de Carga de
Software) para SDN?
Os CSPs (Provedores de Serviços de Nuvem) e as empresas que estão implantando o

SDN (Software Defined Networking) podem usar o software Load Balancer (SLB) para
distribuir uniformemente o tráfego de rede do cliente de locatário e locatário entre os
recursos de rede virtual. O SLB permite que vários servidores hospedem a mesma carga
de trabalho, fornecendo alta disponibilidade e escalabilidade.
Os Load Balancer de software podem fornecer uma borda unificada e multilocatário

integrando-se a tecnologias de SDN, como Gateway ras, Firewall do Datacenter e
Refletor de Rota.
７ Observação
Não há suporte para multilocatário para VLANs pelo Controlador de Rede. No

entanto, você pode usar VLANs com SLB para cargas de trabalho gerenciadas do
provedor de serviços, como a infraestrutura do datacenter e servidores Web de alta
densidade.
Usando o software Load Balancer, você pode escalar horizontalmente seus recursos de
balanceamento de carga usando VMs (máquinas virtuais) SLB nos mesmos servidores de
computação do Hyper-V que você usa para suas outras cargas de trabalho de VM. Por
isso, o Software Load Balancer dá suporte à criação rápida e à exclusão de pontos de
extremidade de balanceamento de carga, conforme necessário para operações CSP.
Além disso, o Software Load Balancer dá suporte a dezenas de gigabytes por cluster,
fornece um modelo de provisionamento simples e é fácil de escalar horizontalmente.
Para saber como gerenciar políticas de software Load Balancer usando Windows Admin
Center, consulte Gerenciar Load Balancer de software para SDN.
O que o Software Load Balancer inclui?

O software Load Balancer inclui os seguintes recursos:
Serviços de balanceamento de carga de camada 4 (L4) para tráfego TCP/UDP
norte/sul e leste/oeste.
Rede pública e balanceamento de carga de tráfego de rede interno.
Suporte a DIPs (endereços IP dinâmicos) em VLANs (redes virtuais de área local) e

em redes virtuais que você cria usando a Virtualização de Rede do Hyper-V.
Suporte à investigação de integridade.
Pronto para escala de nuvem, incluindo capacidade de expansão e capacidade de

expansão para multiplexadores e agentes host.
Para obter mais informações, consulte Recursos de software Load Balancer neste artigo.
Como funciona o software Load Balancer

O software Load Balancer funciona mapeando VIPs (endereços IP virtuais) para DIPs que
fazem parte de um conjunto de recursos de serviço de nuvem no datacenter.
OS VIPs são endereços IP únicos que fornecem acesso público a um pool de VMs com
balanceamento de carga. Por exemplo, VIPs são endereços IP expostos na Internet para
que locatários e clientes locatários possam se conectar aos recursos de locatário no
datacenter de nuvem.
DIPs são os endereços IP das VMs membro de um pool com balanceamento de carga
atrás do VIP. Os DIPs são atribuídos dentro da infraestrutura de nuvem aos recursos de
locatário.
Os VIPs estão localizados no MUX (Multiplexer SLB). O MUX consiste em uma ou mais
VMs. O Controlador de Rede fornece a cada MUX cada VIP, e cada MUX, por sua vez,
usa o BGP (Border Gateway Protocol) para anunciar cada VIP para roteadores na rede
física como uma rota /32. O BGP permite que os roteadores de rede física:
Saiba que um VIP está disponível em cada MUX, mesmo que os MUXes estejam
em sub-redes diferentes em uma rede de Camada 3.
Espalhe a carga para cada VIP em todos os MUXes disponíveis usando o

roteamento ECMP (Caminho Múltiplo de Custo Igual).
Detecte automaticamente uma falha ou remoção de MUX e interrompa o envio de

tráfego para o MUX com falha.
Espalhe a carga do MUX com falha ou removido entre os MUXes íntegros.

Quando o tráfego público chega da Internet, o SLB MUX examina o tráfego, que contém
o VIP como um destino, e mapeia e reescreve o tráfego para que ele chegue a um DIP
individual. Para tráfego de rede de entrada, essa transação é executada em um processo
de duas etapas dividido entre as VMs MUX e o host Hyper-V em que o DIP de destino
está localizado:
1. Balanceamento de carga – o MUX usa o VIP para selecionar um DIP, encapsula o

pacote e encaminha o tráfego para o host Hyper-V onde o DIP está localizado.
2. NAT (Conversão de Endereços de Rede) – o host Hyper-V remove o

encapsulamento do pacote, converte o VIP em um DIP, remapea as portas e
encaminha o pacote para a VM DIP.
O MUX sabe como mapear VIPs para os DIPs corretos devido às políticas de
balanceamento de carga que você define usando o Controlador de Rede. Essas regras
incluem protocolo, porta de front-end, porta de back-end e algoritmo de distribuição (5,
3 ou 2 tuplas).
Quando as VMs de locatário respondem e enviam o tráfego de rede de saída de volta

para os locais da Internet ou do locatário remoto, como o NAT é executado pelo host
Hyper-V, o tráfego ignora o MUX e vai diretamente para o roteador de borda do host
Hyper-V. Esse processo de bypass do MUX é chamado de DSR (Retorno do Servidor
Direto).
E depois que o fluxo de tráfego de rede inicial é estabelecido, o tráfego de rede de

entrada ignora completamente o MUX do SLB.
Na ilustração a seguir, um computador cliente executa uma consulta DNS para o

endereço IP de um site do SharePoint da empresa – nesse caso, uma empresa fictícia
chamada Contoso. O seguinte processo ocorre:
1. O servidor DNS retorna o VIP 107.105.47.60 para o cliente.
2. O cliente envia uma solicitação HTTP para o VIP.
3. A rede física tem vários caminhos disponíveis para acessar o VIP localizado em
qualquer MUX. Cada roteador ao longo do caminho usa o ECMP para escolher o
próximo segmento do caminho até que a solicitação chegue a um MUX.
4. O MUX que recebe as políticas configuradas de verificação de solicitação e vê que

há dois DIPs disponíveis, 10.10.10.5 e 10.10.20.5, em uma rede virtual para lidar
com a solicitação para o VIP 107.105.47.60
5. O MUX seleciona DIP 10.10.10.5 e encapsula os pacotes usando VXLAN para que
ele possa enviá-lo para o host que contém o DIP usando o endereço de rede física
do host.
6. O host recebe o pacote encapsulado e o inspeciona. Ele remove o encapsulamento

e reescreve o pacote para que o destino agora seja DIP 10.10.10.5 em vez do VIP e
envie o tráfego para a VM DIP.
7. A solicitação chega ao site da Contoso SharePoint no Server Farm 2. O servidor

gera uma resposta e a envia para o cliente, usando seu próprio endereço IP como
a origem.
8. O host intercepta o pacote de saída na opção virtual que lembra que o cliente,
agora o destino, fez a solicitação original para o VIP. O host reescreve a origem do
pacote para ser o VIP para que o cliente não veja o endereço DIP.
9. O host encaminha o pacote diretamente para o gateway padrão para a rede física
que usa sua tabela de roteamento padrão para encaminhar o pacote para o
cliente, que eventualmente recebe a resposta.
Balanceamento de carga do tráfego interno do

datacenter
Ao balancear a carga do tráfego de rede interno para o datacenter, como entre os
recursos de locatário que estão em execução em servidores diferentes e que são
membros da mesma rede virtual, a opção virtual hyper-v à qual as VMs estão
conectadas executa NAT.
Com o balanceamento de carga de tráfego interno, a primeira solicitação é enviada e

processada pelo MUX, que seleciona o DIP apropriado e roteia o tráfego para o DIP.
Desse ponto em diante, o fluxo de tráfego estabelecido ignora o MUX e vai diretamente
da VM para a VM.
Investigações de integridade
O software Load Balancer inclui investigações de integridade para validar a integridade
da infraestrutura de rede, incluindo o seguinte:
Investigação TCP para porta
Investigação HTTP para porta e URL
Ao contrário de um dispositivo de balanceador de carga tradicional em que a sonda se

origina no dispositivo e viaja pelo fio para o DIP, a investigação SLB se origina no host
onde o DIP está localizado e vai diretamente do agente host SLB para o DIP,
distribuindo ainda mais o trabalho entre os hosts.
Infraestrutura de Load Balancer de software

Antes de configurar o Software Load Balancer, primeiro você deve implantar o
Controlador de Rede e uma ou mais VMs MUX SLB.
Além disso, você deve configurar os hosts do Azure Stack HCI com o comutador virtual
Hyper-V habilitado para SDN e garantir que o Agente host SLB esteja em execução. Os
roteadores que atendem aos hosts devem dar suporte ao roteamento ECMP e ao BGP
(Border Gateway Protocol) e devem ser configurados para aceitar solicitações de
emparelhamento BGP dos MUXes SLB.
A figura a seguir fornece uma visão geral da infraestrutura SLB.
As seções a seguir fornecem mais informações sobre esses elementos da infraestrutura

de software Load Balancer.
Controlador de rede
O Controlador de Rede hospeda o Gerenciador de SLB e executa as seguintes ações
para Software Load Balancer:
Processa comandos SLB que vêm por meio da API northbound de Windows Admin
Center, System Center, Windows PowerShell ou outro aplicativo de gerenciamento
de rede.
Calcula a política de distribuição para hosts do Azure Stack HCI e MUXes SLB.
Fornece o status de integridade da infraestrutura de software Load Balancer.
Você pode usar Windows Admin Center ou Windows PowerShell para instalar e
configurar o Controlador de Rede e outras infraestruturas SLB.
SLB MUX
O SLB MUX processa o tráfego de rede de entrada e mapeia VIPs para DIPs e encaminha
o tráfego para o DIP correto. Cada MUX também usa BGP para publicar rotas VIP em
roteadores de borda. O BGP Keep Alive notifica os MUXes quando um MUX falha, o que
permite que MUXes ativos redistribuam a carga em caso de falha do MUX. Isso
essencialmente fornece balanceamento de carga para os balanceadores de carga.
Agente host SLB

Ao implantar o Software Load Balancer, você deve usar Windows Admin Center, System
Center, Windows PowerShell ou outro aplicativo de gerenciamento para implantar o
Agente host SLB em cada servidor host.
O Agente host SLB escuta atualizações de política SLB do Controlador de Rede. Além
disso, as regras de programas do agente host para SLB nos comutadores virtuais do
Hyper-V habilitados para SDN configurados no computador local.
Comutador virtual do Hyper-V habilitado para SDN

Para que um comutador virtual seja compatível com o SLB, a extensão VFP (Plataforma
de Filtragem Virtual) deve ser habilitada no comutador virtual. Isso é feito
automaticamente pelos scripts do PowerShell de implantação do SDN, pelo assistente
de implantação de Windows Admin Center e pela implantação do SCVMM (System
Center Virtual Machine Manager).
Para obter informações sobre como habilitar o VFP em comutadores virtuais, consulte
os comandos Windows PowerShell Get-VMSystemSwitchExtension e Enable-
VMSwitchExtension.
O comutador virtual Hyper-V habilitado para SDN executa as seguintes ações para SLB:
Processa o caminho de dados para SLB.
Recebe o tráfego de rede de entrada do MUX.
Ignora o MUX para tráfego de rede de saída, enviando-o para o roteador usando
DSR.
Roteador BGP
O roteador BGP executa as seguintes ações para Software Load Balancer:
Roteia o tráfego de entrada para o MUX usando o ECMP.
Para tráfego de rede de saída, usa a rota fornecida pelo host.
Escuta as atualizações de rota para VIPs do SLB MUX.
Remove MUXes SLB da rotação do SLB se Keep Alive falhar.
Recursos de Load Balancer de software

As seções a seguir descrevem alguns dos recursos e recursos do Software Load
Balancer.
Funcionalidade principal
O SLB fornece serviços de balanceamento de carga de Camada 4 para tráfego
TCP/UDP norte/sul e leste/oeste.
Você pode usar o SLB em uma rede baseada em Virtualização de Rede Hyper-V.
Você pode usar o SLB com uma rede baseada em VLAN para VMs DIP conectadas
a um comutador virtual Hyper-V habilitado para SDN.
Uma instância do SLB pode lidar com vários locatários.
O SLB e o DIP dão suporte a um caminho de retorno escalonável e de baixa

latência, conforme implementado pelo DSR.
O SLB funciona quando você também está usando o SET (Switch Embedded
Teaming) ou o SR-IOV (Virtualização de Entrada/Saída Raiz Única).
O SLB inclui o IPv6 (Protocolo de Internet versão 6) e o suporte à versão 4 (IPv4).
Para cenários de gateway site a site, o SLB fornece a funcionalidade NAT para
habilitar todas as conexões site a site a utilizar um único IP público.
Escala e desempenho
Pronto para escala de nuvem, incluindo a capacidade de expansão e expansão
para MUXes e agentes de host.
Um módulo ativo do Controlador de Rede do SLB Manager pode dar suporte a

oito instâncias de MUX.
Alta disponibilidade
Você pode implantar o SLB em mais de dois nós em uma configuração ativa/ativa.
OS MUXes podem ser adicionados e removidos do pool de MUX sem afetar o

serviço SLB. Isso mantém a disponibilidade do SLB quando MUXes individuais
estão sendo corrigidos.
As instâncias individuais do MUX têm um tempo de atividade de 99%.
Os dados de monitoramento de integridade estão disponíveis para entidades de

gerenciamento.
Próximas etapas
Gerenciar Balanceador de Carga de Software SDN

Módulo do Learn: Implementar o Firewall do Datacenter e o software Load
Balancer no Azure Stack HCI
Visão geral de rede de contêineres
Neste tópico, apresentamos uma visão geral da pilha de rede para contêineres Windows
e incluímos links para diretrizes adicionais sobre como criar, configurar e gerenciar redes
de contêiner.
Windows contêineres de servidor são um método leve de virtualização do sistema

operacional que separa aplicativos ou serviços de outros serviços executados no mesmo
host de contêiner. Windows contêineres funcionam da mesma forma que as máquinas
virtuais. Quando habilitado, cada contêiner tem uma exibição separada do sistema
operacional, dos processos, do sistema de arquivos, do registro e dos endereços IP, que
você pode conectar a redes virtuais.
Um Windows contêiner compartilha um kernel com o host do contêiner e todos os

contêineres em execução no host. Devido ao espaço de kernel compartilhado, esses
contêineres exigem a mesma versão e configuração de kernel. Os contêineres fornecem
isolamento do aplicativo por meio da tecnologia de isolamento de processo e
namespace.
） Importante
Windows contêineres não fornecem um limite de segurança agressivo e não devem

ser usados para isolar código não falso.
Com Windows contêineres, você pode implantar um host Hyper-V, em que você cria
uma ou mais máquinas virtuais nos hosts de VM. Dentro dos hosts de VM, os
contêineres são criados e o acesso à rede é feito por meio de um com switch virtual em
execução dentro da máquina virtual. Você pode usar imagens reutilizáveis armazenadas
em um repositório para implantar o sistema operacional e os serviços em contêineres.
Cada contêiner tem um adaptador de rede virtual que se conecta a um com switch
virtual, encaminhando o tráfego de entrada e saída. Você pode anexar pontos de
extremidade de contêiner a uma rede de host local (como NAT), à rede física ou à rede
virtual de sobreposição criada por meio da pilha SDN.
Para impor o isolamento entre contêineres no mesmo host, crie um compartimento de

rede para cada Windows Server e contêiner hyper-V. Contêineres do Windows Server
usam uma vNIC do host para se conectar ao comutador virtual. Os contêineres do
Hyper-V usam uma NIC de VM sintética (não exposta à VM do utilitário) para se
conectar ao comutador virtual.
Tópicos relacionados
Windows Rede de Contêineres: saiba como criar e gerenciar redes de contêiner
para implantações de não sobreposição/SDN.
Conexão de contêiner para uma rede virtual de locatário: saiba como criar e
gerenciar redes de contêiner para sobrepor redes virtuais com SDN.
Planejar uma infraestrutura de Rede
definida pelo software
Saiba mais sobre o planejamento de implantação para uma infraestrutura de SDN (Rede
Definida por Software), incluindo pré-requisitos de hardware e software. Este tópico
inclui requisitos de planejamento para configuração de rede física e lógica, roteamento,
gateways, hardware de rede e muito mais. Ele também inclui considerações sobre como
estender uma infraestrutura de SDN e usar uma implantação em fases.
７ Observação
Não há suporte para SDN em clusters estendidos (vários sites).
Pré-requisitos
Há vários pré-requisitos de hardware e software para uma infraestrutura de SDN,
incluindo:
Grupos de segurança e registro DNS dinâmico. Você deve preparar seu

datacenter para implantação do Controlador de Rede, que requer um conjunto de
VMs (máquinas virtuais). Antes de implantar o Controlador de Rede, você deve
configurar grupos de segurança e registro DNS dinâmico.
Para saber mais sobre a implantação do Controlador de Rede para seu datacenter,
consulte Requisitos para implantar o controlador de rede.
Rede física. Você precisa de acesso aos seus dispositivos de rede física para
configurar VLANs (redes de área local virtual), roteamento e BGP (Border Gateway
Protocol). Este tópico fornece instruções para configuração de comutador manual,
bem como opções para usar o emparelhamento BGP em comutadores/roteadores
de Camada 3 ou uma VM RRAS (Servidor de Roteamento e Acesso Remoto).
Hosts de computação física. Esses hosts executam o Hyper-V e são necessários

para hospedar uma infraestrutura de SDN e VMs de locatário. O hardware de rede
específico é necessário nesses hosts para melhor desempenho, conforme descrito
na próxima seção.
Requisitos de hardware do SDN

Esta seção fornece requisitos de hardware para comutadores físicos ao planejar um
ambiente SDN.
Comutadores e roteadores
Ao selecionar um comutador físico e um roteador para seu ambiente SDN, verifique se

ele dá suporte ao seguinte conjunto de recursos:
Configurações de MTU do switchport (obrigatório)

MTU definido como >= 1674 bytes (incluindo cabeçalho L2-Ethernet)
Protocolos L3 (obrigatórios)
Roteamento de vários caminhos de custo igual (ECMP)
ECMP baseado em BGP (IETF RFC 4271)
As implementações devem dar suporte às instruções MUST nos seguintes padrões IETF:
RFC 2545: extensões multiprotocol BGP-4 para roteamento de Inter-Domain

IPv6
RFC 4760: Extensões multiprotocol para BGP-4
RFC 4893: Suporte bgp para espaço numérico as de quatro octetos
RFC 4456: Reflexão de rota BGP: uma alternativa ao BGP interno de malha
completa (IBGP)
RFC 4724: Mecanismo de reinicialização normal para BGP
Os seguintes protocolos de marcação são necessários:
VLAN – Isolamento de vários tipos de tráfego

Tronco 802.1q
Os seguintes itens fornecem o controle Link:
QoS (Qualidade de Serviço) (PFC necessário somente se estiver usando o RoCE)

Seleção avançada de tráfego (802.1Qaz)
PFC (controle de fluxo baseado em prioridade) (802,1p/Q e 802,1Qbb)
Os seguintes itens fornecem disponibilidade e redundância:
Disponibilidade de comutador (obrigatório)

Um roteador altamente disponível é necessário para executar funções de gateway.
Você pode fornecer isso usando um comutador de vários chassis\roteador ou
tecnologias como o VRRP (Protocolo de Redundância de Roteador Virtual).
Configuração de rede física e lógica

Cada host de computação física requer conectividade de rede por meio de um ou mais
adaptadores de rede anexados a uma porta de comutador físico. Uma VLAN de
Camada 2 dá suporte a redes divididas em vários segmentos de rede lógica.
 Dica
Use a VLAN 0 para redes lógicas no modo de acesso ou não registradas.
） Importante
Windows Server 2016 Rede Definida pelo Software dá suporte ao endereçamento

IPv4 para a sobreposição e a sobreposição. Não há suporte para IPv6. O Windows
Server 2019 dá suporte ao endereçamento IPv4 e IPv6.
Logical networks
Esta seção aborda os requisitos de planejamento de infraestrutura de SDN para a rede
lógica de gerenciamento e a rede lógica do Provedor de Virtualização de Rede do
Hyper-V (HNV). Ele inclui detalhes sobre como provisionar redes lógicas adicionais para
usar gateways e o SLB (Software Load Balancer) e uma topologia de rede de exemplo.
Gerenciamento e provedor de HNV

Todos os hosts de computação física devem acessar a rede lógica de gerenciamento e a
rede lógica do Provedor HNV. Para fins de planejamento de endereço IP, cada host de
computação física deve ter pelo menos um endereço IP atribuído da rede lógica de
gerenciamento. O Controlador de Rede requer um endereço IP reservado dessa rede
para servir como o endereço IP REST (Transferência de Estado Representacional).
A rede provedor HNV serve como a rede física subjacente para o tráfego de locatário
leste/oeste (interno-interno), tráfego de locatário Norte/Sul (externo-interno) e para
trocar informações de emparelhamento BGP com a rede física.
Um servidor DHCP pode atribuir automaticamente endereços IP para a rede de
gerenciamento ou você pode atribuir manualmente endereços IP estáticos. A pilha SDN
atribui automaticamente endereços IP para a rede lógica do Provedor HNV para os
hosts Hyper-V individuais de um pool de endereços IP. O Controlador de Rede
especifica e gerencia o pool de endereços IP.
７ Observação
O Controlador de Rede atribui um endereço IP do provedor HNV a um host de

computação física somente depois que o Agente host do Controlador de Rede
recebe a política de rede para uma VM de locatário específica.
Se... Então...
As redes lógicas usam o host de computação física deve se conectar a uma porta de
VLANs, comutador com tronco que tenha acesso aos VLANs. É importante
observar que os adaptadores de rede física no host do computador não
devem ter nenhuma filtragem de VLAN ativada.
Você está usando você deve conectar todos os membros da equipe nic para esse host
Switched-Embedded específico ao mesmo domínio de transmissão de Camada 2.
agrupamento (SET) e
tem vários membros
da equipe nic (placa
de interface de rede),
como adaptadores de
rede,
O host de computação verifique se a rede lógica de gerenciamento tem endereços IP

física está executando suficientes para cada VM hospedada. Além disso, verifique se a rede
VMs de infraestrutura lógica do Provedor HNV tem endereços IP suficientes para alocar para
adicionais, como cada SLB/MUX e VM de infraestrutura de gateway. Embora a reserva de
Controlador de Rede, IP seja gerenciada pelo Controlador de Rede, a falha ao reservar um
SLB/Multiplexer (MUX) novo endereço IP devido à indisponibilidade pode resultar em
ou Gateway, endereços IP duplicados em sua rede.
Para obter informações sobre a HNV (Virtualização de Rede do Hyper-V) que você pode
usar para virtualizar redes em uma implantação do SDN da Microsoft, consulte
Virtualização de rede do Hyper-V.
Gateways e o SLB (Software Load Balancer)
Você precisa criar e provisionar redes lógicas adicionais para usar gateways e o SLB.
Certifique-se de obter os prefixos de IP corretos, IDs de VLAN e endereços IP de
gateway para essas redes.
Rede Descrição
lógica
Rede A rede lógica VIP (IP virtual público) deve usar prefixos de sub-rede IP roteáveis fora do
lógica ambiente de nuvem (normalmente roteáveis pela Internet). Esses são os endereços IP
VIP de front-end que os clientes externos usam para acessar recursos nas redes virtuais,
pública incluindo o VIP de front-end para o gateway site a site. Você não precisa atribuir uma
VLAN a essa rede.
Rede A rede lógica VIP privada não é necessária para ser roteável fora da nuvem. Isso ocorre
lógica porque apenas VIPs que podem ser acessados de clientes de nuvem internos o usam,
VIP como serviços privados. Você não precisa atribuir uma VLAN a essa rede.
privada
Rede A rede VIP GRE (Encapsulamento de Roteamento Genérico) é uma sub-rede que existe
lógica apenas para definir VIPs. Os VIPs são atribuídos a VMs de gateway em execução na
DO malha SDN para um tipo de conexão GRE site a site (S2S). Você não precisa pré-
GRE configurar essa rede em seus comutadores físicos ou roteador ou atribuir uma VLAN a
VIP ela.
Topologia de rede de exemplo

Altere os prefixos de sub-rede IP de exemplo e as IDs de VLAN para seu ambiente.
Nome da rede Sub-rede Mask ID de VLAN no Gateway Reserva (exemplos)

tronco
Gerenciamento 10.184.108.0 24 7 10.184.108.1 10.184.108.1 –

Roteador
10.184.108.4 –
Controlador de Rede
10.184.108.10 – Host
de computação 1
10.184.108.11 – Host
de computação 2
10.184.108.X – Host de
computação X
Provedor HNV 10.10.56.0 23 11 10.10.56.1 10.10.56.1 – Roteador
10.10.56.2 –
SLB/MUX1
10.10.56.5 – Gateway1
VIP público 41.40.40.0 27 NA 41.40.40.1 41.40.40.1 – Roteador
41.40.40.3 – IPSec S2S

VPN VIP
Nome da rede Sub-rede Mask ID de VLAN no Gateway Reserva (exemplos)
tronco
VIP privado 20.20.20.0 27 NA 20.20.20.1 20.20.20.1 – GW

padrão (roteador)
VIP do GRE 31.30.30.0 24 NA 31.30.30.1 31.30.30.1 – GW

padrão
Infraestrutura de roteamento
As informações de roteamento (como o próximo salto) para as sub-redes VIP são
anunciadas pelos gateways SLB/MUX e RAS (Servidor de Acesso Remoto) na rede física
usando o emparelhamento BGP interno. As redes lógicas VIP não têm uma VLAN
atribuída e não são pré-configuradas na opção Camada 2 (como o comutador Top-of-
Rack).
Você precisa criar um par BGP no roteador que sua infraestrutura de SDN usa para
receber rotas para as redes lógicas VIP anunciadas pelos Gateways SLB/MUXes e RAS. O
emparelhamento BGP só precisa ocorrer de uma maneira (do Gateway SLB/MUX ou RAS
para o par BGP externo). Acima da primeira camada de roteamento, você pode usar
rotas estáticas ou outro protocolo de roteamento dinâmico, como OSPF (Open Shortest
Path First). No entanto, como mencionado anteriormente, o prefixo de sub-rede IP para
as redes lógicas VIP precisa ser roteável da rede física para o par BGP externo.
O emparelhamento BGP normalmente é configurado em um comutador gerenciado ou

roteador como parte da infraestrutura de rede. O par BGP também pode ser
configurado em um Windows Server com a função RAS instalada em um modo
Somente Roteamento. O par de roteador BGP na infraestrutura de rede deve ser
configurado para usar seus próprios NÚMEROs de Sistema Autônomo (ASN) e permitir
o emparelhamento de um ASN atribuído aos componentes SDN (Gateways SLB/MUX e
RAS).
Você deve obter as seguintes informações do roteador físico ou do administrador de

rede no controle desse roteador:
ASN do roteador
Endereço IP do roteador
７ Observação
As ASNs de quatro bytes não têm suporte do SLB/MUX. Você deve alocar ASNs de
dois bytes para o SLB/MUX e o roteador ao qual ele se conecta. Você pode usar
ASNs de quatro bytes em outro lugar em seu ambiente.
Você ou o administrador de rede devem configurar o par do roteador BGP para aceitar
conexões do endereço ASN e IP ou do endereço de sub-rede da rede lógica do
Provedor de HNV que seu Gateway RAS e MUXes SLB estão usando.
Para obter mais informações, consulte BORDER Gateway Protocol (BGP).
Gateways padrão
Os computadores configurados para se conectar a várias redes, como hosts físicos,
SLB/MUX e VMs de gateway, devem ter apenas um gateway padrão configurado. Use os
seguintes gateways padrão para os hosts e as VMs de infraestrutura:
Para hosts Hyper-V, use a rede de gerenciamento como o gateway padrão.

Para VMs do Controlador de Rede, use a rede de gerenciamento como o gateway
padrão.
Para VMs SLB/MUX, use a rede de gerenciamento como o gateway padrão.
Para as VMs de gateway, use a rede do Provedor de HNV como o gateway padrão.
Isso deve ser definido na NIC de front-end das VMs do gateway.
Comutadores e roteadores
Para ajudar a configurar seu comutador físico ou roteador, um conjunto de arquivos de
configuração de exemplo para uma variedade de modelos de comutador e
fornecedores está disponível no repositório GitHub do SDN da Microsoft . Um arquivo
leiame e comandos de CLI (interface de linha de comando) testados para comutadores
específicos são fornecidos.
Para obter requisitos detalhados de comutador e roteador, consulte a seção Requisitos

de hardware do SDN acima.
Computação
Todos os hosts Hyper-V devem ter o sistema operacional apropriado instalado, estar
habilitado para Hyper-V e usar um comutador virtual Hyper-V externo com pelo menos
um adaptador físico conectado à rede lógica de gerenciamento. O host deve estar
acessível por meio de um endereço IP de gerenciamento atribuído à vNIC do host de
gerenciamento.
Você pode usar qualquer tipo de armazenamento compatível com o Hyper-V,
compartilhado ou local.
 Dica
É conveniente usar o mesmo nome para todos os seus comutadores virtuais, mas
não é obrigatório. Se você planeja usar scripts para implantar, consulte o
comentário associado vSwitchName à variável no arquivo config.psd1.
Requisitos de computação do host

Veja a seguir os requisitos mínimos de hardware e software para os quatro hosts físicos
usados na implantação de exemplo.
Host Requisitos de hardware Requisitos de software
Host Hyper-V CPU 4-core de 2,66 GHz

Sistema operacional: conforme
físico 32 GB de RAM
definido em
300 GB de espaço em disco

o "Aplica-se a" no início deste
Adaptador de rede física de 1 Gb/s (ou tópico.
mais rápido) Função Hyper-V instalada
Requisitos de função de VM de infraestrutura de SDN

Veja a seguir os requisitos para as funções de VM.
Função Requisitos de Requisitos de Requisitos de disco

vCPU memória
Controlador de Rede 4 vCPUs Mínimo de 4 GB

75 GB para unidade do sistema
(três nós) (8 GB operacional
recomendado)
SLB/MUX (três nós) 8 vCPUs 8 GB 75 GB para unidade do sistema

recomendados operacional
Gateway de RAS
8 vCPUs 8 GB 75 GB para unidade do sistema
(pool único de três nós recomendados operacional
gateways, dois ativos, um
passivo)
Função Requisitos de Requisitos de Requisitos de disco
vCPU memória
Roteador BGP do 2 vCPUs 2 GB 75 GB para unidade do sistema

Gateway ras
operacional
para emparelhamento
SLB/MUX
(como alternativa, use a

opção ToR
como Roteador BGP)
Se você usar o System Center – VMM (Virtual Machine Manager) para implantação,
recursos adicionais de VM de infraestrutura serão necessários para o VMM e outras
infraestruturas não SDN. Para saber mais, confira Requisitos do sistema para System
Center Virtual Machine Manager.
Estendendo sua infraestrutura

O dimensionamento e os requisitos de recursos para sua infraestrutura dependem das
VMs de carga de trabalho do locatário que você planeja hospedar. Os requisitos de
CPU, memória e disco para as VMs de infraestrutura (por exemplo: Controlador de Rede,
SLB, gateway e assim por diante) são definidos na tabela anterior. Você pode adicionar
mais VMs de infraestrutura para dimensionar conforme necessário. No entanto, todas as
VMs de locatário em execução nos hosts Hyper-V têm seus próprios requisitos de CPU,
memória e disco que você deve considerar.
Quando as VMs de carga de trabalho do locatário começam a consumir muitos recursos

nos hosts físicos do Hyper-V, você pode estender sua infraestrutura adicionando hosts
físicos adicionais. Você pode usar scripts Windows Admin Center, VMM ou PowerShell
para criar novos recursos de servidor por meio do Controlador de Rede. O método a ser
usado depende de como você implantou inicialmente a infraestrutura. Se você precisar
adicionar endereços IP adicionais para a rede do Provedor HNV, poderá criar novas sub-
redes lógicas (com pools de IP correspondentes) que os hosts podem usar.
Implantação em fases
Com base em seus requisitos, talvez seja necessário implantar um subconjunto da
infraestrutura do SDN. Por exemplo, se você quiser hospedar apenas cargas de trabalho
do cliente em seu datacenter e a comunicação externa não for necessária, você poderá
implantar o Controlador de Rede e ignorar a implantação de SLB/MUX e VMs de
gateway. A seguir, descreve os requisitos de infraestrutura de recursos de rede para uma
implantação em fases da infraestrutura do SDN.
Recurso Requisitos para Requisitos de rede
implantação
Gerenciamento de Rede Lógica

Controlador de rede Nenhum
NSGs (grupos de segurança de rede) (para
rede baseada em VLAN)
QoS (qualidade de serviço) (para redes

baseadas em VLAN)
Rede Virtual
Controlador de rede HNV PA VLAN, Sub-rede,
Roteamento Definido pelo Usuário
Roteador
ACLs (para rede virtual)
Sub-redes criptografadas
QoS (para redes virtuais)
Emparelhamento de rede virtual
NAT de entrada/saída
Controlador de rede
BGP na rede pa HNV
Balanceamento de carga SLB/MUX Sub-redes VIP pública e

privada
Conexões de gateway GRE Controlador de rede

BGP na rede pa HNV
SLB/MUX
Sub-redes VIP pública e
Gateway privada
Sub-rede VIP do GRE
Conexões de gateway IPSec Controlador de rede

BGP na rede pa HNV
SLB/MUX
Gateway privada
Conexões de gateway L3 Controlador de rede

BGP na rede pa HNV
SLB/MUX
Gateway privada
VLAN de locatário, sub-

rede, roteador
BGP na VLAN de locatário

opcional
Próximas etapas
Requisitos para implantar o controlador de rede

SDN no Azure Stack HCI
Módulo do Learn: Planejar e implantar a infraestrutura do SDN no Azure Stack HCI
Planejar a implantação do Controlador
de Rede
Planejar a implantação do Controlador de Rede por meio de Windows Admin Center

requer um conjunto de VMs (máquinas virtuais) que executam o sistema operacional
Azure Stack HCI ou Windows Server. O Controlador de Rede é uma função de servidor
altamente disponível e escalonável que requer um mínimo de três VMs para fornecer
alta disponibilidade em sua rede.
７ Observação
É recomendável implantar o Controlador de Rede em suas próprias VMs dedicadas.
Requisitos do controlador de rede

O seguinte é necessário para implantar o Controlador de Rede:
Um VHD (disco rígido virtual) para o sistema operacional do Azure Stack HCI criar
VMs do Controlador de Rede.
Um nome de domínio e credenciais para ingressar VMs do Controlador de Rede

em um domínio.
Pelo menos um comutador virtual configurado usando o assistente de Criação de

Cluster no Windows Admin Center.
Uma configuração de rede física que corresponde a uma das opções de topologia
nesta seção.
Windows Admin Center cria a configuração dentro do host Hyper-V. No entanto, a

rede de gerenciamento deve se conectar aos adaptadores físicos do host de
acordo com uma das três opções a seguir:
Opção 1: a rede de gerenciamento é fisicamente separada das redes de carga de

trabalho. Essa opção usa um único comutador virtual para computação e
armazenamento:


trabalho. Essa opção usa apenas um comutador virtual para computação:

trabalho. Essa opção usa dois comutadores virtuais, um para computação e outro
para armazenamento:
Você também pode agrupar os adaptadores físicos de gerenciamento para usar o

mesmo comutador de gerenciamento. Nesse caso, ainda é recomendável usar uma
das opções nesta seção.
Informações de rede de gerenciamento que o Controlador de Rede usa para se
comunicar com Windows Admin Center e os hosts Hyper-V.
Endereçamento baseado em DHCP ou estático baseado em rede para VMs do

O FQDN (representational state transfer) totalmente qualificado para Controlador

de Rede que os clientes de gerenciamento usam para se comunicar com o
７ Observação
Windows Admin Center atualmente não dá suporte à autenticação do

Controlador de Rede, seja para comunicação com clientes REST ou
comunicação entre VMs do Controlador de Rede. Você pode usar a
autenticação baseada em Kerberos se usar o PowerShell para implantá-la e
gerenciá-la.
Atualizações de DNS dinâmico

Você pode implantar nós de cluster do Controlador de Rede na mesma sub-rede ou em
sub-redes diferentes. Se você planeja implantar nós de cluster do Controlador de Rede
em sub-redes diferentes, deverá fornecer o nome DNS REST do Controlador de Rede
durante o processo de implantação.
Habilitar atualizações DNS dinâmicas para uma zona

Para habilitar atualizações dinâmicas de DNS para uma zona, execute as seguintes
etapas:
1. No servidor DNS, abra o console do Gerenciador de DNS .

2. No painel esquerdo, selecione Encaminhar Zonas de Pesquisa.
3. Clique com o botão direito do mouse na zona que hospeda o registro de nome do
Controlador de Rede e clique em Propriedades.
4. Na guia Geral , ao lado de Atualizações dinâmicas, selecione Somente seguro.
Restringir atualizações dinâmicas a nós do Controlador

de Rede
Para restringir as atualizações dinâmicas do registro de nome do Controlador de Rede
somente a nós do Controlador de Rede, execute as seguintes etapas:
1. No servidor DNS, abra o console do Gerenciador de DNS .

2. No painel esquerdo, selecione Encaminhar Zonas de Pesquisa.
3. Clique com o botão direito do mouse na zona que hospeda o registro de nome do
Controlador de Rede e clique em Propriedades.
4. Na guia Segurança, selecione Avançado.
5. Selecione Adicionar.
6. Escolha Selecionar uma entidade de segurança.
7. Na caixa de diálogo Selecionar Usuário, Computador, Conta de Serviço ou Grupo
, selecione Tipos de Objeto. Verifique Computadores e clique em OK.
8. Na caixa de diálogo Selecionar Usuário, Computador, Conta de Serviço ou Grupo
, insira o nome do computador de um dos nós do Controlador de Rede e clique
em OK.
9. Em Tipo, selecione Permitir.
10. Em Permissões, verifique Controle Total.
11. Clique em OK.
12. Repita as Etapas 5 a 11 para todos os computadores no cluster do Controlador de
Rede.
Próximas etapas
Agora você está pronto para implantar o Controlador de Rede em VMs.
Confira também
Criar um cluster do Azure Stack HCI
Implantar uma infraestrutura de SDN usando o SDN Express
Visão geral do controlador de rede
Alta disponibilidade do controlador de rede
Implantar uma infraestrutura de rede
definida por software
Implante a infraestrutura de SDN (Rede Definida por Software) da Microsoft.
Essas implantações incluem todas as tecnologias necessárias para uma infraestrutura

totalmente funcional, incluindo HNV (Virtualização de Rede Hyper-V), controladores de
rede, balanceadores de carga de software (SLB/MUX) e gateways.
Configurar a infraestrutura do SDN na malha

do VMM
Configurar uma infraestrutura SDN (rede definida pelo software) na malha do
VMM
Use esse método se quiser incorporar o VMM (System Center Virtual Machine
Manger) para gerenciar sua infraestrutura de SDN.
Implantar a infraestrutura do SDN usando

scripts
Use esse método se você não quiser usar o VMM para gerenciar sua infraestrutura
do SDN ou se tiver outro método de gerenciamento.
Implantar tecnologias individuais de SDN em

vez de uma infraestrutura inteira
Se você quiser implantar tecnologias individuais de SDN em vez de uma infraestrutura
inteira, confira: Implantar tecnologias de rede definidas por software usando Windows
PowerShell.
SDN (rede definida pelo software)
Tecnologias SDN
Planejar O SDN
Gerenciar SDN
Segurança para SDN
Solucionar problemas de SDN
Implantar uma infraestrutura de rede
definida pelo software usando scripts
Neste tópico, você implantará uma infraestrutura SDN (Microsoft Software Defined
Network) usando scripts. A infraestrutura inclui um controlador de rede (HA) altamente
disponível, um SLB (Load Balancer de Software de HA)/MUX, redes virtuais e ACLs (Listas
de Controle de Acesso) associadas. Além disso, outro script implanta uma carga de
trabalho de locatário para validar sua infraestrutura de SDN.
Se você quiser que suas cargas de trabalho de locatário se comuniquem fora de suas
redes virtuais, você pode configurar regras de NAT SLB, túneis de Gateway site a site ou
Encaminhamento de Camada 3 para rotear entre cargas de trabalho virtuais e físicas.
Você também pode implantar uma infraestrutura de SDN usando Virtual Machine
Manager (VMM). Para obter mais informações, consulte Configurar uma infraestrutura
de SDN (Rede Definida por Software) na malha do VMM.
Pré-implantação
） Importante
Antes de começar a implantação, você deve planejar e configurar os hosts e a

infraestrutura da rede física. Para obter mais informações, confira Planejar a
infraestrutura de rede definida por software.
Todos os hosts Hyper-V devem ter Windows Server 2019 ou 2016 instalados.
Etapas de implantação.
Comece configurando o comutador virtual Hyper-V (servidores físicos) do host Hyper-V
e a atribuição de endereço IP. Qualquer tipo de armazenamento compatível com Hyper-
V, compartilhado ou local pode ser usado.
Instalar a rede de host

1. Instale os drivers de rede mais recentes disponíveis para o hardware nic.
2. Instale a função Hyper-V em todos os hosts (Para obter mais informações, consulte
Introdução com o Hyper-V no Windows Server 2016.
PowerShell
Install-WindowsFeature -Name Hyper-V -ComputerName <computer_name> -

IncludeManagementTools -Restart
3. Crie o comutador virtual do Hyper-V.
Use o mesmo nome de comutador para todos os hosts, por exemplo, sdnSwitch.
Configure pelo menos um adaptador de rede ou, se estiver usando SET, configure
pelo menos dois adaptadores de rede. A distribuição máxima de entrada ocorre ao
usar duas NICs.
PowerShell
New-VMSwitch "<switch name>" -NetAdapterName "<NetAdapter1>" [, "

<NetAdapter2>" -EnableEmbeddedTeaming $True] -AllowManagementOS $True
 Dica
Você pode ignorar as etapas 4 e 5 se tiver NICs de Gerenciamento separadas.
4. Consulte o tópico de planejamento (Planejar uma Infraestrutura de Rede Definida

por Software) e trabalhe com o administrador de rede para obter a ID de VLAN da
VLAN de Gerenciamento. Anexe a vNIC de Gerenciamento do Comutador Virtual
recém-criado à VLAN de Gerenciamento. Essa etapa poderá ser omitida se o
ambiente não usar marcas VLAN.
PowerShell
Set-VMNetworkAdapterIsolation -ManagementOS -IsolationMode Vlan -

DefaultIsolationID <Management VLAN> -AllowUntaggedTraffic $True
5. Consulte o tópico de planejamento (Planejar uma infraestrutura de rede definida

pelo software) e trabalhe com o administrador de rede para usar atribuições de IP
estático ou DHCP para atribuir um endereço IP à vNIC de Gerenciamento do
vSwitch recém-criado. O exemplo a seguir mostra como criar um endereço IP
estático e atribuí-lo à vNIC de gerenciamento do vSwitch:
PowerShell
New-NetIPAddress -InterfaceAlias "vEthernet (<switch name>)" -IPAddress

<IP> -DefaultGateway <Gateway IP> -AddressFamily IPv4 -PrefixLength
<Length of Subnet Mask - for example: 24>
6. [Opcional] Implante uma máquina virtual para hospedar Active Directory Domain
Services (Instalar Active Directory Domain Services (Nível 100) e um Servidor DNS.
a. Conexão a máquina virtual do Servidor Active Directory/DNS para a VLAN de

Gerenciamento:
PowerShell
Set-VMNetworkAdapterIsolation -VMName "<VM Name>" -Access -VlanId

<Management VLAN> -AllowUntaggedTraffic $True
b. Instale Active Directory Domain Services e DNS.
７ Observação
O controlador de rede dá suporte a certificados Kerberos e X.509 para

autenticação. Este guia usa ambos os mecanismos de autenticação para fins
diferentes (embora apenas um seja necessário).
7. Junte todos os hosts Hyper-V ao domínio. Verifique a entrada do servidor DNS

para o adaptador de rede que tem um endereço IP atribuído aos pontos de rede
de gerenciamento para um servidor DNS que pode resolver o nome de domínio.
PowerShell
Set-DnsClientServerAddress -InterfaceAlias "vEthernet (<switch name>)"

-ServerAddresses <DNS Server IP>
a. Clique com o botão direito do mouse em Iniciar, clique em Sistema e clique em

Alterar Configurações.
b. Clique em Alterar.
c. Clique em Domínio e especifique o
nome de domínio. """" d. Clique em OK. e. Digite o nome de usuário e as
credenciais de senha quando solicitado.
f. Reinicie o servidor.
Validação
Use as etapas a seguir para validar se a rede de host está configurada corretamente.
1. Verifique se o Comutador de VM foi criado com êxito:
PowerShell
Get-VMSwitch "<switch name>"
2. Verifique se o vNIC de gerenciamento no Comutador de VM está conectado à

VLAN de Gerenciamento:
７ Observação
Relevante somente se o tráfego de Gerenciamento e Locatário compartilhar a

mesma NIC.
PowerShell
Get-VMNetworkAdapterIsolation -ManagementOS
3. Valide todos os hosts Hyper-V e recursos de gerenciamento externo, por exemplo,

servidores DNS.
Verifique se eles estão acessíveis por meio do ping usando o endereço IP de

gerenciamento e/ou o FQDN (nome de domínio totalmente qualificado).
ping <Hyper-V Host IP>
ping <Hyper-V Host FQDN>
4. Execute o comando a seguir no host de implantação e especifique o FQDN de

cada host Hyper-V para garantir que as credenciais Kerberos usadas forneçam
acesso a todos os servidores.
winrm id -r:<Hyper-V Host FQDN>
Executar scripts do SDN Express

1. Acesse o Repositório de GitHub do Microsoft SDN para obter os arquivos de
instalação.
2. Baixe os arquivos de instalação do repositório para o computador de implantação
designado. Clique em Clonar ou baixar e clique em Baixar ZIP.
７ Observação
O computador de implantação designado deve estar executando Windows

Server 2016 ou posterior.
3. Expanda o arquivo zip e copie a pasta SDNExpress para a pasta do computador de

C:\ implantação.
4. Compartilhe a C:\SDNExpress pasta como "SDNExpress" com permissão para

Todoslerem/gravarem.
5. Navegue até a pasta C:\SDNExpress .
Você verá as seguintes pastas:
Nome da Descrição
Pasta
AgentConf Contém novas cópias de esquemas OVSDB usados pelo Agente de Host do
SDN em cada host Windows Server 2016 Hyper-V para programar a política
de rede.
Certificados Local compartilhado temporário para o arquivo de certificado NC.
Imagens Vazio, coloque sua imagem vhdx Windows Server 2016 aqui
Ferramentas Utilitários para solução de problemas e depuração. Copiado para os hosts e

máquinas virtuais. Recomendamos que você coloque o Monitor de Rede ou
o Wireshark aqui para que ele esteja disponível, se necessário.
Nome da Descrição
Pasta
Scripts Scripts de implantação.

- SDNExpress.ps1
Implanta e configura a malha, incluindo as máquinas virtuais do controlador

de rede, as máquinas virtuais SLB Mux, os pools de gateway e as máquinas
virtuais do gateway HNV correspondentes aos pools.
- FabricConfig.psd1
Um modelo de arquivo de configuração para o script SDNExpress. Você

personalizará isso para seu ambiente.
- SDNExpressTenant.ps1
Implanta uma carga de trabalho de locatário de exemplo em uma rede

virtual com um VIP com balanceamento de carga.
Também provisiona uma ou mais conexões de rede (IPSec S2S VPN, GRE, L3)
nos gateways de borda do provedor de serviços conectados à carga de
trabalho de locatário criada anteriormente. Os gateways IPSec e GRE estão
disponíveis para conectividade pelo endereço IP VIP correspondente e o
gateway de encaminhamento L3 pelo pool de endereços correspondente.
Esse script também pode ser usado para excluir a configuração

correspondente com uma opção Desfazer.
- TenantConfig.psd1
Um arquivo de configuração de modelo para a carga de trabalho de

locatário e a configuração do gateway S2S.
- SDNExpressUndo.ps1
Limpa o ambiente da malha e o redefine para um estado inicial.
- SDNExpressEnterpriseExample.ps1
Provisiona um ou mais ambientes de site corporativo com um Gateway de

Acesso Remoto e (opcionalmente) uma máquina virtual corporativa
correspondente por site. Os gateways corporativos IPSec ou GRE se
conectam ao endereço IP VIP correspondente do gateway do provedor de
serviços para estabelecer os túneis S2S. O Gateway de Encaminhamento L3
conecta-se pelo endereço IP par correspondente.
Esse script também pode ser usado para excluir a configuração

correspondente com uma opção Desfazer.
- EnterpriseConfig.psd1
Um arquivo de configuração de modelo para o Enterprise gateway site a site

e configuração de VM cliente.
TenantApps Arquivos usados para implantar cargas de trabalho de locatário de exemplo.
6. Verifique se o arquivo VHDX Windows Server 2016 está na pasta Imagens.
7. Personalize o arquivo SDNExpress\scripts\FabricConfig.psd1 alterando as <<

marcas Replace >> por valores específicos para ajustar sua infraestrutura de
laboratório, incluindo nomes de host, nomes de domínio, nomes de usuário e
senhas e informações de rede para as redes listadas no tópico Rede de
Planejamento.
8. Crie um registro host A no DNS para o FQDN (NetworkControllerRestName) e
NetworkControllerRestIP.
9. Execute o script como um usuário com credenciais de administrador de domínio:
SDNExpress\scripts\SDNExpress.ps1 -ConfigurationDataFile
FabricConfig.psd1 -Verbose
10. Para desfazer todas as operações, execute o seguinte comando:
SDNExpress\scripts\SDNExpressUndo.ps1 -ConfigurationDataFile
FabricConfig.psd1 -Verbose
Validação
Supondo que o script SDN Express tenha sido executado até a conclusão sem relatar
erros, você pode executar a etapa a seguir para garantir que os recursos de malha
tenham sido implantados corretamente e estejam disponíveis para implantação de
locatário.
Use as Ferramentas de Diagnóstico para garantir que não haja erros em nenhum
recurso de malha no controlador de rede.
Debug-NetworkControllerConfigurationState -NetworkController <FQDN of

Network Controller Rest Name>
Implantar uma carga de trabalho de locatário de exemplo

com o balanceador de carga de software
Agora que os recursos de malha foram implantados, você pode validar a implantação
do SDN de ponta a ponta implantando uma carga de trabalho de locatário de exemplo.
Essa carga de trabalho de locatário consiste em duas sub-redes virtuais (camada da Web
e camada de banco de dados) protegidas por meio de regras de ACL (lista de Controle
de Acesso) usando o firewall distribuído do SDN. A sub-rede virtual da camada da Web
é acessível por meio do SLB/MUX usando um endereço IP virtual (VIP). O script implanta
automaticamente duas máquinas virtuais de camada da Web e uma máquina virtual da
camada de banco de dados e as conecta às sub-redes virtuais.
1. Personalize o arquivo SDNExpress\scripts\TenantConfig.psd1 alterando as <<

marcas Replace >> por valores específicos (por exemplo: nome da imagem VHD,
nome REST do controlador de rede, nome vSwitch etc. conforme definido
anteriormente no arquivo FabricConfig.psd1)
2. Execute o script. Por exemplo:
SDNExpress\scripts\SDNExpressTenant.ps1 -ConfigurationDataFile
TenantConfig.psd1 -Verbose
3. Para desfazer a configuração, execute o mesmo script com o parâmetro desfazer .

Por exemplo:
SDNExpress\scripts\SDNExpressTenant.ps1 -Undo -ConfigurationDataFile

TenantConfig.psd1 -Verbose
Validação
Para validar se a implantação do locatário foi bem-sucedida, faça o seguinte:
1. Faça logon na máquina virtual da camada de banco de dados e tente executar

ping no endereço IP de uma das máquinas virtuais da camada da Web (verifique se
Windows Firewall está desativado em máquinas virtuais da camada da Web).
2. Verifique se há erros nos recursos de locatário do controlador de rede. Execute o

seguinte de qualquer host Hyper-V com conectividade de Camada 3 com o
controlador de rede:
Debug-NetworkControllerConfigurationState -NetworkController <FQDN of

Network Controller REST Name>
3. Para verificar se o balanceador de carga está sendo executado corretamente,

execute o seguinte em qualquer host Hyper-V:
wget <VIP IP address>/unique.htm -disablekeepalive -usebasicparsing
onde <VIP IP address> está o endereço IP VIP da camada da Web que você
configurou no arquivo TenantConfig.psd1.
 Dica
Pesquise a VIPIP variável em TenantConfig.psd1.
Execute isso várias vezes para ver a opção de balanceador de carga entre os DIPs
disponíveis. Você também pode observar esse comportamento usando um
navegador da Web. Navegue até <VIP IP address>/unique.htm . Feche o navegador
e abra uma nova instância e navegue novamente. Você verá a página azul e a
página verde como alternativa, exceto quando o navegador armazenar a página
em cache antes do cache atingir o tempo limite.
Implantar tecnologias de rede definidas
pelo software usando o Windows
PowerShell
Você pode usar os tópicos desta seção para implantar tecnologias de SDN individuais
usando o Windows PowerShell.
Esta seção contém o tópico a seguir:
Implantar controlador de rede usando o Windows PowerShell

Implantar o controlador de rede usando
o Windows PowerShell
Este tópico fornece instruções sobre como usar Windows PowerShell para implantar o
Controlador de Rede em uma ou mais VMs (máquinas virtuais) que estão executando
Windows Server 2019 ou 2016.
） Importante

por Software) adicionando os hosts ao Controlador de Rede usando o comando
Windows PowerShell New-NetworkControllerServer. Ao fazer isso, você está
habilitando o software SDN Load Balancer funcionar. Para obter mais informações,
consulte New-NetworkControllerServer.
Instalar a função de servidor controlador de rede
Configurar o cluster do Controlador de Rede
Configurar o aplicativo Controlador de Rede
Validação de implantação do Controlador de Rede
Comandos de Windows PowerShell adicionais para o Controlador de Rede
Script de configuração de controlador de rede de exemplo
Etapas pós-implantação para implantações não Kerberos

Instalar a função de servidor controlador de
rede
Você pode usar esse procedimento para instalar a função de servidor controlador de
rede em uma VM (máquina virtual).
） Importante

por Software) adicionando os hosts ao Controlador de Rede. Ao fazer isso, você
está habilitando o software SDN Load Balancer funcionar.

este procedimento.
７ Observação
Se você quiser usar Gerenciador do Servidor em vez de Windows PowerShell para

instalar o Controlador de Rede, consulte Instalar a função de servidor controlador
de rede usando Gerenciador do Servidor
Para instalar o Controlador de Rede usando Windows PowerShell, digite os comandos a

seguir em um prompt de Windows PowerShell e pressione ENTER.
Install-WindowsFeature -Name NetworkController -IncludeManagementTools
A instalação do Controlador de Rede requer que você reinicie o computador. Para fazer
isso, digite o comando a seguir e pressione ENTER.
Restart-Computer
Configurar o cluster do Controlador de Rede

O cluster controlador de rede fornece alta disponibilidade e escalabilidade para o
aplicativo Controlador de Rede, que você pode configurar após a criação do cluster e
que está hospedado na parte superior do cluster.
７ Observação
Você pode executar os procedimentos nas seções a seguir diretamente na VM em

que instalou o Controlador de Rede ou pode usar as Ferramentas de Administração
de Servidor Remoto para Windows Server 2016 para executar os procedimentos de
um computador remoto que está executando Windows Server 2016 ou Windows
10. Além disso, a associação aos Administradores, ou equivalente, é o mínimo
necessário para executar esse procedimento. Se o computador ou a VM no qual
você instalou o Controlador de Rede estiver ingressado em um domínio, sua conta
de usuário deverá ser membro dos Usuários de Domínio.
Você pode criar um cluster do Controlador de Rede criando um objeto de nó e

configurando o cluster.
Criar um objeto de nó
Você precisa criar um objeto de nó para cada VM que seja membro do cluster
Para criar um objeto de nó, digite o comando a seguir no prompt de comando Windows
PowerShell e pressione ENTER. Adicione valores para cada parâmetro apropriado para
sua implantação.
New-NetworkControllerNodeObject -Name <string> -Server <String> -FaultDomain

<string>-RestInterface <string> [-NodeCertificate <X509Certificate2>]
A tabela a seguir fornece descrições para cada parâmetro do comando New-

NetworkControllerNodeObject .
Nome O parâmetro Name especifica o nome amigável do servidor que você deseja
adicionar ao cluster
Servidor O parâmetro Server especifica o nome do host, o FQDN (Nome de Domínio

Totalmente Qualificado) ou o endereço IP do servidor que você deseja
adicionar ao cluster. Para computadores ingressados no domínio, o FQDN é
necessário.
FaultDomain O parâmetro FaultDomain especifica o domínio de falha do servidor que você

está adicionando ao cluster. Esse parâmetro define os servidores que podem
apresentar falha ao mesmo tempo que o servidor que você está adicionando ao
cluster. Essa falha pode ser devido a dependências físicas compartilhadas, como
fontes de energia e rede. Os domínios de falha normalmente representam
hierarquias relacionadas a essas dependências compartilhadas, com mais
servidores propensos a falhar juntos a partir de um ponto mais alto na árvore
de domínio de falha. Durante o runtime, o Controlador de Rede considera os
domínios de falha no cluster e tenta distribuir os serviços do Controlador de
Rede para que eles estejam em domínios de falha separados. Esse processo
ajuda a garantir que, em caso de falha de qualquer domínio de falha, a
disponibilidade do serviço e seu estado não sejam comprometidos. Os
domínios de falha são especificados em um formato hierárquico. Por exemplo:
"Fd:/DC1/Rack1/Host1", onde DC1 é o nome do datacenter, Rack1 é o nome do
rack e Host1 é o nome do host em que o nó é colocado.
RestInterface O parâmetro RestInterface especifica o nome da interface no nó em que a

comunicação REST (Transferência de Estado Representacional) é encerrada. Essa
interface do Controlador de Rede recebe solicitações de API northbound da
camada de gerenciamento da rede.
NodeCertificate O parâmetro NodeCertificate especifica o certificado que o Controlador de

Rede usa para autenticação de computador. O certificado será necessário se
você usar a autenticação baseada em certificado para comunicação dentro do
cluster; o certificado também é usado para criptografia de tráfego entre os
serviços do Controlador de Rede. O nome da entidade do certificado deve ser o
mesmo que o nome DNS do nó.
Configurar o cluster
Para configurar o cluster, digite o comando a seguir no prompt de comando Windows
PowerShell e pressione ENTER. Adicione valores para cada parâmetro apropriado para
sua implantação.
Install-NetworkControllerCluster -Node <NetworkControllerNode[]> -

ClusterAuthentication <ClusterAuthentication> [-ManagementSecurityGroup
<string>][-DiagnosticLogLocation <string>][-LogLocationCredential
<PSCredential>] [-CredentialEncryptionCertificate <X509Certificate2>][-
Credential <PSCredential>][-CertificateThumbprint <String>] [-UseSSL][-
ComputerName <string>][-LogSizeLimitInMBs<UInt32>] [-
LogTimeLimitInDays<UInt32>]
A tabela a seguir fornece descrições para cada parâmetro do comando Install-

NetworkControllerCluster .
ClusterAuthentication O parâmetro ClusterAuthentication especifica o tipo de

autenticação usado para proteger a comunicação entre nós e
também é usado para criptografia de tráfego entre os serviços
do Controlador de Rede. Os valores com suporte são Kerberos,
X509 e None. A autenticação Kerberos usa contas de domínio e
só pode ser usada se os nós do Controlador de Rede estiverem
ingressados no domínio. Se você especificar a autenticação
baseada em X509, deverá fornecer um certificado no objeto
NetworkControllerNode. Além disso, você deve provisionar
manualmente o certificado antes de executar este comando.
ManagementSecurityGroup O parâmetro ManagementSecurityGroup especifica o nome do

grupo de segurança que contém usuários que têm permissão
para executar os cmdlets de gerenciamento de um computador
remoto. Isso só será aplicável se ClusterAuthentication for
Kerberos. Você deve especificar um grupo de segurança de
domínio e não um grupo de segurança no computador local.
Nó O parâmetro Node especifica a lista de nós do Controlador de

Rede que você criou usando o comando New-
DiagnosticLogLocation O parâmetro DiagnosticLogLocation especifica o local de

compartilhamento em que os logs de diagnóstico são
carregados periodicamente. Se você não especificar um valor
para esse parâmetro, os logs serão armazenados localmente em
cada nó. Os logs são armazenados localmente na pasta
%systemdrive%\Windows\tracing\SDNDiagnostics. Os logs de
cluster são armazenados localmente na pasta
%systemdrive%\ProgramData\Microsoft\Service
Fabric\log\Traces.
LogLocationCredential O parâmetro LogLocationCredential especifica as credenciais

necessárias para acessar o local de compartilhamento onde os
logs são armazenados.
CredentialEncryptionCertificate O parâmetro CredentialEncryptionCertificate especifica o

certificado que o Controlador de Rede usa para criptografar as
credenciais usadas para acessar binários do Controlador de
Rede e o LogLocationCredential, se especificado. O certificado
deve ser provisionado em todos os nós do Controlador de Rede
antes de executar esse comando e o mesmo certificado deve ser
registrado em todos os nós do cluster. O uso desse parâmetro
para proteger binários e logs do Controlador de Rede é
recomendado em ambientes de produção. Sem esse parâmetro,
as credenciais são armazenadas em texto claro e podem ser mal
utilizadas por qualquer usuário não autorizado.
Credencial Esse parâmetro será necessário somente se você estiver

executando esse comando em um computador remoto. O
parâmetro credential especifica uma conta de usuário que tem
permissão para executar esse comando no computador de
destino.
CertificateThumbprint Esse parâmetro será necessário somente se você estiver

parâmetro CertificateThumbprint especifica o certificado de
chave pública digital (X509) de uma conta de usuário que tem
permissão para executar esse comando no computador de
destino.
UseSSL Esse parâmetro será necessário somente se você estiver

parâmetro UseSSL especifica o protocolo SSL (Secure Sockets
Layer) usado para estabelecer uma conexão com o computador
remoto. Por padrão, SSL não é usado.
ComputerName O parâmetro ComputerName especifica o nó controlador de

rede no qual esse comando é executado. Se você não
especificar um valor para esse parâmetro, o computador local
será usado por padrão.
LogSizeLimitInMBs Esse parâmetro especifica o tamanho máximo do log, em MB,

que o Controlador de Rede pode armazenar. Os logs são
armazenados de forma circular. Se DiagnosticLogLocation for
fornecido, o valor padrão desse parâmetro será 40 GB. Se
DiagnosticLogLocation não for fornecido, os logs serão
armazenados nos nós do Controlador de Rede e o valor padrão
desse parâmetro será de 15 GB.
LogTimeLimitInDays Esse parâmetro especifica o limite de duração, em dias, para o

qual os logs são armazenados. Os logs são armazenados de
forma circular. O valor padrão desse parâmetro é de 3 dias.
Configurar o aplicativo Controlador de Rede
Para configurar o aplicativo controlador de rede, digite o comando a seguir no prompt
de comando Windows PowerShell e pressione ENTER. Adicione valores para cada
parâmetro apropriado para sua implantação.
Install-NetworkController -Node <NetworkControllerNode[]> -

ClientAuthentication <ClientAuthentication> [-ClientCertificateThumbprint
<string[]>] [-ClientSecurityGroup <string>] -ServerCertificate
<X509Certificate2> [-RESTIPAddress <String>] [-RESTName <String>] [-
Credential <PSCredential>][-CertificateThumbprint <String> ] [-UseSSL]
A tabela a seguir fornece descrições para cada parâmetro do comando Install-

NetworkController .
Clientauthentication O parâmetro ClientAuthentication especifica o tipo de

autenticação usado para proteger a comunicação entre REST e
Controlador de Rede. Os valores com suporte são Kerberos, X509 e
None. A autenticação Kerberos usa contas de domínio e só pode
ser usada se os nós do Controlador de Rede estiverem ingressados
no domínio. Se você especificar a autenticação baseada em X509,
deverá fornecer um certificado no objeto NetworkControllerNode.
Além disso, você deve provisionar manualmente o certificado antes
de executar este comando.
Nó O parâmetro Node especifica a lista de nós do Controlador de Rede

que você criou usando o comando New-
ClientCertificateThumbprint Esse parâmetro é necessário somente quando você está usando a

autenticação baseada em certificado para clientes do Controlador
de Rede. O parâmetro ClientCertificateThumbprint especifica a
impressão digital do certificado registrado para clientes na camada
Norte.
ServerCertificate O parâmetro ServerCertificate especifica o certificado que o

Controlador de Rede usa para provar sua identidade aos clientes. O
certificado do servidor deve incluir a finalidade de Autenticação de
Servidor em extensões avançadas de uso de chave e deve ser
emitido para o Controlador de Rede por uma AC confiável pelos
clientes.
RESTIPAddress Você não precisa especificar um valor para RESTIPAddress com

uma única implantação de nó do Controlador de Rede. Para
implantações de vários nós, o parâmetro RESTIPAddress especifica
o endereço IP do ponto de extremidade REST na notação CIDR. Por
exemplo, 192.168.1.10/24. O valor nome da entidade de
ServerCertificate deve ser resolvido para o valor do parâmetro
RESTIPAddress . Esse parâmetro deve ser especificado para todas
as implantações do Controlador de Rede de vários nós quando
todos os nós estiverem na mesma sub-rede. Se os nós estiverem
em sub-redes diferentes, você deverá usar o parâmetro RestName
em vez de usar RESTIPAddress.
RestName Você não precisa especificar um valor para RestName com uma
implantação de nó único do Controlador de Rede. A única vez que
você deve especificar um valor para RestName é quando
implantações de vários nós têm nós que estão em sub-redes
diferentes. Para implantações de vários nós, o parâmetro RestName
especifica o FQDN para o cluster do Controlador de Rede.
ClientSecurityGroup O parâmetro ClientSecurityGroup especifica o nome do grupo de

segurança do Active Directory cujos membros são clientes do
Controlador de Rede. Esse parâmetro será necessário somente se
você usar a autenticação Kerberos para ClientAuthentication. O
grupo de segurança deve conter as contas das quais as APIs REST
são acessadas e você deve criar o grupo de segurança e adicionar
membros antes de executar esse comando.
Credencial Esse parâmetro será necessário somente se você estiver executando

esse comando em um computador remoto. O parâmetro credential
especifica uma conta de usuário que tem permissão para executar
esse comando no computador de destino.
CertificateThumbprint Esse parâmetro será necessário somente se você estiver executando

esse comando em um computador remoto. O parâmetro
CertificateThumbprint especifica o certificado de chave pública
digital (X509) de uma conta de usuário que tem permissão para
executar esse comando no computador de destino.
UseSSL Esse parâmetro será necessário somente se você estiver executando

esse comando em um computador remoto. O parâmetro UseSSL
especifica o protocolo SSL (Secure Sockets Layer) usado para
estabelecer uma conexão com o computador remoto. Por padrão,
SSL não é usado.
Depois de concluir a configuração do aplicativo Controlador de Rede, sua implantação

do Controlador de Rede será concluída.
Validação de implantação do Controlador de
Rede
Para validar a implantação do Controlador de Rede, você pode adicionar uma credencial
ao Controlador de Rede e recuperar a credencial.
Se você estiver usando Kerberos como o mecanismo ClientAuthentication, a associação

no ClientSecurityGroup que você criou será o mínimo necessário para executar esse
procedimento.
Procedimento:
1. Em um computador cliente, se você estiver usando Kerberos como o mecanismo

ClientAuthentication, faça logon com uma conta de usuário que seja membro do
ClientSecurityGroup.
2. Abra Windows PowerShell, digite os comandos a seguir para adicionar uma

credencial ao Controlador de Rede e pressione ENTER. Adicione valores para cada
parâmetro apropriado para sua implantação.
$cred=New-Object
Microsoft.Windows.Networkcontroller.credentialproperties
$cred.type="usernamepassword"
$cred.username="admin"
$cred.value="abcd"
New-NetworkControllerCredential -ConnectionUri
https://networkcontroller -Properties $cred -ResourceId cred1
3. Para recuperar a credencial adicionada ao Controlador de Rede, digite o comando

a seguir e pressione ENTER. Adicione valores para cada parâmetro apropriado para
sua implantação.
Get-NetworkControllerCredential -ConnectionUri
https://networkcontroller -ResourceId cred1
4. Examine a saída do comando, que deve ser semelhante à saída de exemplo a

seguir.
Tags :
ResourceRef : /credentials/cred1
CreatedTime : 1/1/0001 12:00:00 AM
InstanceId : e16ffe62-a701-4d31-915e-7234d4bc5a18
Etag : W/"1ec59631-607f-4d3e-ac78-94b0822f3a9d"
ResourceMetadata :
ResourceId : cred1
Properties :
Microsoft.Windows.NetworkController.CredentialProperties
７ Observação
Ao executar o comando Get-NetworkControllerCredential , você pode

atribuir a saída do comando a uma variável usando o operador de ponto para
listar as propriedades das credenciais. Por exemplo, $cred. Propriedades.
Comandos de Windows PowerShell adicionais

para o Controlador de Rede
Depois de implantar o Controlador de Rede, você pode usar Windows PowerShell
comandos para gerenciar e modificar sua implantação. A seguir estão algumas das
alterações que você pode fazer em sua implantação.
Modificar as configurações de nó, cluster e aplicativo do Controlador de Rede
Remover o cluster e o aplicativo do Controlador de Rede
Gerenciar nós de cluster do Controlador de Rede, incluindo adicionar, remover,

habilitar e desabilitar nós.
A tabela a seguir fornece a sintaxe para Windows PowerShell comandos que você pode
usar para realizar essas tarefas.
Tarefa Comando Syntax
Modificar as Set- Set-NetworkControllerCluster [-

configurações NetworkControllerCluster ManagementSecurityGroup <string>][-Credential
do cluster do <PSCredential>] [-computerName <string>][-
Controlador CertificateThumbprint <String> ] [-UseSSL]
de Rede
Modificar as Set-NetworkController Set-NetworkController [-ClientAuthentication

configurações <ClientAuthentication>] [-Credential
de aplicativo <PSCredential>] [-ClientCertificateThumbprint
do <string[]>] [-ClientSecurityGroup <string>] [-
Controlador ServerCertificate <X509Certificate2>] [-
de Rede RestIPAddress <String>] [-ComputerName
<String>][-CertificateThumbprint <String> ] [-
UseSSL]
Modificar as Set-NetworkControllerNode Set-NetworkControllerNode -Name <string> > [-

configurações RestInterface <string>] [-NodeCertificate
do nó do <X509Certificate2>] [-Credential
Controlador <PSCredential>] [-ComputerName <string>][-
de Rede CertificateThumbprint <String> ] [-UseSSL]
Modificar as Set- Set-NetworkControllerDiagnostic [-LogScope

configurações NetworkControllerDiagnostic <string>] [-DiagnosticLogLocation <string>] [-
de LogLocationCredential <PSCredential>] [-
diagnóstico UseLocalLogLocation] >] [-LogLevel <loglevel>]
do [-LogSizeLimitInMBs <uint32>] [-
Controlador LogTimeLimitInDays <uint32>] [-Credential
de Rede <PSCredential>] [-ComputerName <string>][-
CertificateThumbprint <String> ] [-UseSSL]
Remover o Uninstall-NetworkController Uninstall-NetworkController [-Credential

aplicativo <PSCredential>][-ComputerName <string>] [-
Controlador CertificateThumbprint <String> ] [-UseSSL]
de Rede
Remover o Uninstall- Uninstall-NetworkControllerCluster [-

cluster do NetworkControllerCluster Credential <PSCredential>][-ComputerName
Controlador <string>][-CertificateThumbprint <String> ] [-
de Rede UseSSL]
Adicionar um Add-NetworkControllerNode Add-NetworkControllerNode -FaultDomain

nó ao cluster <String> -Name <String> -RestInterface
do <String> -Server <String> [-
Controlador CertificateThumbprint <String> ] [-
de Rede ComputerName <String> ] [-Credential
<PSCredential> ] [-Force] [-NodeCertificate
<X509Certificate2> ] [-PassThru] [-UseSsl]
Desabilitar Disable- Disable-NetworkControllerNode -Name <String>

um nó de NetworkControllerNode [-CertificateThumbprint <String> ] [-
cluster do ComputerName <String> ] [-Credential
Controlador <PSCredential> ] [-PassThru] [-UseSsl]
de Rede
Habilitar um Enable- Enable-NetworkControllerNode -Name <String> [-

nó de cluster NetworkControllerNode CertificateThumbprint <String> ] [-
do ComputerName <String> ] [-Credential
Controlador <PSCredential> ] [-PassThru] [-UseSsl]
de Rede
Remover um Remove- Remove-NetworkControllerNode [-

nó do NetworkControllerNode CertificateThumbprint <String> ] [-
Controlador ComputerName <String> ] [-Credential
de Rede de <PSCredential> ] [-Force] [-Name <String> ] [-
um cluster PassThru] [-UseSsl]
７ Observação
Windows PowerShell comandos para Controlador de Rede estão na Biblioteca

TechNet em Cmdlets do Controlador de Rede.
Exemplo de script de configuração do

Controlador de Rede
O script de configuração de exemplo a seguir mostra como criar um cluster do
Controlador de Rede de vários nós e instalar o aplicativo controlador de rede. Além
disso, a variável $cert seleciona um certificado no repositório de certificados de
computador local que corresponde à cadeia de caracteres de nome da entidade
"networkController.contoso.com".
$a = New-NetworkControllerNodeObject -Name Node1 -Server NCNode1.contoso.com

-FaultDomain fd:/rack1/host1 -RestInterface Internal
$b = New-NetworkControllerNodeObject -Name Node2 -Server NCNode2.contoso.com

$c = New-NetworkControllerNodeObject -Name Node3 -Server NCNode3.contoso.com

$cert= get-item Cert:\LocalMachine\My | get-ChildItem | where {$_.Subject -

imatch "networkController.contoso.com" }
Install-NetworkControllerCluster -Node @($a,$b,$c) -ClusterAuthentication

Kerberos -DiagnosticLogLocation \\share\Diagnostics -
ManagementSecurityGroup Contoso\NCManagementAdmins -
CredentialEncryptionCertificate $cert
Install-NetworkController -Node @($a,$b,$c) -ClientAuthentication Kerberos -

ClientSecurityGroup Contoso\NCRESTClients -ServerCertificate $cert -
RestIpAddress 10.0.0.1/24
Etapas pós-implantação para implantações não

Kerberos
Se você não estiver usando o Kerberos com a implantação do Controlador de Rede,
deverá implantar certificados.
Para obter mais informações, consulte As Etapas pós-implantação do Controlador de

Rede.
Gerenciar SDN
Você pode usar os tópicos nesta seção para gerenciar a Rede Definida pelo Software,
incluindo cargas de trabalho de locatário e redes virtuais.
７ Observação
Para documentação adicional de Rede Definida pelo Software, você pode usar as
Tecnologias SDN
Planejar O SDN
Implantar SDN
Segurança para SDN
Gerenciar redes virtuais de locatário

Gerenciar cargas de trabalho de locatário
Atualizar, fazer backup e restaurar a infraestrutura de rede definida pelo software
Gerenciar redes virtuais do locatário
Você pode usar os tópicos desta seção para gerenciar redes virtuais de virtualização de
rede Hyper-V de locatário depois de ter implantado a rede definida pelo software
usando o tópico implantar uma infraestrutura de rede definida pelo software usando
scripts.
Entendendo o uso de redes virtuais e VLANs

Use ACLs (listas de controle de acesso) para gerenciar o tráfego de rede do
datacenter Flow
Criar, excluir ou atualizar redes virtuais de locatário
Adicionar um gateway virtual a uma rede virtual de locatário
Conectar pontos de extremidade do contêiner a uma rede virtual do locatário
Entender o uso de redes virtuais e
VLANs
Neste tópico, você aprenderá sobre redes virtuais de virtualização de rede Hyper-V e
como elas diferem das VLANs (redes locais virtuais). Com a virtualização de rede hyper-
V, você cria redes virtuais de sobreposição, também chamadas de redes virtuais.
A SDN (Rede Definida pelo Software) no Windows Server 2016 é baseada na política de
programação para sobreposição de redes virtuais em um Comutamento Virtual do
Hyper-V. Você pode criar redes virtuais de sobreposição, também chamadas de Redes
Virtuais, com a Virtualização de Rede Hyper-V.
Quando você implanta a Virtualização de Rede Hyper-V, as redes de sobreposição são

criadas encapsulando o quadro Ethernet de Camada 2 da máquina virtual de locatário
original com um header de sobreposição ( ou túnel – (por exemplo, VXLAN ou NVGRE)
e os headers IP de Camada 3 e Ethernet de Camada 2 da rede de subposição (ou física).
As redes virtuais de sobreposição são identificadas por um VNI (Identificador de Rede
Virtual) de 24 bits para manter o isolamento de tráfego de locatário e permitir
endereços IP sobrepostos. A VNI é composta por uma VSID (ID de sub-rede virtual), ID
de comutamento lógico e ID de túnel.
Além disso, cada locatário recebe um domínio de roteamento (semelhante ao

roteamento e encaminhamento virtual – VRF) para que vários prefixos de sub-rede
virtuais (cada um representado por uma VNI) possam ser roteados diretamente entre si.
Não há suporte para o roteamento entre locatários (ou domínio de roteamento
cruzado) sem passar por um gateway.
A rede física na qual o tráfego encapsulado de cada locatário é encapsulado é

representada por uma rede lógica chamada rede lógica do provedor. Essa rede lógica
do provedor consiste em uma ou mais sub-redes, cada uma representada por um
Prefixo IP e, opcionalmente, uma marca VLAN 802.1q.
Você pode criar redes lógicas e sub-redes adicionais para fins de infraestrutura para
transportar o tráfego de gerenciamento, o tráfego de armazenamento, o tráfego de
migração ao vivo etc.
O Microsoft SDN não dá suporte ao isolamento de redes de locatário usando VLANs. O
isolamento de locatário é realizado exclusivamente usando o encapsulamento e redes
virtuais de sobreposição de Virtualização de Rede Hyper-V.
Configurar grupos de segurança de rede
com o PowerShell
Este tópico fornece instruções para configurar NSGs (grupos de segurança de rede) para
gerenciar o fluxo de tráfego de dados usando o SDN (Firewall do Datacenter para Rede
Definida por Software) no Azure Stack HCI usando Windows PowerShell. Habilite e
configure o Firewall do Datacenter criando grupos de segurança de rede que são
aplicados a uma sub-rede ou a um adaptador de rede. Os scripts de exemplo neste
tópico usam comandos Windows PowerShell exportados do módulo
NetworkController. Você também pode usar Windows Admin Center para configurar e
gerenciar grupos de segurança de rede.
Configurar o Firewall do Datacenter para

permitir todo o tráfego
Depois de implantar o SDN, você deve testar a conectividade de rede básica em seu
novo ambiente. Para fazer isso, crie uma regra para o Firewall do Datacenter que
permita todo o tráfego de rede, sem restrições.
Use as entradas na tabela a seguir para criar um conjunto de regras que permitem todo
o tráfego de rede de entrada e saída.
IP de IP de Protocolo Porta de Porta de Direção Ação Prioridade

origem destino origem destino
* * Todos * * Entrada Allow 100
* * Todos * * Saída Allow 110
Neste exemplo, você cria um grupo de segurança de rede com duas regras:
1. AllowAll_Inbound – permite que todo o tráfego de rede passe para o adaptador

de rede em que esse grupo de segurança de rede está configurado.
2. AllowAllOutbound – permite que todo o tráfego passe para fora do adaptador de
rede. Esse grupo de segurança de rede, identificado pela ID do recurso "AllowAll-
1" agora está pronto para ser usado em sub-redes virtuais e interfaces de rede.
Primeiro, conecte-se a um dos nós de cluster abrindo uma sessão do PowerShell:
PowerShell
Enter-PSSession <server-name>
Em seguida, execute o seguinte script para criar o grupo de segurança de rede:
PowerShell
$ruleproperties = new-object
Microsoft.Windows.NetworkController.AclRuleProperties
$ruleproperties.Protocol = "All"
$ruleproperties.SourcePortRange = "0-65535"
$ruleproperties.DestinationPortRange = "0-65535"
$ruleproperties.Action = "Allow"
$ruleproperties.SourceAddressPrefix = "*"
$ruleproperties.DestinationAddressPrefix = "*"
$ruleproperties.Priority = "100"
$ruleproperties.Type = "Inbound"
$ruleproperties.Logging = "Enabled"
$aclrule1 = new-object Microsoft.Windows.NetworkController.AclRule
$aclrule1.Properties = $ruleproperties
$aclrule1.ResourceId = "AllowAll_Inbound"
$ruleproperties.Type = "Outbound"
$aclrule2.ResourceId = "AllowAll_Outbound"
$acllistproperties = new-object
Microsoft.Windows.NetworkController.AccessControlListProperties
$acllistproperties.AclRules = @($aclrule1, $aclrule2)
New-NetworkControllerAccessControlList -ResourceId "AllowAll" -Properties

$acllistproperties -ConnectionUri <NC REST FQDN>
７ Observação
A referência de comando Windows PowerShell para o Controlador de Rede está

localizada no tópico Cmdlets do Controlador de Rede.
Usar grupos de segurança de rede para limitar
o tráfego em uma sub-rede
Neste exemplo, você cria um grupo de segurança de rede que impede que máquinas
virtuais (VMs) na sub-rede 192.168.0.0/24 se comuniquem entre si. Esse tipo de grupo
de segurança de rede é útil para limitar a capacidade de um invasor se espalhar
lateralmente dentro da sub-rede, permitindo que as VMs recebam solicitações de fora
da sub-rede, bem como se comuniquem com outros serviços em outras sub-redes.
IP de origem IP de destino Protocolo Porta Porta Direção Ação Prioridade

de de
origem destino
192.168.0.1 * Todos * * Entrada Allow 100
* 192.168.0.1 Todos * * Saída Allow 101
192.168.0.0/24 * Todos * * Entrada Bloquear 102
* 192.168.0.0/24 Todos * * Saída Bloquear 103
O grupo de segurança de rede criado pelo script de exemplo abaixo, identificado pela
sub-rede de ID do recurso sub-rede-192-168-0-0, agora pode ser aplicado a uma sub-
rede de rede virtual que usa o endereço de sub-rede "192.168.0.0/24". Qualquer
adaptador de rede anexado a essa sub-rede de rede virtual obtém automaticamente as
regras de grupo de segurança de rede acima aplicadas.
Veja a seguir um exemplo de script para criar esse grupo de segurança de rede usando
a API REST do Controlador de Rede:
PowerShell
import-module networkcontroller
$ncURI = "https://mync.contoso.local"
$aclrules = @()
$ruleproperties.SourceAddressPrefix = "192.168.0.1"
$aclrule = new-object Microsoft.Windows.NetworkController.AclRule
$aclrule.Properties = $ruleproperties
$aclrule.ResourceId = "AllowRouter_Inbound"
$aclrules += $aclrule
$ruleproperties.DestinationAddressPrefix = "192.168.0.1"
$aclrule.ResourceId = "AllowRouter_Outbound"
$ruleproperties.Action = "Deny"
$ruleproperties.SourceAddressPrefix = "192.168.0.0/24"
$aclrule.ResourceId = "DenySubnet_Inbound"
$ruleproperties.DestinationAddressPrefix = "192.168.0.0/24"
$aclrule.ResourceId = "DenySubnet_Outbound"
$aclrule.ResourceId = "AllowAll_Inbound"
$aclrule.ResourceId = "AllowAll_Outbound"
$acllistproperties.AclRules = $aclrules
New-NetworkControllerAccessControlList -ResourceId "Subnet-192-168-0-0" -

Properties $acllistproperties -ConnectionUri $ncURI
Adicionar um grupo de segurança de rede a

um adaptador de rede
Depois de criar um grupo de segurança de rede e atribuí-lo a uma sub-rede virtual,
convém substituir esse grupo de segurança de rede padrão na sub-rede virtual por um
grupo de segurança de rede específico para um adaptador de rede individual. A partir
do Windows Server 2019 Datacenter, você pode aplicar grupos de segurança de rede
específicos diretamente a interfaces de rede anexadas a redes lógicas SDN, além de
redes virtuais SDN. Se você tiver grupos de segurança de rede definidos na sub-rede
virtual conectada ao adaptador de rede, ambos os grupos de segurança de rede serão
aplicados e os grupos de segurança de rede do adaptador de rede serão priorizados
acima dos grupos de segurança de rede de sub-rede virtual.
Neste exemplo, demonstramos como adicionar um grupo de segurança de rede a uma

rede virtual.
 Dica
Também é possível adicionar um grupo de segurança de rede ao mesmo tempo em

que você cria o adaptador de rede.
1. Obtenha ou crie o adaptador de rede ao qual você adicionará o grupo de

segurança de rede.
PowerShell
$nic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "MyVM_Ethernet1"
2. Obtenha ou crie o grupo de segurança de rede que você adicionará ao adaptador

de rede.
PowerShell
$acl = get-networkcontrolleraccesscontrollist -ConnectionUri $uri -

ResourceId "AllowAllACL"
3. Atribua o grupo de segurança de rede à propriedade AccessControlList do

adaptador de rede.
PowerShell
$nic.properties.ipconfigurations[0].properties.AccessControlList =
$acl
4. Adicione o adaptador de rede ao Controlador de Rede.
PowerShell
new-networkcontrollernetworkinterface -ConnectionUri $uri -Properties
$nic.properties -ResourceId $nic.resourceid
Remover um grupo de segurança de rede de

Neste exemplo, mostramos como remover um grupo de segurança de rede de um
adaptador de rede. A remoção de um grupo de segurança de rede aplica o conjunto
padrão de regras ao adaptador de rede. O conjunto padrão de regras permite todo o
tráfego de saída, mas bloqueia todo o tráfego de entrada. Se você quiser permitir todo
o tráfego de entrada, deverá seguir o exemplo anterior para adicionar um grupo de
segurança de rede que permita todo o tráfego de entrada e de saída.
1. Obtenha o adaptador de rede do qual você removerá o grupo de segurança de

rede.
PowerShell

2. Atribua $null à propriedade AccessControlList do ipConfiguration.
PowerShell
$null
3. Adicione o objeto de interface de rede no Controlador de Rede.
PowerShell

Auditoria de firewall
Introduzida no Windows Server 2019, a auditoria de firewall é uma nova funcionalidade
para o Firewall do Datacenter que registra qualquer fluxo processado pelas regras de
firewall do SDN. Todos os grupos de segurança de rede que têm o registro em log
habilitado são registrados. Os arquivos de log devem estar em uma sintaxe consistente
com os logs de fluxo do Azure Observador de Rede. Esses logs podem ser usados para
diagnóstico ou arquivados para análise posterior.
Aqui está um script de exemplo para habilitar a auditoria de firewall nos servidores host.
Atualize as variáveis no início e execute-as em um cluster do Azure Stack HCI com o
Controlador de Rede implantado:
PowerShell
$logpath = "C:\test\log1"
$servers = @("sa18n22-2", "sa18n22-3", "sa18n22-4")
$uri = "https://sa18n22sdn.sa18.nttest.microsoft.com"
# Create log directories on the hosts
invoke-command -Computername $servers {
param(
$Path
mkdir $path -force
} -argumentlist $LogPath
# Set firewall auditing settings on Network Controller
$AuditProperties = new-object
Microsoft.Windows.NetworkController.AuditingSettingsProperties
$AuditProperties.OutputDirectory = $logpath
set-networkcontrollerauditingsettingsconfiguration -connectionuri $uri -

properties $AuditProperties -force | out-null
# Enable logging on each server
$servers = get-networkcontrollerserver -connectionuri $uri
foreach ($s in $servers) {
$s.properties.AuditingEnabled = @("Firewall")
new-networkcontrollerserver -connectionuri $uri -resourceid

$s.resourceid -properties $s.properties -force | out-null
Uma vez habilitado, um novo arquivo aparece no diretório especificado em cada host
cerca de uma vez por hora. Você deve processar periodicamente esses arquivos e
removê-los dos hosts. O arquivo atual tem comprimento zero e fica bloqueado até ser
liberado na marca da próxima hora:
syntax
PS C:\test\log1> dir
Directory: C:\test\log1
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 7/19/2018 6:28 AM 17055

SdnFirewallAuditing.d8b3b697-5355-40e2-84d2-
1bf2f0e0dc4a.20180719TL122803093.json
-a---- 7/19/2018 7:28 AM 7880

1bf2f0e0dc4a.20180719TL132803173.json
-a---- 7/19/2018 8:28 AM 7867

1bf2f0e0dc4a.20180719TL142803264.json
-a---- 7/19/2018 9:28 AM 10949

1bf2f0e0dc4a.20180719TL152803360.json
-a---- 7/19/2018 9:28 AM 0

1bf2f0e0dc4a.20180719TL162803464.json
Esses arquivos contêm uma sequência de eventos de fluxo, por exemplo:
syntax
"records": [
"properties":{
"Version":"1.0",
"flows":[
"flows":[
{
"flowTuples":
["1531963580,192.122.0.22,192.122.255.255,138,138,U,I,A"],
"portId":"9",
"portName":"7290436D-0422-498A-8EB8-
C6CF5115DACE"
],
"rule":"Allow_Inbound"
},
"operationName":"NetworkSecurityGroupFlowEvents",
"resourceId":"394f647d-2ed0-4c31-87c5-389b8c0c8132",
"time":"20180719:L012620622",
"category":"NetworkSecurityGroupFlowEvent",
"systemId":"d8b3b697-5355-40e2-84d2-1bf2f0e0dc4a"
},
Observe que o registro em log ocorre apenas para regras que têm o registro em log
definido como Habilitado, por exemplo:
syntax
{
"Tags": null,
"ResourceRef": "/accessControlLists/AllowAll",
"InstanceId": "4a63e1a5-3264-4986-9a59-4e77a8b107fa",
"Etag": "W/\"1535a780-0fc8-4bba-a15a-093ecac9b88b\"",
"ResourceMetadata": null,
"ResourceId": "AllowAll",
"Properties": {
"ConfigurationState": null,
"ProvisioningState": "Succeeded",
"AclRules": [
"ResourceRef":
"/accessControlLists/AllowAll/aclRules/AllowAll_Inbound",
"InstanceId": "ba8710a8-0f01-
422b-9038-d1f2390645d7",
"Etag": "W/\"1535a780-0fc8-
4bba-a15a-093ecac9b88b\"",
"ResourceId":
"AllowAll_Inbound",
"Properties": {
"Protocol":
"All",
"SourcePortRange": "0-65535",
"DestinationPortRange": "0-65535",
"Action":
"Allow",
"SourceAddressPrefix": "*",
"DestinationAddressPrefix": "*",
"Priority":
"101",
"Description": null,
"Type":
"Inbound",
"Logging":
"Enabled",
"ProvisioningState": "Succeeded"
}
},
"ResourceRef":
"/accessControlLists/AllowAll/aclRules/AllowAll_Outbound",
"InstanceId": "068264c6-2186-
4dbc-bbe7-f504c6f47fa8",
"Etag": "W/\"1535a780-0fc8-
"ResourceId":
"AllowAll_Outbound",
"Properties": {
"Protocol":
"All",
"Action":
"Allow",
"Priority":
"110",
"Type":
"Outbound",
"Logging":
"Enabled",
}
],
"IpConfigurations": [
],
"Subnets": [
"ResourceRef":
"/virtualNetworks/10_0_1_0/subnets/Subnet1",
"InstanceId": "00000000-0000-
0000-0000-000000000000",
"Etag": null,
"ResourceId": null,
"Properties": null
Próximas etapas
Visão geral do Firewall do Datacenter

Criar, excluir ou atualizar redes virtuais
do locatário
Neste tópico, você aprenderá a criar, excluir e atualizar Redes Virtuais de Virtualização
de Rede Hyper-V depois de implantar a SDN (Rede Definida pelo Software). A
Virtualização de Rede Hyper-V ajuda a isolar redes de locatário para que cada rede de
locatário seja uma entidade separada. Cada entidade não tem nenhuma possibilidade
de conexão cruzada, a menos que você configure cargas de trabalho de acesso público.
Criar uma nova rede virtual

A criação de uma rede virtual para um locatário a coloca em um domínio de roteamento
exclusivo no host Hyper-V. Abaixo de cada rede virtual, há pelo menos uma sub-rede
virtual. Sub-redes virtuais são definidas por um prefixo IP e referenciam uma ACL
definida anteriormente.
As etapas para criar uma nova rede virtual são:
1. Identifique os prefixos de endereço IP dos quais você deseja criar as sub-redes

virtuais.
2. Identifique a rede do provedor lógico na qual o tráfego de locatário é túnel.
3. Crie pelo menos uma sub-rede virtual para cada prefixo IP identificado na etapa 1.
4. (Opcional) Adicione as ACLs criadas anteriormente às sub-redes virtuais ou
adicione conectividade de gateway para locatários.
A tabela a seguir inclui exemplos de IDs de sub-rede e prefixos para dois locatários
fictícios. O locatário Fabrikam tem duas sub-redes virtuais, enquanto o locatário da
Contoso tem três sub-redes virtuais.
Nome do locatário ID de Sub-rede Virtual Prefixo de sub-rede virtual
Fabrikam 5001 24.30.1.0/24
Fabrikam 5002 24.30.2.0/20
Contoso 6001 24.30.1.0/24

Nome do locatário ID de Sub-rede Virtual Prefixo de sub-rede virtual
Contoso 6002 24.30.2.0/24
Contoso 6003 24.30.3.0/24
O script de exemplo a seguir Windows PowerShell comandos exportados do módulo

NetworkController para criar a rede virtual da Contoso e uma sub-rede:
Powershell
$URI = "https://ncrest.contoso.local"
#Find the HNV Provider Logical Network
$logicalnetworks = Get-NetworkControllerLogicalNetwork -ConnectionUri $uri
foreach ($ln in $logicalnetworks) {
if ($ln.Properties.NetworkVirtualizationEnabled -eq "True") {
$HNVProviderLogicalNetwork = $ln
#Find the Access Control List to user per virtual subnet
$acllist = Get-NetworkControllerAccessControlList -ConnectionUri $uri -

ResourceId "AllowAll"
#Create the Virtual Subnet
$vsubnet = new-object Microsoft.Windows.NetworkController.VirtualSubnet
$vsubnet.ResourceId = "Contoso_WebTier"
$vsubnet.Properties = new-object
Microsoft.Windows.NetworkController.VirtualSubnetProperties
$vsubnet.Properties.AccessControlList = $acllist
$vsubnet.Properties.AddressPrefix = "24.30.1.0/24"
#Create the Virtual Network
$vnetproperties = new-object
Microsoft.Windows.NetworkController.VirtualNetworkProperties
$vnetproperties.AddressSpace = new-object
Microsoft.Windows.NetworkController.AddressSpace
$vnetproperties.AddressSpace.AddressPrefixes = @("24.30.1.0/24")
$vnetproperties.LogicalNetwork = $HNVProviderLogicalNetwork
$vnetproperties.Subnets = @($vsubnet)
New-NetworkControllerVirtualNetwork -ResourceId "Contoso_VNet1" -

ConnectionUri $uri -Properties $vnetproperties
Modificar uma rede virtual existente

Você pode usar Windows PowerShell para atualizar uma sub-rede virtual ou rede
existente.
Quando você executar o script de exemplo a seguir, os recursos atualizados serão

simplesmente PUT to Network Controller com a mesma ID de recurso. Se seu locatário
Contoso quiser adicionar uma nova sub-rede virtual (24.30.2.0/24) à rede virtual, você
ou o Administrador da Contoso poderão usar o script a seguir.
PowerShell
$acllist = Get-NetworkControllerAccessControlList -ConnectionUri $uri -

$vnet = Get-NetworkControllerVirtualNetwork -ResourceId "Contoso_VNet1" -

ConnectionUri $uri
$vnet.properties.AddressSpace.AddressPrefixes += "24.30.2.0/24"
$vsubnet.ResourceId = "Contoso_DBTier"
$vsubnet.Properties.AccessControlList = $acllist
$vnet.properties.Subnets += $vsubnet

ConnectionUri $uri -properties $vnet.properties
Excluir uma rede virtual

Você pode usar Windows PowerShell para excluir uma Rede Virtual.
O exemplo Windows PowerShell a seguir exclui uma Rede Virtual de locatário emindo
uma exclusão HTTP para o URI da ID do Recurso.
PowerShell
Remove-NetworkControllerVirtualNetwork -ResourceId "Contoso_Vnet1" -

ConnectionUri $uri
Adicionar um gateway virtual a uma

rede virtual de locatário
Saiba como usar Windows PowerShell cmdlets e scripts para fornecer conectividade site
a site para as redes virtuais do locatário. Neste tópico, você adiciona gateways virtuais
de locatário a instâncias do gateway RAS que são membros de pools de gateways,
usando o Controlador de Rede. O gateway RAS dá suporte a até cem locatários,
dependendo da largura de banda usada por cada locatário. O Controlador de Rede
determina automaticamente o melhor Gateway de RAS a ser usado quando você
implanta um novo gateway virtual para seus locatários.
Cada gateway virtual corresponde a um locatário específico e consiste em uma ou mais

conexões de rede (túneis VPN site a site) e, opcionalmente, conexões BGP (Border
Gateway Protocol). Quando você fornece conectividade site a site, seus clientes podem
conectar sua rede virtual de locatário a uma rede externa, como uma rede empresarial
de locatário, uma rede de provedor de serviços ou a Internet.
Ao implantar um Gateway Virtual de Locatário, você tem as seguintes opções de

configuração:
Opções de conexão de rede Opções de configuração do BGP
VPN (rede virtual privada) ipsec site a site Configuração do roteador BGP
GRE (Encapsulamento de Roteamento Configuração de par BGP
Genérico) Configuração de políticas de
Encaminhamento de camada 3 roteamento BGP
O Windows PowerShell exemplo de scripts e comandos neste tópico demonstra como

implantar um gateway virtual de locatário em um Gateway ras com cada uma dessas
opções.
） Importante
Antes de executar qualquer um dos comandos e scripts Windows PowerShell de

exemplo fornecidos, você deve alterar todos os valores de variáveis para que os
valores sejam apropriados para sua implantação.
1. Verifique se o objeto do pool de gateway existe no controlador de rede.
PowerShell
$uri = "https://ncrest.contoso.com"
# Retrieve the Gateway Pool configuration
$gwPool = Get-NetworkControllerGatewayPool -ConnectionUri $uri
# Display in JSON format
$gwPool | ConvertTo-Json -Depth 2
2. Verifique se a sub-rede usada para rotear pacotes da rede virtual do locatário

existe no Controlador de Rede. Você também recupera a sub-rede virtual usada
para roteamento entre o gateway de locatário e a rede virtual.
PowerShell
$uri = "https://ncrest.contoso.com"
# Retrieve the Tenant Virtual Network configuration
$Vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -

ResourceId "Contoso_Vnet1"
$Vnet | ConvertTo-Json -Depth 4
# Retrieve the Tenant Virtual Subnet configuration
$RoutingSubnet = Get-NetworkControllerVirtualSubnet -ConnectionUri $uri

-ResourceId "Contoso_WebTier" -VirtualNetworkID $vnet.ResourceId
$RoutingSubnet | ConvertTo-Json -Depth 4
3. Crie um novo objeto para o gateway virtual de locatário e atualize a referência do

pool de gateway. Você também especifica a sub-rede virtual usada para
roteamento entre o gateway e a rede virtual. Depois de especificar a sub-rede
virtual, você atualiza o restante das propriedades do objeto do gateway virtual e,
em seguida, adiciona o novo gateway virtual para o locatário.
PowerShell
# Create a new object for Tenant Virtual Gateway
$VirtualGWProperties = New-Object
Microsoft.Windows.NetworkController.VirtualGatewayProperties
# Update Gateway Pool reference
$VirtualGWProperties.GatewayPools = @()
$VirtualGWProperties.GatewayPools += $gwPool
# Specify the Virtual Subnet that is to be used for routing between the
gateway and Virtual Network
$VirtualGWProperties.GatewaySubnets = @()
$VirtualGWProperties.GatewaySubnets += $RoutingSubnet
# Update the rest of the Virtual Gateway object properties
$VirtualGWProperties.RoutingType = "Dynamic"
$VirtualGWProperties.NetworkConnections = @()
$VirtualGWProperties.BgpRouters = @()
# Add the new Virtual Gateway for tenant
$virtualGW = New-NetworkControllerVirtualGateway -ConnectionUri $uri -

ResourceId "Contoso_VirtualGW" -Properties $VirtualGWProperties -Force
4. Crie uma conexão VPN site a site com encaminhamento IPsec, GRE ou Camada 3
(L3).
 Dica
Opcionalmente, você pode combinar todas as etapas anteriores e configurar

um gateway virtual de locatário com as três opções de conexão. Para obter
mais detalhes, consulte Configurar um gateway com todos os três tipos de
conexão (IPsec, GRE, L3) e BGP.
Conexão de rede site a site vpn IPsec
PowerShell
# Create a new object for Tenant Network Connection
$nwConnectionProperties = New-Object
Microsoft.Windows.NetworkController.NetworkConnectionProperties
# Update the common object properties
$nwConnectionProperties.ConnectionType = "IPSec"
$nwConnectionProperties.OutboundKiloBitsPerSecond = 10000
$nwConnectionProperties.InboundKiloBitsPerSecond = 10000
# Update specific properties depending on the Connection Type
$nwConnectionProperties.IpSecConfiguration = New-Object
Microsoft.Windows.NetworkController.IpSecConfiguration
$nwConnectionProperties.IpSecConfiguration.AuthenticationMethod = "PSK"
$nwConnectionProperties.IpSecConfiguration.SharedSecret = "P@ssw0rd"
$nwConnectionProperties.IpSecConfiguration.QuickMode = New-Object
Microsoft.Windows.NetworkController.QuickMode
$nwConnectionProperties.IpSecConfiguration.QuickMode.PerfectForwardSecr
ecy = "PFS2048"
$nwConnectionProperties.IpSecConfiguration.QuickMode.AuthenticationTran
sformationConstant = "SHA256128"
$nwConnectionProperties.IpSecConfiguration.QuickMode.CipherTransformati
onConstant = "DES3"
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeSeconds
= 1233
$nwConnectionProperties.IpSecConfiguration.QuickMode.IdleDisconnectSeco
nds = 500
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeKiloByte
s = 2000
$nwConnectionProperties.IpSecConfiguration.MainMode = New-Object
Microsoft.Windows.NetworkController.MainMode
$nwConnectionProperties.IpSecConfiguration.MainMode.DiffieHellmanGroup
= "Group2"
$nwConnectionProperties.IpSecConfiguration.MainMode.IntegrityAlgorithm
= "SHA256"
$nwConnectionProperties.IpSecConfiguration.MainMode.EncryptionAlgorithm
= "AES256"
$nwConnectionProperties.IpSecConfiguration.MainMode.SALifeTimeSeconds =
1234
$nwConnectionProperties.IpSecConfiguration.MainMode.SALifeTimeKiloBytes
= 2000
# L3 specific configuration (leave blank for IPSec)
$nwConnectionProperties.IPAddresses = @()
$nwConnectionProperties.PeerIPAddresses = @()
# Update the IPv4 Routes that are reachable over the site-to-site VPN
Tunnel
$nwConnectionProperties.Routes = @()
$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo
$ipv4Route.DestinationPrefix = "14.1.10.1/32"
$ipv4Route.metric = 10
$nwConnectionProperties.Routes += $ipv4Route
# Tunnel Destination (Remote Endpoint) Address
$nwConnectionProperties.DestinationIPAddress = "10.127.134.121"
# Add the new Network Connection for the tenant
New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri
$uri -VirtualGatewayId $virtualGW.ResourceId -ResourceId
"Contoso_IPSecGW" -Properties $nwConnectionProperties -Force
Conexão de rede site a site do GRE VPN
PowerShell
# Create a new object for the Tenant Network Connection
$nwConnectionProperties.ConnectionType = "GRE"
$nwConnectionProperties.GreConfiguration = New-Object
Microsoft.Windows.NetworkController.GreConfiguration
$nwConnectionProperties.GreConfiguration.GreKey = 1234
Tunnel
$nwConnectionProperties.DestinationIPAddress = "10.127.134.122"
# L3 specific configuration (leave blank for GRE)
$nwConnectionProperties.L3Configuration = New-Object
Microsoft.Windows.NetworkController.L3Configuration
"Contoso_GreGW" -Properties $nwConnectionProperties -Force
Conexão de rede de encaminhamento L3
Para que uma conexão de rede de encaminhamento L3 funcione corretamente,

você deve configurar uma rede lógica correspondente.
a. Configure uma rede lógica para a conexão de rede de encaminhamento L3.
PowerShell
# Create a new object for the Logical Network to be used for L3

Forwarding
$lnProperties = New-Object
Microsoft.Windows.NetworkController.LogicalNetworkProperties
$lnProperties.NetworkVirtualizationEnabled = $false
$lnProperties.Subnets = @()
# Create a new object for the Logical Subnet to be used for L3

Forwarding and update properties
$logicalsubnet = New-Object
Microsoft.Windows.NetworkController.LogicalSubnet
$logicalsubnet.ResourceId = "Contoso_L3_Subnet"
$logicalsubnet.Properties = New-Object
Microsoft.Windows.NetworkController.LogicalSubnetProperties
$logicalsubnet.Properties.VlanID = 1001
$logicalsubnet.Properties.AddressPrefix = "10.127.134.0/25"
$logicalsubnet.Properties.DefaultGateways = "10.127.134.1"
$lnProperties.Subnets += $logicalsubnet
# Add the new Logical Network to Network Controller
$vlanNetwork = New-NetworkControllerLogicalNetwork -ConnectionUri

$uri -ResourceId "Contoso_L3_Network" -Properties $lnProperties -
Force
b. Crie um objeto JSON de conexão de rede e adicione-o ao Controlador de Rede.
PowerShell
# Create a new object for the Tenant Network Connection
$nwConnectionProperties.ConnectionType = "L3"
# GRE specific configuration (leave blank for L3)
$nwConnectionProperties.GreConfiguration = New-Object
$nwConnectionProperties.L3Configuration = New-Object
$nwConnectionProperties.L3Configuration.VlanSubnet =
$vlanNetwork.properties.Subnets[0]
$localIPAddress = New-Object
Microsoft.Windows.NetworkController.CidrIPAddress
$localIPAddress.IPAddress = "10.127.134.55"
$localIPAddress.PrefixLength = 25
$nwConnectionProperties.IPAddresses += $localIPAddress
$nwConnectionProperties.PeerIPAddresses = @("10.127.134.65")
Tunnel
"Contoso_L3GW" -Properties $nwConnectionProperties -Force
5. Configure o gateway como um roteador BGP e adicione-o ao Controlador de

Rede.
a. Adicione um roteador BGP para o locatário.
PowerShell
# Create a new object for the Tenant BGP Router
$bgpRouterproperties = New-Object
Microsoft.Windows.NetworkController.VGwBgpRouterProperties
# Update the BGP Router properties
$bgpRouterproperties.ExtAsNumber = "0.64512"
$bgpRouterproperties.RouterId = "192.168.0.2"
$bgpRouterproperties.RouterIP = @("192.168.0.2")
# Add the new BGP Router for the tenant
$bgpRouter = New-NetworkControllerVirtualGatewayBgpRouter -
ConnectionUri $uri -VirtualGatewayId $virtualGW.ResourceId -
ResourceId "Contoso_BgpRouter1" -Properties $bgpRouterProperties -
Force
b. Adicione um par BGP para esse locatário, correspondente à Conexão de Rede

VPN site a site adicionada acima.
PowerShell
# Create a new object for Tenant BGP Peer
$bgpPeerProperties = New-Object
Microsoft.Windows.NetworkController.VGwBgpPeerProperties
# Update the BGP Peer properties
$bgpPeerProperties.PeerIpAddress = "14.1.10.1"
$bgpPeerProperties.AsNumber = 64521
$bgpPeerProperties.ExtAsNumber = "0.64521"
# Add the new BGP Peer for tenant

New-NetworkControllerVirtualGatewayBgpPeer -ConnectionUri $uri -
VirtualGatewayId $virtualGW.ResourceId -BgpRouterName
$bgpRouter.ResourceId -ResourceId "Contoso_IPSec_Peer" -Properties
$bgpPeerProperties -Force
(Etapa opcional) Configurar um gateway com

todos os três tipos de conexão (IPsec, GRE, L3)
e BGP
Opcionalmente, você pode combinar todas as etapas anteriores e configurar um
gateway virtual de locatário com as três opções de conexão:
PowerShell
# Create a new Virtual Gateway Properties type object
$VirtualGWProperties = New-Object
Microsoft.Windows.NetworkController.VirtualGatewayProperties
# Update GatewayPool reference
$VirtualGWProperties.GatewayPools = @()
$VirtualGWProperties.GatewayPools += $gwPool
# Specify the Virtual Subnet that is to be used for routing between GW and
VNET
$VirtualGWProperties.GatewaySubnets = @()
$VirtualGWProperties.GatewaySubnets += $RoutingSubnet
# Update some basic properties
$VirtualGWProperties.RoutingType = "Dynamic"
# Update Network Connection object(s)
$VirtualGWProperties.NetworkConnections = @()
# IPSec Connection configuration
$ipSecConnection = New-Object
Microsoft.Windows.NetworkController.NetworkConnection
$ipSecConnection.ResourceId = "Contoso_IPSecGW"
$ipSecConnection.Properties = New-Object
$ipSecConnection.Properties.ConnectionType = "IPSec"
$ipSecConnection.Properties.OutboundKiloBitsPerSecond = 10000
$ipSecConnection.Properties.InboundKiloBitsPerSecond = 10000
$ipSecConnection.Properties.IpSecConfiguration = New-Object
$ipSecConnection.Properties.IpSecConfiguration.AuthenticationMethod = "PSK"
$ipSecConnection.Properties.IpSecConfiguration.SharedSecret = "P@ssw0rd"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode = New-Object
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.PerfectForwardSecre
cy = "PFS2048"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.AuthenticationTrans
formationConstant = "SHA256128"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.CipherTransformatio
nConstant = "DES3"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.SALifeTimeSeconds =
1233
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.IdleDisconnectSecon
ds = 500
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.SALifeTimeKiloBytes
= 2000
$ipSecConnection.Properties.IpSecConfiguration.MainMode = New-Object
$ipSecConnection.Properties.IpSecConfiguration.MainMode.DiffieHellmanGroup =
"Group2"
$ipSecConnection.Properties.IpSecConfiguration.MainMode.IntegrityAlgorithm =
"SHA256"
$ipSecConnection.Properties.IpSecConfiguration.MainMode.EncryptionAlgorithm
= "AES256"
$ipSecConnection.Properties.IpSecConfiguration.MainMode.SALifeTimeSeconds =
1234
$ipSecConnection.Properties.IpSecConfiguration.MainMode.SALifeTimeKiloBytes
= 2000
$ipSecConnection.Properties.IPAddresses = @()
$ipSecConnection.Properties.PeerIPAddresses = @()
$ipSecConnection.Properties.Routes = @()
$ipSecConnection.Properties.Routes += $ipv4Route
$ipSecConnection.Properties.DestinationIPAddress = "10.127.134.121"
# GRE Connection configuration
$greConnection = New-Object
$greConnection.ResourceId = "Contoso_GreGW"
$greConnection.Properties = New-Object
$greConnection.Properties.ConnectionType = "GRE"
$greConnection.Properties.OutboundKiloBitsPerSecond = 10000
$greConnection.Properties.InboundKiloBitsPerSecond = 10000
$greConnection.Properties.GreConfiguration = New-Object
$greConnection.Properties.GreConfiguration.GreKey = 1234
$greConnection.Properties.IPAddresses = @()
$greConnection.Properties.PeerIPAddresses = @()
$greConnection.Properties.Routes = @()
$greConnection.Properties.Routes += $ipv4Route
$greConnection.Properties.DestinationIPAddress = "10.127.134.122"
$greConnection.Properties.L3Configuration = New-Object
# L3 Forwarding connection configuration
$l3Connection = New-Object
$l3Connection.ResourceId = "Contoso_L3GW"
$l3Connection.Properties = New-Object
$l3Connection.Properties.ConnectionType = "L3"
$l3Connection.Properties.OutboundKiloBitsPerSecond = 10000
$l3Connection.Properties.InboundKiloBitsPerSecond = 10000
$l3Connection.Properties.GreConfiguration = New-Object
$l3Connection.Properties.L3Configuration = New-Object
$l3Connection.Properties.L3Configuration.VlanSubnet =
$vlanNetwork.properties.Subnets[0]
$l3Connection.Properties.IPAddresses = @()
$localIPAddress = New-Object
Microsoft.Windows.NetworkController.CidrIPAddress
$localIPAddress.IPAddress = "10.127.134.55"
$localIPAddress.PrefixLength = 25
$l3Connection.Properties.IPAddresses += $localIPAddress
$l3Connection.Properties.PeerIPAddresses = @("10.127.134.65")
$l3Connection.Properties.Routes = @()
$l3Connection.Properties.Routes += $ipv4Route
# Update BGP Router Object
$VirtualGWProperties.BgpRouters = @()
$bgpRouter = New-Object Microsoft.Windows.NetworkController.VGwBgpRouter
$bgpRouter.ResourceId = "Contoso_BgpRouter1"
$bgpRouter.Properties = New-Object
Microsoft.Windows.NetworkController.VGwBgpRouterProperties
$bgpRouter.Properties.ExtAsNumber = "0.64512"
$bgpRouter.Properties.RouterId = "192.168.0.2"
$bgpRouter.Properties.RouterIP = @("192.168.0.2")
$bgpRouter.Properties.BgpPeers = @()
# Create BGP Peer Object(s)
# BGP Peer for IPSec Connection
$bgpPeer_IPSec = New-Object Microsoft.Windows.NetworkController.VGwBgpPeer
$bgpPeer_IPSec.ResourceId = "Contoso_IPSec_Peer"
$bgpPeer_IPSec.Properties = New-Object
$bgpPeer_IPSec.Properties.PeerIpAddress = "14.1.10.1"
$bgpPeer_IPSec.Properties.AsNumber = 64521
$bgpPeer_IPSec.Properties.ExtAsNumber = "0.64521"
$bgpRouter.Properties.BgpPeers += $bgpPeer_IPSec
# BGP Peer for GRE Connection
$bgpPeer_Gre = New-Object Microsoft.Windows.NetworkController.VGwBgpPeer
$bgpPeer_Gre.ResourceId = "Contoso_Gre_Peer"
$bgpPeer_Gre.Properties = New-Object
$bgpPeer_Gre.Properties.PeerIpAddress = "14.2.20.1"
$bgpPeer_Gre.Properties.AsNumber = 64522
$bgpPeer_Gre.Properties.ExtAsNumber = "0.64522"
$bgpRouter.Properties.BgpPeers += $bgpPeer_Gre
# BGP Peer for L3 Connection
$bgpPeer_L3 = New-Object Microsoft.Windows.NetworkController.VGwBgpPeer
$bgpPeer_L3.ResourceId = "Contoso_L3_Peer"
$bgpPeer_L3.Properties = New-Object
$bgpPeer_L3.Properties.PeerIpAddress = "14.3.30.1"
$bgpPeer_L3.Properties.AsNumber = 64523
$bgpPeer_L3.Properties.ExtAsNumber = "0.64523"
$bgpRouter.Properties.BgpPeers += $bgpPeer_L3
$VirtualGWProperties.BgpRouters += $bgpRouter
# Finally Add the new Virtual Gateway for tenant
New-NetworkControllerVirtualGateway -ConnectionUri $uri -ResourceId

"Contoso_VirtualGW" -Properties $VirtualGWProperties -Force
Modificar um gateway para uma rede virtual

Recuperar a configuração do componente e armazená-la em uma variável
PowerShell
$nwConnection = Get-NetworkControllerVirtualGatewayNetworkConnection -
ConnectionUri $uri -VirtualGatewayId "Contoso_VirtualGW" -ResourceId
"Contoso_IPSecGW"
Navegue pela estrutura variável para alcançar a propriedade necessária e defina-a

como o valor de atualizações
PowerShell
$nwConnection.properties.IpSecConfiguration.SharedSecret = "C0mplexP@ssW0rd"
Adicionar a configuração modificada para substituir a configuração mais antiga no

Controlador de Rede
PowerShell
New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -

VirtualGatewayId "Contoso_VirtualGW" -ResourceId $nwConnection.ResourceId -
Properties $nwConnection.Properties -Force
Remover um gateway de uma rede virtual

Você pode usar os comandos Windows PowerShell a seguir para remover os recursos
individuais do gateway ou todo o gateway.
Remover uma conexão de rede
PowerShell
Remove-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri

-VirtualGatewayId "Contoso_VirtualGW" -ResourceId "Contoso_IPSecGW" -Force
Remover um par BGP
PowerShell
Remove-NetworkControllerVirtualGatewayBgpPeer -ConnectionUri $uri -

VirtualGatewayId "Contoso_VirtualGW" -BgpRouterName "Contoso_BgpRouter1" -
ResourceId "Contoso_IPSec_Peer" -Force
Remover um roteador BGP
PowerShell
Remove-NetworkControllerVirtualGatewayBgpRouter -ConnectionUri $uri -

VirtualGatewayId "Contoso_VirtualGW" -ResourceId "Contoso_BgpRouter1" -Force
Remover um gateway
PowerShell
Remove-NetworkControllerVirtualGateway -ConnectionUri $uri -ResourceId

"Contoso_VirtualGW" -Force
Conectar pontos de extremidade do

contêiner a uma rede virtual do
locatário
Neste tópico, mostramos como conectar pontos de extremidade de contêiner a uma

rede virtual de locatário existente criada por meio do SDN. Use o driver de rede l2bridge
(e, opcionalmente, l2tunnel) disponível com o plug-in Windows libnetwork do Docker
para criar uma rede de contêiner na VM do locatário.
No tópico Drivers de rede de contêiner, abordamos que vários drivers de rede estão
disponíveis por meio do Docker Windows. Para SDN, use os drivers l2bridge e l2tunnel .
Para ambos os drivers, cada ponto de extremidade de contêiner está na mesma sub-
rede virtual que a máquina virtual do host do contêiner (locatário).
O HNS (Serviço de Rede de Host), por meio do plug-in de nuvem privada, atribui
dinamicamente os endereços IP para pontos de extremidade de contêiner. Os pontos de
extremidade de contêiner têm endereços IP exclusivos, mas compartilham o mesmo
endereço MAC da máquina virtual do host do contêiner (locatário) devido à conversão
de endereços de Camada 2.
A política de rede (ACLs, encapsulamento e QoS) para esses pontos de extremidade de

contêiner é imposta no host físico do Hyper-V, conforme recebido pelo Controlador de
Rede e definido em sistemas de gerenciamento de camada superior.
As diferenças entre os drivers l2bridge e l2tunnel são:
l2bridge l2tunnel
l2bridge l2tunnel
Pontos de extremidade de contêiner que TODO o tráfego de rede entre dois pontos de
residem em: extremidade de contêiner é encaminhado para
A mesma máquina virtual do host de o host físico do Hyper-V, independentemente
contêiner e na mesma sub-rede têm do host ou da sub-rede. A política de rede se
todo o tráfego de rede ponte dentro do aplica ao tráfego de rede entre sub-redes e
comutando virtual hyper-V. entre host.
VMs de host de contêiner diferentes ou
em sub-redes diferentes têm seu tráfego
encaminhado para o host físico do
Hyper-V.
A política de rede não é imposta, pois o

tráfego de rede entre contêineres no mesmo
host e na mesma sub-rede não flui para o host
físico. A política de rede se aplica somente ao
tráfego de rede de contêiner entre host ou
entre sub-redes.
７ Observação
Esses modos de rede não funcionam para conectar pontos de extremidade de

contêiner do Windows a uma rede virtual de locatário na nuvem pública do Azure.
Pré-requisitos
Uma infraestrutura SDN implantada com o Controlador de Rede.
Uma rede virtual de locatário foi criada.
Uma máquina virtual de locatário implantada com o Windows contêiner habilitado,

o Docker instalado e o recurso Hyper-V habilitados. O recurso Hyper-V é
necessário para instalar vários binários para redes l2bridge e l2tunnel.
PowerShell
# To install HyperV feature without checks for nested virtualization
dism /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V /All
７ Observação
A virtualização aninhada e a exposição de extensões de virtualização não são

necessárias, a menos que use contêineres do Hyper-V.
Fluxo de trabalho
1. Adicione várias configurações de IP a um recurso NIC de VM existente por meio do
Controlador de Rede (Host hyper-V)2. Habilita o proxy de rede no host para alocar
endereços IP de AC para pontos de extremidade de contêiner (Host Hyper-V)3. Instale o
plug-in de nuvem privada para atribuir endereços IP de AC a pontos de extremidade de
contêiner (VM do Host de Contêiner)4. Criar uma rede l2bridge ou l2tunnel usando o
docker (VM do Host de Contêiner)
７ Observação
Não há suporte para várias configurações de IP em recursos de NIC de VM criados

por meio de System Center Virtual Machine Manager. É recomendável para esses
tipos de implantações que você cria o recurso de NIC da VM fora da banda usando
o PowerShell do Controlador de Rede.
1. Adicionar várias configurações de IP

Nesta etapa, vamos supor que a NIC da VM da máquina virtual do locatário tenha uma
configuração de IP com o endereço IP 192.168.1.9 e seja anexada a uma ID de recurso
de VNet de 'VNet1' e recurso de sub-rede de VM de 'Subnet1' na sub-rede IP
192.168.1.0/24. Adicionamos 10 endereços IP para contêineres de 192.168.1.101 a
192.168.1.110.
PowerShell
Import-Module NetworkController
# Specify Network Controller REST IP or FQDN
$uri = "<NC REST IP or FQDN>"
$vnetResourceId = "VNet1"
$vsubnetResourceId = "Subnet1"
$vmnic= Get-NetworkControllerNetworkInterface -ConnectionUri $uri | where

{$_.properties.IpConfigurations.Properties.PrivateIPAddress -eq
"192.168.1.9" }
$vmsubnet = Get-NetworkControllerVirtualSubnet -VirtualNetworkId

$vnetResourceId -ResourceId $vsubnetResourceId -ConnectionUri $uri
# For this demo, we will assume an ACL has already been defined; any ACL can
be applied here
$allowallacl = Get-NetworkControllerAccessControlList -ConnectionUri $uri -

foreach ($i in 1..10)
$newipconfig = new-object
Microsoft.Windows.NetworkController.NetworkInterfaceIpConfiguration
$props = new-object
Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationPropertie
s
$resourceid = "IP_192_168_1_1"
if ($i -eq 10)
$resourceid += "10"
$ipstr = "192.168.1.110"
else
$resourceid += "0$i"
$ipstr = "192.168.1.10$i"
$newipconfig.ResourceId = $resourceid
$props.PrivateIPAddress = $ipstr
$props.PrivateIPAllocationMethod = "Static"
$props.Subnet = new-object Microsoft.Windows.NetworkController.Subnet
$props.Subnet.ResourceRef = $vmsubnet.ResourceRef
$props.AccessControlList = new-object
Microsoft.Windows.NetworkController.AccessControlList
$props.AccessControlList.ResourceRef = $allowallacl.ResourceRef
$newipconfig.Properties = $props
$vmnic.Properties.IpConfigurations += $newipconfig
New-NetworkControllerNetworkInterface -ResourceId $vmnic.ResourceId -

Properties $vmnic.Properties -ConnectionUri $uri
2. Habilitar o proxy de rede

Nesta etapa, você permite que o proxy de rede aloce vários endereços IP para a
máquina virtual do host do contêiner.
Para habilitar o proxy de rede, execute o scriptConfigureMCNP.ps1 no Host Hyper-V

que hospeda a máquina virtual do host do contêiner (locatário).
PowerShell
PS C:\> ConfigureMCNP.ps1
3. Instalar o plug-in de Nuvem Privada

Nesta etapa, você instala um plug-in para permitir que o HNS se comunique com o
proxy de rede no Host hyper-V.
Para instalar o plug-in, execute o script InstallPrivateCloudPlugin.ps1 dentro da

máquina virtual do host do contêiner (locatário).
PowerShell
PS C:\> InstallPrivateCloudPlugin.ps1
4. Criar uma rede de contêiner l2bridge

Nesta etapa, você usa o comando na docker network create máquina docker network
create para criar uma rede l2bridge.
PowerShell
# Create the container network
C:\> docker network create -d l2bridge --subnet="192.168.1.0/24" --

gateway="192.168.1.1" MyContainerOverlayNetwork
# Attach a container to the MyContainerOverlayNetwork
C:\> docker run -it --network=MyContainerOverlayNetwork <image> <cmd>
７ Observação
Não há suporte para a atribuição de IP estático com redes de contêiner l2bridge ou

l2tunnel quando usadas com o Microsoft SDN Stack.
Mais informações
Para obter mais detalhes sobre como implantar uma infraestrutura de SDN, consulte
Implantar uma infraestrutura de rede definida pelo software.
Configurar criptografia para uma sub-
rede virtual
A criptografia de rede virtual permite a criptografia do tráfego de rede virtual entre VMs
que se comunicam entre si dentro de sub-redes marcadas como "Criptografia
Habilitada". Ela também utiliza o DTLS (Datagrama do protocolo TLS) na sub-rede virtual
para criptografar os pacotes. O DTLS protege contra interceptações, falsificação e
adulteração por qualquer pessoa com acesso à rede física.
A criptografia de rede virtual requer:
Certificados de criptografia instalados em cada um dos hosts Hyper-V habilitados

para SDN.
Um objeto de credencial no Controlador de Rede fazendo referência à impressão
digital desse certificado.
A configuração em cada uma das Redes Virtuais contém sub-redes que exigem
criptografia.
Depois de habilitar a criptografia em uma sub-rede, todo o tráfego de rede dentro

dessa sub-rede será criptografado automaticamente, além de qualquer criptografia no
nível do aplicativo que também possa ocorrer. O tráfego que cruza entre sub-redes,
mesmo que marcado como criptografado, é enviado descriptografado
automaticamente. Qualquer tráfego que cruza o limite da rede virtual também é
enviado sem criptografia.
７ Observação
Ao se comunicar com outra VM na mesma sub-rede, seja ela conectada ou

conectada posteriormente, o tráfego é criptografado automaticamente.
 Dica
Se você precisar restringir os aplicativos para se comunicar apenas na sub-rede

criptografada, poderá usar Controle de Acesso Listas (ACLs) apenas para permitir a
comunicação dentro da sub-rede atual. Para obter mais informações, consulte Use
Controle de Acesso Lists (ACLs) to Manage Datacenter Network Traffic Flow.
Etapa 1. Criar o certificado de criptografia

Cada host deve ter um certificado de criptografia instalado. Você pode usar o mesmo
certificado para todos os locatários ou gerar um exclusivo para cada locatário.
1. Gerar o certificado
$subjectName = "EncryptedVirtualNetworks"
$cryptographicProviderName = "Microsoft Base Cryptographic Provider

v1.0";
[int] $privateKeyLength = 1024;
$sslServerOidString = "1.3.6.1.5.5.7.3.1";
$sslClientOidString = "1.3.6.1.5.5.7.3.2";
[int] $validityPeriodInYear = 5;
$name = new-object -com "X509Enrollment.CX500DistinguishedName.1"
$name.Encode("CN=" + $SubjectName, 0)
#Generate Key
$key = new-object -com "X509Enrollment.CX509PrivateKey.1"
$key.ProviderName = $cryptographicProviderName
$key.KeySpec = 1 #X509KeySpec.XCN_AT_KEYEXCHANGE
$key.Length = $privateKeyLength
$key.MachineContext = 1
$key.ExportPolicy = 0x2
#X509PrivateKeyExportFlags.XCN_NCRYPT_ALLOW_EXPORT_FLAG
$key.Create()
#Configure Eku
$serverauthoid = new-object -com "X509Enrollment.CObjectId.1"
$serverauthoid.InitializeFromValue($sslServerOidString)
$clientauthoid = new-object -com "X509Enrollment.CObjectId.1"
$clientauthoid.InitializeFromValue($sslClientOidString)
$ekuoids = new-object -com "X509Enrollment.CObjectIds.1"
$ekuoids.add($serverauthoid)
$ekuoids.add($clientauthoid)
$ekuext = new-object -com

"X509Enrollment.CX509ExtensionEnhancedKeyUsage.1"
$ekuext.InitializeEncode($ekuoids)
# Set the hash algorithm to sha512 instead of the default sha1
$hashAlgorithmObject = New-Object -ComObject X509Enrollment.CObjectId
$hashAlgorithmObject.InitializeFromAlgorithmName(
$ObjectIdGroupId.XCN_CRYPT_HASH_ALG_OID_GROUP_ID,
$ObjectIdPublicKeyFlags.XCN_CRYPT_OID_INFO_PUBKEY_ANY,
$AlgorithmFlags.AlgorithmFlagsNone, "SHA512")
#Request Certificate
$cert = new-object -com

"X509Enrollment.CX509CertificateRequestCertificate.1"
$cert.InitializeFromPrivateKey(2, $key, "")
$cert.Subject = $name
$cert.Issuer = $cert.Subject
$cert.NotBefore = (get-date).ToUniversalTime()
$cert.NotAfter = $cert.NotBefore.AddYears($validityPeriodInYear);
$cert.X509Extensions.Add($ekuext)
$cert.HashAlgorithm = $hashAlgorithmObject
$cert.Encode()
$enrollment = new-object -com "X509Enrollment.CX509Enrollment.1"
$enrollment.InitializeFromRequest($cert)
$certdata = $enrollment.CreateRequest(0)
$enrollment.InstallResponse(2, $certdata, 0, "")
Depois de executar o script, um novo certificado aparece no Meu repositório:
PS D:\> dir cert:\\localmachine\my
PSParentPath:
Microsoft.PowerShell.Security\Certificate::localmachine\my
Thumbprint Subject
---------- -------
84857CBBE7A1C851A80AE22391EB2C39BF820CE7 CN=MyNetwork
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks
2. Exporte o certificado para um arquivo.
Você precisa de duas cópias do certificado, uma com a chave privada e outra sem.
$subjectName = "EncryptedVirtualNetworks"
$cert = Get-ChildItem cert:\localmachine\my | ? {$_.Subject -eq

"CN=$subjectName"}
[System.io.file]::WriteAllBytes("c:\$subjectName.pfx",
$cert.Export("PFX", "secret"))
Export-Certificate -Type CERT -FilePath "c:\$subjectName.cer" -cert

$cert
3. Instalar os certificados em cada um dos hosts hyper-v

PS C:\> dir c:\$subjectname.*
Directory: C:\
---- ------------- ------ ----
-a---- 9/22/2017 4:54 PM 543

EncryptedVirtualNetworks.cer
-a---- 9/22/2017 4:54 PM 1706

EncryptedVirtualNetworks.pfx
4. Instalação em um host Hyper-V
$server = "Server01"
$subjectname = "EncryptedVirtualNetworks"
copy c:\$SubjectName.* \\$server\c$
invoke-command -computername $server -ArgumentList

$subjectname,"secret" {
param (
[string] $SubjectName,
[string] $Secret
$certFullPath = "c:\$SubjectName.cer"
# create a representation of the certificate file
$certificate = new-object
System.Security.Cryptography.X509Certificates.X509Certificate2
$certificate.import($certFullPath)
# import into the store
$store = new-object
System.Security.Cryptography.X509Certificates.X509Store("Root",
"LocalMachine")
$store.open("MaxAllowed")
$store.add($certificate)
$store.close()
$certFullPath = "c:\$SubjectName.pfx"
$certificate = new-object
System.Security.Cryptography.X509Certificates.X509Certificate2
$certificate.import($certFullPath, $Secret,
"MachineKeySet,PersistKeySet")
# import into the store
$store = new-object
System.Security.Cryptography.X509Certificates.X509Store("My",
"LocalMachine")
$store.open("MaxAllowed")
$store.add($certificate)
$store.close()
# Important: Remove the certificate files when finished
remove-item C:\$SubjectName.cer
remove-item C:\$SubjectName.pfx
5. Repita para cada servidor em seu ambiente.
Depois de repetir para cada servidor, você deve ter um certificado instalado na raiz
e no meu repositório de cada host Hyper-V.
6. Verifique a instalação do certificado.
Verifique os certificados verificando o conteúdo dos repositórios de certificados

My e Root:
PS C:\> enter-pssession Server1
[Server1]: PS C:\> get-childitem

cert://localmachine/my,cert://localmachine/root | ? {$_.Subject -eq
"CN=EncryptedVirtualNetworks"}
PSParentPath:
Microsoft.PowerShell.Security\Certificate::localmachine\my
Thumbprint Subject
---------- -------
PSParentPath:
Microsoft.PowerShell.Security\Certificate::localmachine\root
Thumbprint Subject
---------- -------
7. Anote a impressão digital.
Você deve anotar a impressão digital porque precisa dela para criar o objeto de
credencial de certificado no controlador de rede.
Etapa 2. Criar a Credencial de Certificado

Depois de instalar o certificado em cada um dos hosts Hyper-V conectados ao
controlador de rede, agora você deve configurar o controlador de rede para usá-lo. Para
fazer isso, você deve criar um objeto de credencial contendo a impressão digital do
certificado do computador com os módulos do PowerShell do Controlador de Rede
instalados.
///Replace with the thumbprint from your certificate
$thumbprint = "5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6"
$uri = "https://nc.contoso.com"
///Replace with your Network Controller URI
Import-module networkcontroller
$credproperties = new-object
$credproperties.Type = "X509Certificate"
$credproperties.Value = $thumbprint
New-networkcontrollercredential -connectionuri $uri -resourceid

"EncryptedNetworkCertificate" -properties $credproperties -force
 Dica
Você pode reutilizar essa credencial para cada rede virtual criptografada ou
implantar e usar um certificado exclusivo para cada locatário.
Etapa 3. Configurando um Rede Virtual para

Criptografia
Esta etapa pressupõe que você já tenha criado um nome de rede virtual "Minha Rede" e
contém pelo menos uma sub-rede virtual. Para obter informações sobre como criar
redes virtuais, consulte Criar, Excluir ou Atualizar Redes Virtuais de Locatário.
７ Observação
Ao se comunicar com outra VM na mesma sub-rede, seja ela conectada ou

conectada posteriormente, o tráfego é criptografado automaticamente.
1. Recupere os objetos Rede Virtual e credenciais do controlador de rede:

$vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -
ResourceId "MyNetwork"
$certcred = Get-NetworkControllerCredential -ConnectionUri $uri -

ResourceId "EncryptedNetworkCertificate"
2. Adicione uma referência à credencial de certificado e habilite a criptografia em

sub-redes individuais:
$vnet.properties.EncryptionCredential = $certcred
# Replace the Subnets index with the value corresponding to the subnet
you want encrypted.
# Repeat for each subnet where encryption is needed
$vnet.properties.Subnets[0].properties.EncryptionEnabled = $true
3. Coloque o objeto Rede Virtual atualizado no controlador de rede:
New-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId

$vnet.ResourceId -Properties $vnet.Properties -force
Parabéns! * Você terminará depois de concluir estas etapas.

Saída de medição em uma rede virtual
Um aspecto fundamental da monetização de rede de nuvem é poder cobrar pela

utilização da largura de banda da rede. Os dados de saída são cobrados com base na
quantidade total de dados que sai do data center pela Internet em um determinado
ciclo de cobrança.
Egress medição para tráfego de rede SDN no Windows Server 2019 permite a
capacidade de oferecer medidores de uso para transferências de dados de saída. O
tráfego de rede que sai de cada rede virtual, mas permanece dentro do data center
pode ser rastreado separadamente para que possa ser excluído dos cálculos de
cobrança. Pacotes associados a endereços IP de destino que não estão incluídos em um
dos intervalos de endereços não cobrados são rastreados como transferências de dados
de saída cobradas.
Intervalos de endereços não faturados de rede

virtual (lista de permitir intervalos de IP)
Você pode encontrar intervalos de endereços não faturados na propriedade
UnbilledAddressRanges de uma rede virtual existente. Por padrão, não há intervalos de
endereços adicionados.
PowerShell
import-module NetworkController
$uri = "https://sdn.contoso.com"
(Get-NetworkControllerVirtualNetwork -ConnectionURI $URI -ResourceId

"VNet1").properties
Sua saída será semelhante a esta:
AddressSpace : Microsoft.Windows.NetworkController.AddressSpace
DhcpOptions :
UnbilledAddressRanges :
ConfigurationState :
ProvisioningState : Succeeded
Subnets : {21e71701-9f59-4ee5-b798-2a9d8c2762f0, 5f4758ef-

9f96-40ca-a389-35c414e996cc,
29fe67b8-6f7b-486c-973b-8b9b987ec8b3}
VirtualNetworkPeerings :
EncryptionCredential :
LogicalNetwork : Microsoft.Windows.NetworkController.LogicalNetwork
Exemplo: Gerenciar os intervalos de endereços

não faturados de uma rede virtual
Você pode gerenciar o conjunto de prefixos de sub-rede IP a ser excluído da medição
de saída cobrada definindo a propriedade UnbilledAddressRange de uma rede virtual.
Qualquer tráfego enviado por interfaces de rede na rede virtual com um endereço IP de
destino que corresponde a um dos prefixos não será incluído na propriedade
BilledEgressBytes.
1. Atualize a propriedade UnbilledAddressRanges para conter as sub-redes que não

serão cobradas pelo acesso.
PowerShell

ResourceID "VNet1"
$vnet.Properties.UnbilledAddressRanges = "10.10.2.0/24,10.10.3.0/24"
 Dica
Se você adicionar várias sub-redes IP, use uma vírgula entre cada uma das
sub-redes IP. Não inclua espaços antes ou depois da vírgula.
2. Atualize o recurso de Rede Virtual com a propriedade UnbilledAddressRanges

modificada .
PowerShell
New-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId

"VNet1" -Properties $unbilled.Properties -PassInnerException

Confirm
Performing the operation 'New-NetworkControllerVirtualNetwork' on

entities of type
'Microsoft.Windows.NetworkController.VirtualNetwork' via
'https://sdn.contoso.com/networking/v3/virtualNetworks/VNet1'. Are
you sure you want to continue?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
Tags :
ResourceRef : /virtualNetworks/VNet1
InstanceId : 29654b0b-9091-4bed-ab01-e172225dc02d
Etag : W/"6970d0a3-3444-41d7-bbe4-36327968d853"
ResourceMetadata :
ResourceId : VNet1
Properties :
3. Verifique a Rede Virtual para ver o UnbilledAddressRanges configurado.
PowerShell
(Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceID

"VNet1").properties
Sua saída agora será semelhante a esta:
AddressSpace :
DhcpOptions :
UnbilledAddressRanges : 10.10.2.0/24,192.168.2.0/24
Subnets : {21e71701-9f59-4ee5-b798-2a9d8c2762f0,
5f4758ef-9f96-40ca-a389-35c414e996cc,
29fe67b8-6f7b-486c-973b-8b9b987ec8b3}
VirtualNetworkPeerings :
EncryptionCredential :
LogicalNetwork :
Microsoft.Windows.NetworkController.LogicalNetwork
Verificar o uso de saída não cobrado de uma

rede virtual
Depois de configurar a propriedade UnbilledAddressRanges , você pode verificar o uso
de saída cobrado e não cobrado de cada sub-rede em uma rede virtual. Egress o
tráfego é atualizado a cada quatro minutos com o total de bytes dos intervalos
cobrados e não cobrados.
As seguintes propriedades estão disponíveis para cada sub-rede virtual:
UnbilledEgressBytes mostra o número de bytes não faturados enviados por

interfaces de rede conectadas a essa sub-rede virtual. Bytes não faturados são
bytes enviados para intervalos de endereços que fazem parte da propriedade
UnbilledAddressRanges da rede virtual pai.
BilledEgressBytes mostra o Número de bytes cobrados enviados por interfaces de

rede conectadas a essa sub-rede virtual. Bytes cobrados são bytes enviados para
intervalos de endereços que não fazem parte da propriedade
UnbilledAddressRanges da rede virtual pai.
Use o exemplo a seguir para consultar o uso de saída:
PowerShell
(Get-NetworkControllerVirtualNetwork -ConnectionURI $URI -ResourceId

"VNet1").properties.subnets.properties | ft
AddressPrefix,BilledEgressBytes,UnbilledEgressBytes
AddressPrefix BilledEgressBytes UnbilledEgressBytes
------------- ----------------- -------------------
10.0.255.8/29 16827067 0
10.0.2.0/24 781733019 0
10.0.4.0/24 0 0
Gerenciar cargas de trabalho de

locatário
Este tópico contém links para a documentação que permite gerenciar cargas de
trabalho de locatário adicionando VMs (máquinas virtuais de locatário), usando soluções
de virtualização de rede, configurando o balanceamento de carga de software e muito
mais.
Esta seção inclui os seguintes tópicos.
Criar uma VM e Conexão uma rede virtual de locatário ou VLAN

Configurar qualidade de serviço (QoS) para um adaptador de rede de VM do
locatário
Configurar as listas de controle de acesso (ACLs) do firewall do datacenter
Configurar o software Load Balancer para nat (conversão de endereços de rede) e
balanceamento de carga
Usar dispositivos de virtualização de rede em uma rede virtual
Clustering de convidado em uma rede virtual
Criar uma máquina virtual e se conectar
a uma rede virtual de locatário ou VLAN
Neste tópico, você criará uma VM de locatário e a conectará a uma rede virtual criada
com a Virtualização de Rede Hyper-V ou a uma VLAN (Rede de Área Local Virtual). Você
pode usar Windows PowerShell cmdlets do Controlador de Rede para se conectar a uma
rede virtual ou NetworkControllerRESTWrappers para se conectar a uma VLAN.
Use os processos descritos neste tópico para implantar dispositivos virtuais. Com
algumas etapas adicionais, você pode configurar dispositivos para processar ou
inspecionar pacotes de dados que fluem de ou para outras VMs no Rede Virtual.
As seções neste tópico incluem comandos de exemplo Windows PowerShell que

contêm valores de exemplo para muitos parâmetros. Substitua os valores de exemplo
nesses comandos por valores apropriados para sua implantação antes de executar esses
comandos.
Pré-requisitos
1. Adaptadores de rede de VM criados com endereços MAC estáticos para o tempo
de vida da VM.
Se o endereço MAC for alterado durante o tempo de vida da VM, o Controlador de

Rede não poderá configurar a política necessária para o adaptador de rede. Não
configurar a política para a rede impede que o adaptador de rede processe o
tráfego de rede e toda a comunicação com a rede falha.
2. Se a VM exigir acesso à rede na inicialização, não inicie a VM até depois de definir

a ID da interface na porta do adaptador de rede da VM. Se você iniciar a VM antes
de definir a ID da interface e a interface de rede não existir, a VM não poderá se
comunicar na rede no Controlador de Rede e todas as políticas aplicadas.
3. Se você precisar de ACLs personalizadas para essa interface de rede, crie a ACL
agora usando instruções no tópico Usar ACLs (Listas de Controle de Acesso) para
gerenciar o tráfego de rede do Datacenter Flow
Verifique se você já criou uma Rede Virtual antes de usar este comando de exemplo.
Para obter mais informações, consulte Criar, excluir ou atualizar redes virtuais de
locatário.
Criar uma VM e conectar-se a uma Rede Virtual

usando os cmdlets do controlador de rede
Windows PowerShell
1. Crie uma VM com um adaptador de rede de VM que tenha um endereço MAC
estático.
PowerShell
New-VM -Generation 2 -Name "MyVM" -Path "C:\VMs\MyVM" -

MemoryStartupBytes 4GB -VHDPath "C:\VMs\MyVM\Virtual Hard
Disks\WindowsServer2016.vhdx" -SwitchName "SDNvSwitch"
Set-VM -Name "MyVM" -ProcessorCount 4
Set-VMNetworkAdapter -VMName "MyVM" -StaticMacAddress "00-11-22-33-44-

55"
2. Obtenha a rede virtual que contém a sub-rede à qual você deseja conectar o
adaptador de rede.
Powershell

ResourceId "Contoso_WebTier"
3. Crie um objeto de interface de rede no Controlador de Rede.
 Dica
Nesta etapa, você usará a ACL personalizada.
PowerShell
$vmnicproperties = New-Object
Microsoft.Windows.NetworkController.NetworkInterfaceProperties
$vmnicproperties.PrivateMacAddress = "001122334455"
$vmnicproperties.PrivateMacAllocationMethod = "Static"
$vmnicproperties.IsPrimary = $true
$vmnicproperties.DnsSettings = New-Object
Microsoft.Windows.NetworkController.NetworkInterfaceDnsSettings
$vmnicproperties.DnsSettings.DnsServers = @("24.30.1.11", "24.30.1.12")
$ipconfiguration = New-Object
$ipconfiguration.resourceid = "MyVM_IP1"
$ipconfiguration.properties = New-Object
Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationProp
erties
$ipconfiguration.properties.PrivateIPAddress = "24.30.1.101"
$ipconfiguration.properties.PrivateIPAllocationMethod = "Static"
$ipconfiguration.properties.Subnet = New-Object
Microsoft.Windows.NetworkController.Subnet
$ipconfiguration.properties.subnet.ResourceRef =
$vnet.Properties.Subnets[0].ResourceRef
$vmnicproperties.IpConfigurations = @($ipconfiguration)
New-NetworkControllerNetworkInterface –ResourceID "MyVM_Ethernet1" –

Properties $vmnicproperties –ConnectionUri $uri
4. Obtenha a InstanceId para a interface de rede do Controlador de Rede.
PowerShell
$nic = Get-NetworkControllerNetworkInterface -ConnectionUri $uri -

5. Defina a ID da interface na porta do adaptador de rede da VM do Hyper-V.
７ Observação
Você deve executar esses comandos no host Hyper-V em que a VM está

instalada.
PowerShell
#Do not change the hardcoded IDs in this section, because they are
fixed values and must not change.
$FeatureId = "9940cd46-8b06-43bb-b9d5-93d50381fd56"
$vmNics = Get-VMNetworkAdapter -VMName "MyVM"
$CurrentFeature = Get-VMSwitchExtensionPortFeature -FeatureId

$FeatureId -VMNetworkAdapter $vmNics
if ($CurrentFeature -eq $null) {
$Feature = Get-VMSystemSwitchExtensionPortFeature -FeatureId

$FeatureId
$Feature.SettingData.ProfileId = "{$($nic.InstanceId)}"
$Feature.SettingData.NetCfgInstanceId = "{56785678-a0e5-4a26-bc9b-
c0cba27311a3}"
$Feature.SettingData.CdnLabelString = "TestCdn"
$Feature.SettingData.CdnLabelId = 1111
$Feature.SettingData.ProfileName = "Testprofile"
$Feature.SettingData.VendorId = "{1FA41B39-B444-4E43-B35A-
E1F7985FD548}"
$Feature.SettingData.VendorName = "NetworkController"
$Feature.SettingData.ProfileData = 1
Add-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature
$Feature -VMNetworkAdapter $vmNics
} else {
$CurrentFeature.SettingData.ProfileId = "{$($nic.InstanceId)}"
$CurrentFeature.SettingData.ProfileData = 1
Set-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature
$CurrentFeature -VMNetworkAdapter $vmNics
6. Inicie a VM.
PowerShell
Get-VM -Name "MyVM" | Start-VM
Você criou uma VM com êxito, conectou a VM a um locatário Rede Virtual e iniciou a
VM para que ela possa processar cargas de trabalho de locatário.
Criar uma VM e conectar-se a uma VLAN

usando NetworkControllerRESTWrappers
1. Crie a VM e atribua um endereço MAC estático à VM.
PowerShell
New-VM -Generation 2 -Name "MyVM" -Path "C:\VMs\MyVM" -

MemoryStartupBytes 4GB -VHDPath "C:\VMs\MyVM\Virtual Hard
Disks\WindowsServer2016.vhdx" -SwitchName "SDNvSwitch"
Set-VM -Name "MyVM" -ProcessorCount 4
Set-VMNetworkAdapter -VMName "MyVM" -StaticMacAddress "00-11-22-33-44-

55"
2. Defina a ID da VLAN no adaptador de rede da VM.
PowerShell
Set-VMNetworkAdapterIsolation –VMName "MyVM" -AllowUntaggedTraffic

$true -IsolationMode VLAN -DefaultIsolationId 123
3. Obtenha a sub-rede de rede lógica e crie o adaptador de rede.
PowerShell
$logicalnet = Get-NetworkControllerLogicalNetwork -ConnectionUri $uri

-ResourceId "00000000-2222-1111-9999-000000000002"
$vmnicproperties = New-Object
Microsoft.Windows.NetworkController.NetworkInterfaceProperties
$vmnicproperties.PrivateMacAddress = "00-1D-C8-B7-01-02"
$vmnicproperties.PrivateMacAllocationMethod = "Static"
$vmnicproperties.IsPrimary = $true
$vmnicproperties.DnsSettings = New-Object
Microsoft.Windows.NetworkController.NetworkInterfaceDnsSettings
$vmnicproperties.DnsSettings.DnsServers =
$logicalnet.Properties.Subnets[0].DNSServers
$ipconfiguration = New-Object
$ipconfiguration.resourceid = "MyVM_Ip1"
$ipconfiguration.properties = New-Object
Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationProp
erties
$ipconfiguration.properties.PrivateIPAddress = "10.127.132.177"
$ipconfiguration.properties.PrivateIPAllocationMethod = "Static"
$ipconfiguration.properties.Subnet = New-Object
$ipconfiguration.properties.subnet.ResourceRef =
$logicalnet.Properties.Subnets[0].ResourceRef
$vmnicproperties.IpConfigurations = @($ipconfiguration)
$vnic = New-NetworkControllerNetworkInterface –ResourceID

"MyVM_Ethernet1" –Properties $vmnicproperties –ConnectionUri $uri
$vnic.InstanceId
4. Defina a InstanceId na porta do Hyper-V.
PowerShell
#The hardcoded Ids in this section are fixed values and must not
change.
$FeatureId = "9940cd46-8b06-43bb-b9d5-93d50381fd56"
$vmNics = Get-VMNetworkAdapter -VMName "MyVM"
$CurrentFeature = Get-VMSwitchExtensionPortFeature -FeatureId

$FeatureId -VMNetworkAdapter $vmNics
if ($CurrentFeature -eq $null) {
$Feature = Get-VMSystemSwitchExtensionFeature -FeatureId $FeatureId
$Feature.SettingData.ProfileId = "{$InstanceId}"
$Feature.SettingData.NetCfgInstanceId = "{56785678-a0e5-4a26-bc9b-
c0cba27311a3}"
$Feature.SettingData.CdnLabelString = "TestCdn"
$Feature.SettingData.CdnLabelId = 1111
$Feature.SettingData.ProfileName = "Testprofile"
$Feature.SettingData.VendorId = "{1FA41B39-B444-4E43-B35A-
E1F7985FD548}"
$Feature.SettingData.VendorName = "NetworkController"
$Feature.SettingData.ProfileData = 1
Add-VMSwitchExtensionFeature -VMSwitchExtensionFeature $Feature -

VMNetworkAdapter $vmNics
} else {
$CurrentFeature.SettingData.ProfileId = "{$InstanceId}"
$CurrentFeature.SettingData.ProfileData = 1
Set-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature
$CurrentFeature -VMNetworkAdapter $vmNics
5. Inicie a VM.
PowerShell
Get-VM -Name "MyVM" | Start-VM
Você criou uma VM com êxito, conectou a VM a uma VLAN e iniciou a VM para que ela
possa processar cargas de trabalho de locatário.
Configurar a QoS (qualidade de serviço)
para um adaptador de rede de VM
Você pode configurar a qualidade de serviço (rede definida pelo software) (QoS) para
um adaptador de rede de máquina virtual (VM) para limitar a largura de banda em uma
interface virtual a fim de impedir que uma VM de tráfego intenso contenha outro
tráfego de rede VM. Você também pode configurar o QoS de SDN para reservar uma
quantidade específica de largura de banda para uma VM a fim de garantir que a VM
possa enviar tráfego independentemente de outro tráfego na rede. Isso pode ser
aplicado às VMs conectadas às redes de VLAN tradicionais, bem como às VMs
conectadas a redes de sobreposição de SDN.
Você também pode configurar o descarregamento de QoS para impor regras de QoS no
adaptador de rede física em vez de no comutador virtual, resultando em menor
utilização da CPU e imposição aprimorada. o descarregamento de QoS é um recurso
opcional encontrado em NICs certificadas do Windows server 2022 que alcançaram o
Windows servidor Software-Defined data Center (SDDC) Premium qualificação adicional
(AQ). Para obter mais informações, consulte selecionar um adaptador de rede.
Limites de largura de banda de QoS de SDN

A QoS de SDN fornece a configuração do máximo permitido de largura de banda ou do
lado de recebimento para VMs. Isso tem suporte para VMs conectadas a uma rede
VLAN tradicional, bem como VMs conectadas a uma rede virtual SDN. Depois de
definido, sua VM não poderá enviar ou receber tráfego acima dos limites máximos
configurados. Para uma VM, você pode optar por configurar um limite no lado do envio,
um limite no lado do recebimento ou ambos.
As configurações que podem ser configuradas por meio de QoS de SDN são:
OutboundReservedValue – se o modo for "Absolute", o valor indicará a largura de

banda, em Mbps, garantida para a porta virtual para transmissão (Egresso). Se
outboundReservedMode Mode for "Weight", o valor indicará a parte ponderada da
largura de banda garantida.

OutboundMaximumMbps -indica o máximo permitido de largura de banda do
lado do envio, em Mbps, para a porta virtual (Egresso).
InboundMaximumMbps -indica o máximo permitido de largura de banda do lado

de recebimento para a porta virtual (entrada) em Mbps.
Políticas de QoS de SDN

Depois que o controlador de rede para SDN é configurado, você pode prosseguir e
implantar suas políticas de QoS. Hoje, você pode fazer isso usando os cmdlets do
PowerShell do controlador de rede .
Para todos os scripts de exemplo usados abaixo, -ConnectionUri é o URI REST do

controlador de rede. Por exemplo: https://nc.contoso.com .
Etapa 1: definir configurações de QoS globais

Execute o seguinte comando do PowerShell em um computador do controlador de rede
ou um cliente de gerenciamento do controlador de rede. Isso permitirá que as
configurações globais configurem políticas de QoS por meio do controlador de rede:
PowerShell
$vswitchConfig=
[Microsoft.Windows.NetworkController.VirtualSwitchManagerProperties]::new()
$qos=[Microsoft.Windows.NetworkController.VirtualSwitchQosSettings]::new()
$qos.EnableSoftwareReservations=$true
$vswitchConfig.QosSettings =$qos
Set-NetworkControllerVirtualSwitchConfiguration -ConnectionUri $uri -

Properties $vswitchConfig
Etapa 2: configurar políticas de QoS

Primeiro, você precisará identificar a interface de rede da VM de carga de trabalho em
que deseja aplicar a política:
PowerShell
$NwInterface=Get-NetworkControllerNetworkInterface -ConnectionUri $uri -

ResourceId Vnet-VM2_Net_Adapter_0
Em seguida, configure a taxa de transferência máxima de entrada e de saída permitida

na interface de rede:
PowerShell
$NwInterface.Properties.PortSettings.QosSettings=
[Microsoft.Windows.NetworkController.VirtualNetworkInterfaceQosSettings]::ne
w()
$NwInterface.Properties.PortSettings.QosSettings.InboundMaximumMbps ="1000"
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId

$NwInterface.ResourceId -Properties $NwInterface.Properties
Descarregamento de QoS (opcional)

Você pode configurar a NIC física para usar o descarregamento de QoS. Se o adaptador
oferecer suporte ao descarregamento de QoS, verifique se ele está habilitado usando
um dos dois métodos:
ATC de rede (recomendado)

Habilitação manual usando as propriedades do adaptador
Usar ATC de rede

O descarregamento de QoS é habilitado automaticamente em todos os adaptadores
com o tipo de Compute tentativa. Para obter mais informações, consulte simplificar a
rede do host com a rede ATC.
７ Observação
Essa opção só está disponível para Azure Stack assinantes do HCI.
Usar habilitação manual

A habilitação manual é feita por meio dos cmdlets internos usados para gerenciar as
propriedades do adaptador físico.
） Importante
Você deve garantir que QosOffload o esteja habilitado em cada NIC física da
equipe em todos os hosts. Sem isso, a regra de QoS será imposta por meio do
comutador virtual e resultará em menor eficiência.
Use os seguintes cmdlets para verificar se os adaptadores dão suporte QosOffload e, em
seguida, modifique as propriedades do adaptador:
PowerShell
Get-NetAdapterAdvancedProperty -Name <physical NIC Name> -RegistryKeyword

*QosOffload
Enable QosOffload for your adapters:
Set-NetAdapterAdvancedProperty -Name <physical NIC Name> -RegistryKeyword

*QosOffload -RegistryValue 1
Configurar QoS de hardware

Você pode configurar a QoS de hardware usando configurações e políticas.
Etapa 1 – definir configurações de QoS globais

Execute as etapas a seguir em um computador do controlador de rede ou um cliente de
gerenciamento do controlador de rede. Isso habilitará a configuração global para
configurar políticas de QoS por meio do controlador de rede.
PowerShell
$vswitchConfig=
[Microsoft.Windows.NetworkController.VirtualSwitchManagerProperties]::new()
$qos=[Microsoft.Windows.NetworkController.VirtualSwitchQosSettings]::new()
$qos.EnableHardwareLimits=$true
$vswitchConfig.QosSettings =$qos
Set-NetworkControllerVirtualSwitchConfiguration -ConnectionUri $uri -

Properties $vswitchConfig
Etapa 2 – configurar políticas de QoS

Primeiro, identifique a interface de rede da VM de carga de trabalho na qual você deseja
aplicar a política:
PowerShell
$NwInterface=Get-NetworkControllerNetworkInterface -ConnectionUri $uri -

ResourceId Vnet-VM2_Net_Adapter_0
Em seguida, configure a taxa de transferência máxima de saída permitida na interface de

rede. O exemplo a seguir cria uma regra de QoS limitando o tráfego de saída de uma
interface de VM para 1 Gbps.
） Importante
O descarregamento de QoS dá suporte apenas a OutboundMaximumMbps. Você

não pode usar OutboundReservedValue ou InboundMaximumMbps com
descarregamento de QoS.
PowerShell
$NwInterface.Properties.PortSettings.QosSettings=
[Microsoft.Windows.NetworkController.VirtualNetworkInterfaceQosSettings]::ne
w()
$NwInterface.Properties.PortSettings.QosSettings. EnableHardwareLimits=$true
$NwInterface.Properties.PortSettings.QosSettings.OutboundMaximumMbps ="1000"

$NwInterface.ResourceId -Properties $NwInterface.Properties
７ Observação
Durante a migração ao vivo, é possível que uma VM passe para um host que não
dá suporte ao descarregamento de QoS. Nesse cenário, a migração ao vivo terá
sucesso, mas a QoS fará fallback para o QoS de SDN.
com o PowerShell



PowerShell
PowerShell

７ Observação


de de
origem destino
PowerShell
$aclrules = @()



rede virtual.
 Dica


segurança de rede.
PowerShell


de rede.
PowerShell


adaptador de rede.
PowerShell
$acl
PowerShell


rede.
PowerShell

PowerShell
$null
PowerShell

PowerShell
param(
$Path
mkdir $path -force


syntax
---- ------------- ------ ----
-a---- 7/19/2018 6:28 AM 17055

1bf2f0e0dc4a.20180719TL122803093.json
-a---- 7/19/2018 7:28 AM 7880

1bf2f0e0dc4a.20180719TL132803173.json
-a---- 7/19/2018 8:28 AM 7867

1bf2f0e0dc4a.20180719TL142803264.json
-a---- 7/19/2018 9:28 AM 10949

1bf2f0e0dc4a.20180719TL152803360.json
-a---- 7/19/2018 9:28 AM 0

1bf2f0e0dc4a.20180719TL162803464.json
syntax
"records": [
"properties":{
"Version":"1.0",
"flows":[
"flows":[
{
"flowTuples":
["1531963580,192.122.0.22,192.122.255.255,138,138,U,I,A"],
"portId":"9",
"portName":"7290436D-0422-498A-8EB8-
C6CF5115DACE"
],
},
"time":"20180719:L012620622",
},
syntax
{
"Tags": null,
"Properties": {
"AclRules": [
"ResourceRef":
422b-9038-d1f2390645d7",
"Etag": "W/\"1535a780-0fc8-
"ResourceId":
"AllowAll_Inbound",
"Properties": {
"Protocol":
"All",
"Action":
"Allow",
"Priority":
"101",
"Type":
"Inbound",
"Logging":
"Enabled",
}
},
"ResourceRef":
"InstanceId": "068264c6-2186-
"Etag": "W/\"1535a780-0fc8-
"ResourceId":
"Properties": {
"Protocol":
"All",
"Action":
"Allow",
"Priority":
"110",
"Type":
"Outbound",
"Logging":
"Enabled",
}
],
],
"Subnets": [
"ResourceRef":
"InstanceId": "00000000-0000-
0000-0000-000000000000",
"Etag": null,
"ResourceId": null,
"Properties": null
Próximas etapas

Configurar o balanceador de carga de
software para balanceamento de carga e
Conversão de endereços de rede (NAT)
Você pode usar este tópico para aprender a usar o SLB (balanceador de carga de
software) SDN (Software Defined Networking) para fornecer NAT (conversão de
endereço de rede de saída), NAT de entrada ou balanceamento de carga entre várias
instâncias de um aplicativo.
Visão geral do software Load Balancer

O SLB (SDN Software Load Balancer) oferece alta disponibilidade e desempenho de rede
para seus aplicativos. É um balanceador de carga de Camada 4 (TCP, UDP) que distribui
o tráfego de entrada entre instâncias de serviço íntegro em serviços de nuvem ou
máquinas virtuais definidas em um conjunto de balanceadores de carga.
Configure o SLB para fazer o seguinte:
Balancear o tráfego de entrada de carga externo a uma rede virtual para VMs
(máquinas virtuais), também chamado de balanceamento de carga VIP público.
Balancear a carga do tráfego de entrada entre VMs em uma rede virtual, entre VMs
em serviços de nuvem ou entre computadores locais e VMs em uma rede virtual
entre locais.
Encaminhe o tráfego de rede de VM da rede virtual para destinos externos usando
a NAT (conversão de endereço de rede), também chamada NAT de saída.
Encaminhe o tráfego externo para uma VM específica, também chamada NAT de
entrada.
Exemplo: criar um VIP público para

balanceamento de carga de um pool de duas
VMs em uma rede virtual
Neste exemplo, você cria um objeto de balanceador de carga com um VIP público e
duas VMs como membros do pool para atender a solicitações para o VIP. Este código
de exemplo também adiciona uma investigação de integridade HTTP para detectar se
um dos membros do pool se torna não responsivo.
1. Prepare o objeto do balanceador de carga.
PowerShell
$URI = "https://sdn.contoso.com"
$LBResourceId = "LB2"
$LoadBalancerProperties = new-object
Microsoft.Windows.NetworkController.LoadBalancerProperties
2. Atribua um endereço IP de front-end, normalmente conhecido como UM IP Virtual

(VIP).
O VIP deve ser de um IP não utilizado em um dos pools de IP de rede lógica dados
ao gerenciador do balanceador de carga.
PowerShell
$VIPIP = "10.127.134.5"
$VIPLogicalNetwork = get-networkcontrollerlogicalnetwork -
ConnectionUri $uri -resourceid "PublicVIP" -PassInnerException
$FrontEndIPConfig = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfiguration
$FrontEndIPConfig.ResourceId = "FE1"
$FrontEndIPConfig.ResourceRef =
"/loadBalancers/$LBResourceId/frontendIPConfigurations/$($FrontEndIPCon
fig.ResourceId)"
$FrontEndIPConfig.Properties = new-object
Properties
$FrontEndIPConfig.Properties.Subnet = new-object
$FrontEndIPConfig.Properties.Subnet.ResourceRef =
$VIPLogicalNetwork.Properties.Subnets[0].ResourceRef
$FrontEndIPConfig.Properties.PrivateIPAddress = $VIPIP
$FrontEndIPConfig.Properties.PrivateIPAllocationMethod = "Static"
$LoadBalancerProperties.FrontEndIPConfigurations += $FrontEndIPConfig
3. Aloque um pool de endereços de back-end, que contém os DIPs (IPs Dinâmicos)

que compõem os membros do conjunto de VMs com balanceamento de carga.
PowerShell
$BackEndAddressPool = new-object
Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPool
$BackEndAddressPool.ResourceId = "BE1"
$BackEndAddressPool.ResourceRef =
"/loadBalancers/$LBResourceId/backendAddressPools/$($BackEndAddressPool
.ResourceId)"
$BackEndAddressPool.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPoolPrope
rties
$LoadBalancerProperties.backendAddressPools += $BackEndAddressPool
4. Defina uma investigação de integridade que o balanceador de carga usa para

determinar o estado de integridade dos membros do pool de back-end.
Neste exemplo, você define uma investigação HTTP que consulta o RequestPath
de "/health.htm". A consulta é executada a cada 5 segundos, conforme
especificado pela propriedade IntervalInSeconds.
A investigação de integridade deve receber um código de resposta HTTP de 200

para 11 consultas consecutivas para que a investigação considere o IP de back-end
íntegro. Se o IP de back-end não estiver íntegro, ele não receberá tráfego do
balanceador de carga.
） Importante
Não bloqueie o tráfego de ou para o primeiro IP na sub-rede para quaisquer

ACLs (Listas de Controle de Acesso) que você aplique ao IP de back-end
porque esse é o ponto de origem para as investigações.
Use o exemplo a seguir para definir uma investigação de integridade.
PowerShell
$Probe = new-object
Microsoft.Windows.NetworkController.LoadBalancerProbe
$Probe.ResourceId = "Probe1"
$Probe.ResourceRef =
"/loadBalancers/$LBResourceId/Probes/$($Probe.ResourceId)"
$Probe.properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerProbeProperties
$Probe.properties.Protocol = "HTTP"
$Probe.properties.Port = "80"
$Probe.properties.RequestPath = "/health.htm"
$Probe.properties.IntervalInSeconds = 5
$Probe.properties.NumberOfProbes = 11
$LoadBalancerProperties.Probes += $Probe
5. Defina uma regra de balanceamento de carga para enviar o tráfego que chega ao
IP front-end para o IP de back-end. Neste exemplo, o pool de back-end recebe o
tráfego TCP para a porta 80.
Use o exemplo a seguir para definir uma regra de balanceamento de carga:
PowerShell
$Rule = new-object
Microsoft.Windows.NetworkController.LoadBalancingRule
$Rule.ResourceId = "webserver1"
$Rule.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancingRuleProperties
$Rule.Properties.FrontEndIPConfigurations += $FrontEndIPConfig
$Rule.Properties.backendaddresspool = $BackEndAddressPool
$Rule.Properties.protocol = "TCP"
$Rule.Properties.FrontEndPort = 80
$Rule.Properties.BackEndPort = 80
$Rule.Properties.IdleTimeoutInMinutes = 4
$Rule.Properties.Probe = $Probe
$LoadBalancerProperties.loadbalancingRules += $Rule
6. Adicione a configuração do balanceador de carga ao Controlador de Rede.
Use o exemplo a seguir para adicionar a configuração do balanceador de carga ao

Controlador de Rede:
PowerShell
$LoadBalancerResource = New-NetworkControllerLoadBalancer -
ConnectionUri $URI -ResourceId $LBResourceId -Properties
$LoadBalancerProperties -Force -PassInnerException
7. Siga o próximo exemplo para adicionar as interfaces de rede a esse pool de back-
end.
Exemplo: usar o SLB para NAT de saída
Neste exemplo, você configura o SLB com um pool de back-end para fornecer
funcionalidade nat de saída para uma VM no espaço de endereço privado de uma rede
virtual para acessar a saída para a Internet.
1. Crie as propriedades do balanceador de carga, o IP de front-end e o pool de back-

end.
PowerShell
$URI = "https://sdn.contoso.com"
$LBResourceId = "OutboundNATMMembers"
$VIPIP = "10.127.134.6"
$VIPLogicalNetwork = get-networkcontrollerlogicalnetwork -
ConnectionUri $uri -resourceid "PublicVIP" -PassInnerException
$FrontEndIPConfig = new-object
$FrontEndIPConfig.ResourceId = "FE1"
$FrontEndIPConfig.ResourceRef =
"/loadBalancers/$LBResourceId/frontendIPConfigurations/$($FrontEndIPCon
fig.ResourceId)"
$FrontEndIPConfig.Properties = new-object
Properties
$FrontEndIPConfig.Properties.Subnet = new-object
$FrontEndIPConfig.Properties.Subnet.ResourceRef =
$VIPLogicalNetwork.Properties.Subnets[0].ResourceRef
$FrontEndIPConfig.Properties.PrivateIPAddress = $VIPIP
$FrontEndIPConfig.Properties.PrivateIPAllocationMethod = "Static"
$LoadBalancerProperties.FrontEndIPConfigurations += $FrontEndIPConfig
$BackEndAddressPool = new-object
$BackEndAddressPool.ResourceId = "BE1"
$BackEndAddressPool.ResourceRef =
"/loadBalancers/$LBResourceId/backendAddressPools/$($BackEndAddressPool
.ResourceId)"
$BackEndAddressPool.Properties = new-object
rties
$LoadBalancerProperties.backendAddressPools += $BackEndAddressPool
2. Defina a regra NAT de saída.
PowerShell
$OutboundNAT = new-object
Microsoft.Windows.NetworkController.LoadBalancerOutboundNatRule
$OutboundNAT.ResourceId = "onat1"
$OutboundNAT.properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerOutboundNatRuleProperti
es
$OutboundNAT.properties.frontendipconfigurations += $FrontEndIPConfig
$OutboundNAT.properties.backendaddresspool = $BackEndAddressPool
$OutboundNAT.properties.protocol = "ALL"
$LoadBalancerProperties.OutboundNatRules += $OutboundNAT
3. Adicione o objeto do balanceador de carga no Controlador de Rede.
PowerShell
$LoadBalancerResource = New-NetworkControllerLoadBalancer -
ConnectionUri $URI -ResourceId $LBResourceId -Properties
$LoadBalancerProperties -Force -PassInnerException
4. Siga o próximo exemplo para adicionar as interfaces de rede às quais você deseja
fornecer acesso à Internet.
Exemplo: adicionar interfaces de rede ao pool

de back-end
Neste exemplo, você adiciona interfaces de rede ao pool de back-end. Você deve repetir
essa etapa para cada interface de rede que pode processar solicitações feitas ao VIP.
Você também pode repetir esse processo em um único adaptador de rede para
adicioná-lo a vários objetos do balanceador de carga. Por exemplo, se você tiver um
objeto de balanceador de carga para um VIP do servidor Web e um objeto de
balanceador de carga separado para fornecer NAT de saída.
1. Obtenha o objeto do balanceador de carga que contém o pool de back-end para

adicionar um adaptador de rede.
PowerShell
$lbresourceid = "LB2"
$lb = get-networkcontrollerloadbalancer -connectionuri $uri -resourceID

$LBResourceId -PassInnerException
2. Obtenha a interface de rede e adicione o pool backendaddress à matriz

loadbalancerbackendaddresspools.
PowerShell
$nic = get-networkcontrollernetworkinterface -connectionuri $uri -

resourceid 6daca142-7d94-0000-1111-c38c0141be06 -PassInnerException
$nic.properties.IpConfigurations[0].properties.LoadBalancerBackendAddre
ssPools += $lb.properties.backendaddresspools[0]
3. Coloque o adaptador de rede para aplicar a alteração.
PowerShell
new-networkcontrollernetworkinterface -connectionuri $uri -resourceid

6daca142-7d94-0000-1111-c38c0141be06 -properties $nic.properties -force
-PassInnerException
Exemplo: usar o software Load Balancer para

encaminhar o tráfego
Se você precisar mapear um IP Virtual para uma única interface de rede em uma rede
virtual sem definir portas individuais, poderá criar uma regra de encaminhamento L3.
Essa regra encaminha todo o tráfego de e para a VM por meio do VIP atribuído contido
em um objeto PublicIPAddress.
Se você definiu o VIP e o DIP como a mesma sub-rede, isso equivale a executar o
encaminhamento L3 sem NAT.
７ Observação
Esse processo não exige que você crie um objeto de balanceador de carga. Atribuir
o PublicIPAddress à interface de rede é informações suficientes para o software
Load Balancer executar sua configuração.
1. Crie um objeto IP público para conter o VIP.

PowerShell
$publicIPProperties = new-object
Microsoft.Windows.NetworkController.PublicIpAddressProperties
$publicIPProperties.ipaddress = "10.127.134.7"
$publicIPProperties.PublicIPAllocationMethod = "static"
$publicIPProperties.IdleTimeoutInMinutes = 4
$publicIP = New-NetworkControllerPublicIpAddress -ResourceId "MyPIP" -

Properties $publicIPProperties -ConnectionUri $uri -Force -
PassInnerException
2. Atribua o PublicIPAddress a um adaptador de rede.
PowerShell

resourceid 6daca142-7d94-0000-1111-c38c0141be06
$nic.properties.IpConfigurations[0].Properties.PublicIPAddress =
$publicIP

$nic.ResourceId -Properties $nic.properties -PassInnerException
Exemplo: usar o software Load Balancer para

encaminhar o tráfego com um VIP alocado
dinamicamente
Este exemplo repete a mesma ação que o exemplo anterior, mas aloca
automaticamente o VIP do pool disponível de VIPs no balanceador de carga em vez de
especificar um endereço IP específico.
1. Crie um objeto IP público para conter o VIP.
PowerShell
$publicIPProperties = new-object
Microsoft.Windows.NetworkController.PublicIpAddressProperties
$publicIPProperties.PublicIPAllocationMethod = "dynamic"
$publicIPProperties.IdleTimeoutInMinutes = 4
$publicIP = New-NetworkControllerPublicIpAddress -ResourceId "MyPIP" -

Properties $publicIPProperties -ConnectionUri $uri -Force -
PassInnerException
2. Consulte o recurso PublicIPAddress para determinar qual endereço IP foi atribuído.
PowerShell
(Get-NetworkControllerPublicIpAddress -ConnectionUri $uri -ResourceId
"MyPIP").properties
A propriedade IpAddress contém o endereço atribuído. A saída parecerá com o

seguinte:
Counters : {}
IpAddress : 10.127.134.2
PublicIPAddressVersion : IPv4
PublicIPAllocationMethod : Dynamic
IdleTimeoutInMinutes : 4
DnsSettings :
IpConfiguration :
PreviousIpConfiguration :
3. Atribua o PublicIPAddress a um adaptador de rede.
PowerShell

resourceid 6daca142-7d94-0000-1111-c38c0141be06
$nic.properties.IpConfigurations[0].Properties.PublicIPAddress =
$publicIP

$nic.ResourceId -Properties $nic.properties -PassInnerException
Exemplo: remover um endereço PublicIP que

está sendo usado para encaminhar o tráfego
e devolvê-lo ao pool VIP
Este exemplo remove o recurso PublicIPAddress criado pelos exemplos anteriores.
Depois que o PublicIPAddress for removido, a referência ao PublicIPAddress será
removida automaticamente da interface de rede, o tráfego deixará de ser
encaminhado e o endereço IP será retornado ao pool vip público para reutilização.
4. Remover o PublicIP
PowerShell
Remove-NetworkControllerPublicIPAddress -ConnectionURI $uri -ResourceId
"MyPIP"
Usar dispositivos virtuais de rede em

uma rede virtual
Neste tópico, você aprenderá a implantar dispositivos virtuais de rede em redes virtuais
de locatário. Você pode adicionar dispositivos virtuais de rede a redes que executam
funções de roteamento e espelhamento de porta definidas pelo usuário.
Tipos de dispositivos virtuais de rede

Você pode usar um dos dois tipos de dispositivos virtuais:
1. Roteamento definido pelo usuário – substitui roteadores distribuídos na rede

virtual pelos recursos de roteamento do dispositivo virtual. Com o roteamento
definido pelo usuário, o dispositivo virtual é usado como um roteador entre as
sub-redes virtuais na rede virtual.
2. Espelhamento de porta – todo o tráfego de rede que está entrando ou saindo da

porta monitorada é duplicado e enviado para um dispositivo virtual para análise.
Implantando um dispositivo virtual de rede

Para implantar um dispositivo virtual de rede, primeiro você deve criar uma VM que
contenha o dispositivo e, em seguida, conectar a VM às sub-redes de rede virtual
apropriadas. Para obter mais detalhes, consulte Criar uma VM de locatário e Conexão
para um locatário Rede Virtual ou VLAN.
Alguns dispositivos exigem vários adaptadores de rede virtual. Normalmente, um

adaptador de rede dedicado ao gerenciamento do dispositivo, enquanto adaptadores
adicionais processam o tráfego. Se o dispositivo exigir vários adaptadores de rede, você
deverá criar cada interface de rede no Controlador de Rede. Você também deve atribuir
uma ID de interface em cada host para cada um dos adaptadores adicionais que estão
em sub-redes virtuais diferentes.
Depois de implantar o dispositivo virtual de rede, você pode usar o dispositivo para
roteamento definido, espelhamento de portabilidade ou ambos.
Exemplo: roteamento definido pelo usuário
Para a maioria dos ambientes, você só precisa das rotas do sistema já definidas pelo
roteador distribuído da rede virtual. No entanto, talvez seja necessário criar uma tabela
de roteamento e adicionar uma ou mais rotas em casos específicos, como:
Túnel à força para a Internet através de sua rede local.

Uso de dispositivos virtuais em seu ambiente.
Para esses cenários, você deve criar uma tabela de roteamento e adicionar rotas
definidas pelo usuário à tabela. Você pode ter várias tabelas de roteamento e associar a
mesma tabela de roteamento a uma ou mais sub-redes. Você só pode associar cada
sub-rede a uma única tabela de roteamento. Todas as VMs em uma sub-rede usam a
tabela de roteamento associada à sub-rede.
As sub-redes dependem de rotas do sistema até que uma tabela de roteamento seja
associada à sub-rede. Após a existência de uma associação, o roteamento é feito com
base na LPM (Correspondência de Prefixo Mais Longa) entre rotas definidas pelo
usuário e rotas do sistema. Se houver mais de uma rota com a mesma correspondência
LPM, a rota definida pelo usuário será selecionada primeiro antes da rota do sistema.
Procedimento:
1. Crie as propriedades da tabela de rotas, que contém todas as rotas definidas pelo
usuário.
As rotas do sistema ainda se aplicam de acordo com as regras definidas acima.
PowerShell
$routetableproperties = new-object
Microsoft.Windows.NetworkController.RouteTableProperties
2. Adicione uma rota às propriedades da tabela de roteamento.
Qualquer rota destinada à sub-rede 12.0.0.0/8 é roteada para o dispositivo virtual

em 192.168.1.10. O dispositivo deve ter um adaptador de rede virtual anexado à
rede virtual com esse IP atribuído a um adaptador de rede.
PowerShell
$route = new-object Microsoft.Windows.NetworkController.Route
$route.ResourceID = "0_0_0_0_0"
$route.properties = new-object
Microsoft.Windows.NetworkController.RouteProperties
$route.properties.AddressPrefix = "0.0.0.0/0"
$route.properties.nextHopType = "VirtualAppliance"
$route.properties.nextHopIpAddress = "192.168.1.10"
$routetableproperties.routes += $route
 Dica
Se você quiser adicionar mais rotas, repita esta etapa para cada rota que você
deseja definir.
3. Adicione a tabela de roteamento ao Controlador de Rede.
PowerShell
$routetable = New-NetworkControllerRouteTable -ConnectionUri $uri -

ResourceId "Route1" -Properties $routetableproperties
4. Aplique a tabela de roteamento à sub-rede virtual.
Quando você aplica a tabela de rotas à sub-rede virtual, a primeira sub-rede virtual
na rede Tenant1_Vnet1 usa a tabela de rotas. Você pode atribuir a tabela de rotas a
quantas sub-redes quiser na rede virtual.
PowerShell

ResourceId "Tenant1_VNet1"
$vnet.properties.subnets[0].properties.RouteTable = $routetable
new-networkcontrollervirtualnetwork -connectionuri $uri -properties

$vnet.properties -resourceId $vnet.resourceid
Assim que você aplicar a tabela de roteamento à rede virtual, o tráfego será
encaminhado para o dispositivo virtual. Você deve configurar a tabela de roteamento no
dispositivo virtual para encaminhar o tráfego, de maneira apropriada para seu ambiente.
Exemplo: espelhamento de porta

Neste exemplo, você configura o tráfego para MyVM_Ethernet1 espelhar
Appliance_Ethernet1. Presumimos que você tenha implantado duas VMs, uma como o
dispositivo e outra como a VM a ser monitorada com espelhamento.
O dispositivo deve ter uma segunda interface de rede para gerenciamento. Depois de
habilitar o espelhamento como um destino no Appliciance_Ethernet1, ele não receberá
mais o tráfego destinado à interface IP configurada lá.
Procedimento:
1. Obtenha a rede virtual na qual suas VMs estão localizadas.
PowerShell

ResourceId "Tenant1_VNet1"
2. Obtenha as interfaces de rede do Controlador de Rede para a origem e o destino

do espelhamento.
PowerShell
$dstNic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

ResourceId "Appliance_Ethernet1"
$srcNic = get-networkcontrollernetworkinterface -ConnectionUri $uri -

3. Crie um objeto serviceinsertionproperties para conter as regras de espelhamento

de porta e o elemento que representa a interface de destino.
PowerShell
$portmirror =
[Microsoft.Windows.NetworkController.ServiceInsertionProperties]::new()
$portMirror.Priority = 1
4. Crie um objeto serviceinsertionrules para conter as regras que devem ser

correspondidas para que o tráfego seja enviado para o dispositivo.
As regras definidas abaixo correspondem a todo o tráfego, tanto de entrada

quanto de saída, que representa um espelho tradicional. Você pode ajustar essas
regras se estiver interessado em espelhar uma porta específica ou em
destinos/fontes específicos.
PowerShell
$portmirror.ServiceInsertionRules =
[Microsoft.Windows.NetworkController.ServiceInsertionRule[]]::new(1)
$portmirror.ServiceInsertionRules[0] =
[Microsoft.Windows.NetworkController.ServiceInsertionRule]::new()
$portmirror.ServiceInsertionRules[0].ResourceId = "Rule1"
$portmirror.ServiceInsertionRules[0].Properties =
[Microsoft.Windows.NetworkController.ServiceInsertionRuleProperties]::n
ew()
$portmirror.ServiceInsertionRules[0].Properties.Description = "Port
Mirror Rule"
$portmirror.ServiceInsertionRules[0].Properties.Protocol = "All"
$portmirror.ServiceInsertionRules[0].Properties.SourcePortRangeStart =
"0"
$portmirror.ServiceInsertionRules[0].Properties.SourcePortRangeEnd =
"65535"
$portmirror.ServiceInsertionRules[0].Properties.DestinationPortRangeSta
rt = "0"
$portmirror.ServiceInsertionRules[0].Properties.DestinationPortRangeEnd
= "65535"
$portmirror.ServiceInsertionRules[0].Properties.SourceSubnets = "*"
$portmirror.ServiceInsertionRules[0].Properties.DestinationSubnets =
"*"
5. Crie um objeto serviceinsertionelements para conter a interface de rede do

dispositivo espelhado.
PowerShell
$portmirror.ServiceInsertionElements =
[Microsoft.Windows.NetworkController.ServiceInsertionElement[]]::new(1)
$portmirror.ServiceInsertionElements[0] =
[Microsoft.Windows.NetworkController.ServiceInsertionElement]::new()
$portmirror.ServiceInsertionElements[0].ResourceId = "Element1"
$portmirror.ServiceInsertionElements[0].Properties =
[Microsoft.Windows.NetworkController.ServiceInsertionElementProperties]
::new()
$portmirror.ServiceInsertionElements[0].Properties.Description = "Port
Mirror Element"
$portmirror.ServiceInsertionElements[0].Properties.NetworkInterface =
$dstNic
$portmirror.ServiceInsertionElements[0].Properties.Order = 1
6. Adicione o objeto de inserção de serviço no Controlador de Rede.
Quando você emite esse comando, todo o tráfego para o adaptador de rede do
dispositivo especificado na etapa anterior é interrompido.
PowerShell
$portMirror = New-NetworkControllerServiceInsertion -ConnectionUri $uri

-Properties $portmirror -ResourceId "MirrorAll"
7. Atualize a interface de rede da origem a ser espelhada.
PowerShell
$srcNic.Properties.IpConfigurations[0].Properties.ServiceInsertion =
$portMirror
$srcNic = New-NetworkControllerNetworkInterface -ConnectionUri $uri -

Properties $srcNic.Properties -ResourceId $srcNic.ResourceId
Depois de concluir essas etapas, a interface Appliance_Ethernet1 espelha o tráfego da

interface MyVM_Ethernet1.
Clustering convidado em uma rede
virtual
Máquinas virtuais conectadas a uma rede virtual só têm permissão para usar os
endereços IP atribuídos pelo Controlador de Rede para se comunicarem na rede. As
tecnologias de clustering que exigem um endereço IP flutuante, como o Clustering de
Failover da Microsoft, exigem algumas etapas extras para funcionar corretamente.
O método para tornar o IP flutuante acessível é usar um IP virtual (SLB) de software

Load Balancer (SLB). O balanceador de carga de software deve ser configurado com
uma investigação de integridade em uma porta nesse IP para que o SLB direcione o
tráfego para o computador que atualmente tem esse IP.
Exemplo: Configuração do balanceador de

carga
Este exemplo pressupõe que você já criou as VMs que se tornarão nós de cluster e as
anexou a um Rede Virtual. Para obter diretrizes, consulte Criar uma VM e Conexão para
um locatário Rede Virtual ou VLAN.
Neste exemplo, você criará um endereço IP virtual (192.168.2.100) para representar o

endereço IP flutuante do cluster e configurará uma investigação de integridade para
monitorar a porta TCP 59999 para determinar qual nó é o ativo.
1. Selecione o VIP.
Prepare atribuindo um endereço IP VIP, que pode ser qualquer endereço não
utilizado ou reservado na mesma sub-rede que os nós de cluster. O VIP deve
corresponder ao endereço flutuante do cluster.
PowerShell
$VIP = "192.168.2.100"
$subnet = "Subnet2"
$VirtualNetwork = "MyNetwork"
$ResourceId = "MyNetwork_InternalVIP"
2. Crie o objeto de propriedades do balanceador de carga.
PowerShell
3. Crie um endereço IP de front-end.
PowerShell
$LoadBalancerProperties.frontendipconfigurations += $FrontEnd = new-

object
$FrontEnd.properties = new-object
Properties
$FrontEnd.resourceId = "Frontend1"
$FrontEnd.resourceRef =
"/loadBalancers/$ResourceId/frontendIPConfigurations/$($FrontEnd.resour
ceId)"
$FrontEnd.properties.subnet = new-object
$FrontEnd.properties.subnet.ResourceRef =
"/VirtualNetworks/MyNetwork/Subnets/Subnet2"
$FrontEnd.properties.privateIPAddress = $VIP
$FrontEnd.properties.privateIPAllocationMethod = "Static"
4. Crie um pool de back-end para conter os nós de cluster.
PowerShell
$BackEnd = new-object
$BackEnd.properties = new-object
rties
$BackEnd.resourceId = "Backend1"
$BackEnd.resourceRef =
"/loadBalancers/$ResourceId/backendAddressPools/$($BackEnd.resourceId)"
$LoadBalancerProperties.backendAddressPools += $BackEnd
5. Adicione uma investigação para detectar em qual nó de cluster o endereço

flutuante está ativo no momento.
７ Observação
A consulta de investigação no endereço permanente da VM na porta definida
abaixo. A porta só deve responder no nó ativo.
PowerShell
$LoadBalancerProperties.probes += $lbprobe = new-object

Microsoft.Windows.NetworkController.LoadBalancerProbe
$lbprobe.properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerProbeProperties
$lbprobe.ResourceId = "Probe1"
$lbprobe.resourceRef =
"/loadBalancers/$ResourceId/Probes/$($lbprobe.resourceId)"
$lbprobe.properties.protocol = "TCP"
$lbprobe.properties.port = "59999"
$lbprobe.properties.IntervalInSeconds = 5
$lbprobe.properties.NumberOfProbes = 11
6. Adicione as regras de balanceamento de carga para a porta TCP 1433.
Você pode modificar o protocolo e a porta conforme necessário. Você também

pode repetir essa etapa várias vezes para outras portas e protocolos neste VIP. É
importante que EnableFloatingIP esteja definido como $true porque isso informa
ao balanceador de carga para enviar o pacote para o nó com o VIP original no
local.
PowerShell
$LoadBalancerProperties.loadbalancingRules += $lbrule = new-object

Microsoft.Windows.NetworkController.LoadBalancingRule
$lbrule.properties = new-object
Microsoft.Windows.NetworkController.LoadBalancingRuleProperties
$lbrule.ResourceId = "Rules1"
$lbrule.properties.frontendipconfigurations += $FrontEnd
$lbrule.properties.backendaddresspool = $BackEnd
$lbrule.properties.protocol = "TCP"
$lbrule.properties.frontendPort = $lbrule.properties.backendPort = 1433
$lbrule.properties.IdleTimeoutInMinutes = 4
$lbrule.properties.EnableFloatingIP = $true
$lbrule.properties.Probe = $lbprobe
7. Crie o balanceador de carga no Controlador de Rede.
PowerShell
$lb = New-NetworkControllerLoadBalancer -ConnectionUri $URI -ResourceId

$ResourceId -Properties $LoadBalancerProperties -Force
8. Adicione os nós de cluster ao pool de back-end.
Você pode adicionar tantos nós ao pool quanto necessário para o cluster.
PowerShell
# Cluster Node 1

resourceid "ClusterNode1_Network-Adapter"
$nic = new-networkcontrollernetworkinterface -connectionuri $uri -

resourceid $nic.resourceid -properties $nic.properties -force
# Cluster Node 2

resourceid "ClusterNode2_Network-Adapter"
$nic = new-networkcontrollernetworkinterface -connectionuri $uri -

resourceid $nic.resourceid -properties $nic.properties -force
Depois de criar o balanceador de carga e adicionar as interfaces de rede ao pool

de back-end, você estará pronto para configurar o cluster.
9. (Opcional) Se você estiver usando um Cluster de Failover da Microsoft, continue

com o próximo exemplo.
Exemplo 2: Configurando um cluster de failover

da Microsoft
Você pode usar as etapas a seguir para configurar um cluster de failover.
1. Instale e configure propriedades para um cluster de failover.
PowerShell
add-windowsfeature failover-clustering -IncludeManagementTools
Import-module failoverclusters
$ClusterName = "MyCluster"
$ClusterNetworkName = "Cluster Network 1"
$IPResourceName =
$ILBIP = "192.168.2.100"
$nodes = @("DB1", "DB2")
2. Crie o cluster em um nó.
PowerShell
New-Cluster -Name $ClusterName -NoStorage -Node $nodes[0]
3. Pare o recurso de cluster.
PowerShell
Stop-ClusterResource "Cluster Name"
4. Defina o IP do cluster e a porta de investigação.
O endereço IP deve corresponder ao endereço IP de front-end usado no exemplo

anterior e a porta de investigação deve corresponder à porta de investigação no
exemplo anterior.
PowerShell
Get-ClusterResource "Cluster IP Address" | Set-ClusterParameter -

Multiple
@{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255"
;"Network"="$ClusterNetworkName";"EnableDhcp"=0}
5. Inicie os recursos do cluster.
PowerShell
Start-ClusterResource "Cluster IP Address" -Wait 60
Start-ClusterResource "Cluster Name" -Wait 60
6. Adicione os nós restantes.
PowerShell
Add-ClusterNode $nodes[1]
Seu cluster está ativo. O tráfego que vai para o VIP na porta especificada é direcionado
para o nó ativo.
Atualizar, fazer backup e restaurar a
infraestrutura do SDN
Neste tópico, você aprenderá a atualizar, fazer backup e restaurar uma infraestrutura
SDN.
Atualizar a infraestrutura do SDN

A infraestrutura do SDN pode ser atualizada de Windows Server 2016 para Windows
Server 2019. Para a ordenação de atualização, siga a mesma sequência de etapas
mencionada na seção "Atualizar a infraestrutura do SDN". Antes da atualização, é
recomendável fazer um backup do banco de dados do Controlador de Rede.
Para computadores controladores de rede, use o cmdlet Get-NetworkControllerNode

para verificar o status do nó após a conclusão da atualização. Verifique se o nó volta
para o status "Up" antes de atualizar os outros nós. Depois de atualizar todos os nós do
Controlador de Rede, o Controlador de Rede atualizará os microsserviços em execução
no cluster controlador de rede dentro de uma hora. Você pode disparar uma atualização
imediata usando o cmdlet update-networkcontroller.
Instale as mesmas atualizações Windows em todos os componentes do sistema

operacional do sistema SDN (Software Defined Networking), que inclui:
Hosts Hyper-V habilitados para SDN

VMs do Controlador de Rede
VMs Mux Load Balancer software
RAS Gateway VMs
） Importante
Se você usar System Center Virtual Manager, deverá atualizá-lo com os pacotes
cumulativos de atualização mais recentes.
Ao atualizar cada componente, você pode usar qualquer um dos métodos padrão para
instalar Windows atualizações. No entanto, para garantir o tempo de inatividade mínimo
para cargas de trabalho e a integridade do banco de dados do Controlador de Rede,
siga estas etapas:
1. Atualize os consoles de gerenciamento.
Instale as atualizações em cada um dos computadores em que você usa o módulo

PowerShell do Controlador de Rede. Incluindo em qualquer lugar que você tenha a
função RSAT-NetworkController instalada por si só. Excluindo as próprias VMs do
Controlador de Rede; você os atualiza na próxima etapa.
2. Na primeira VM do Controlador de Rede, instale todas as atualizações e reinicie.
3. Antes de prosseguir para a próxima VM do Controlador de Rede, use o get-

networkcontrollernode cmdlet para verificar o status do nó que você atualizou e
reiniciou.
4. Durante o ciclo de reinicialização, aguarde até que o nó controlador de rede desça

e volte para cima novamente.
Depois de reinicializar a VM, ela pode levar vários minutos até que ela volte ao
status Up . Para obter um exemplo da saída, consulte
5. Instale atualizações em cada VM do SLB Mux uma de cada vez para garantir a
disponibilidade contínua da infraestrutura do balanceador de carga.
6. Atualize hosts Hyper-V e gateways RAS, começando com os hosts que contêm os
gateways RAS que estão no modo de espera .
As VMs do gateway RAS não podem ser migradas ao vivo sem perder conexões de
locatário. Durante o ciclo de atualização, você deve ter cuidado para minimizar o
número de vezes que as conexões de locatário fazem failover para um novo
gateway RAS. Ao coordenar a atualização de hosts e gateways RAS, cada locatário
faz failover uma vez, no máximo.
a. Evacue o host de VMs capazes de migração dinâmica.
As VMs do gateway RAS devem permanecer no host.
b. Instale atualizações em cada VM do Gateway neste host.
c. Se a atualização exigir que a VM do gateway seja reinicializada, reinicialize a VM.
d. Instale atualizações no host que contém a VM do gateway que acabou de ser

atualizada.
e. Reinicie o host, se necessário, pelas atualizações.

f. Repita para cada host adicional que contém um gateway de espera.
Se nenhum gateway de espera permanecer, siga estas mesmas etapas para todos
os hosts restantes.
Exemplo: usar o cmdlet get-networkcontrollernode

Neste exemplo, você verá a saída para o get-networkcontrollernode cmdlet ser
executado de dentro de uma das VMs do Controlador de Rede.
O status dos nós que você vê na saída de exemplo é:
NCNode1.contoso.com = Para baixo

NCNode2.contoso.com = Up
NCNode3.contoso.com = Up
） Importante
Você deve esperar vários minutos até que o status do nó seja alterado para Cima
antes de atualizar quaisquer nós adicionais, um de cada vez.
Depois de atualizar todos os nós do Controlador de Rede, o Controlador de Rede

atualizará os microsserviços em execução no cluster controlador de rede dentro de uma
hora.
 Dica
Você pode disparar uma atualização imediata usando o update-networkcontroller

cmdlet.
PowerShell
PS C:\> get-networkcontrollernode
Name : NCNode1.contoso.com
Server : NCNode1.Contoso.com
FaultDomain : fd:/NCNode1.Contoso.com
RestInterface : Ethernet
NodeCertificate :
Status : Down
Name : NCNode2.Contoso.com
Server : NCNode2.contoso.com
FaultDomain : fd:/ NCNode2.Contoso.com
NodeCertificate :
Status : Up
Name : NCNode3.Contoso.com
Server : NCNode3.Contoso.com
FaultDomain : fd:/ NCNode3.Contoso.com
NodeCertificate :
Status : Up
Exemplo: usar o cmdlet update-networkcontroller

Neste exemplo, você verá a saída do update-networkcontroller cmdlet para forçar o
Controlador de Rede a atualizar.
） Importante
Execute este cmdlet quando você não tiver mais atualizações para instalar.
PowerShell
PS C:\> update-networkcontroller
NetworkControllerClusterVersion NetworkControllerVersion
------------------------------- ------------------------
10.1.1 10.1.15
Fazer backup da infraestrutura do SDN

Backups regulares do banco de dados controlador de rede garantem a continuidade
dos negócios em caso de desastre ou perda de dados. O backup das VMs do
Controlador de Rede não é suficiente porque não garante que a sessão continue entre
os vários nós do Controlador de Rede.
Requisitos:
Um compartilhamento SMB e credenciais com permissões de leitura/gravação para

o sistema de compartilhamento e arquivos.
Opcionalmente, você pode usar uma GMSA (Conta de Serviço Gerenciado de
Grupo) se o Controlador de Rede foi instalado usando um GMSA também.
Procedimento:
1. Use o método de backup da VM de sua escolha ou use o Hyper-V para exportar
uma cópia de cada VM do Controlador de Rede.
O backup da VM do Controlador de Rede garante que os certificados necessários

para descriptografar o banco de dados estejam presentes.
2. Se estiver usando System Center Virtual Machine Manager (SCVMM), pare o

serviço SCVMM e faça backup por meio de SQL Server.
O objetivo aqui é garantir que nenhuma atualização seja feita no SCVMM durante
esse tempo, o que pode criar uma inconsistência entre o backup do Controlador
de Rede e o SCVMM.
） Importante
Não reinicie o serviço SCVMM até que o backup do Controlador de Rede seja
concluído.
3. Faça backup do banco de dados do Controlador de Rede com o new-

networkcontrollerbackup cmdlet.
4. Verifique a conclusão e o sucesso do backup com o get-networkcontrollerbackup

cmdlet.
5. Se estiver usando SCVMM, inicie o serviço SCVMM.
Exemplo: fazendo backup do banco de dados do

Controlador de Rede
PowerShell
$URI = "https://NC.contoso.com"
# Get or Create Credential object for File share user
$ShareUserResourceId = "BackupUser"
$ShareCredential = Get-NetworkControllerCredential -ConnectionURI $URI -

Credential $Credential | Where {$_.ResourceId -eq $ShareUserResourceId }
If ($ShareCredential -eq $null) {
$CredentialProperties = New-Object
$CredentialProperties.Type = "usernamePassword"
$CredentialProperties.UserName = "contoso\alyoung"
$CredentialProperties.Value = "<Password>"
$ShareCredential = New-NetworkControllerCredential -ConnectionURI $URI -

Credential $Credential -Properties $CredentialProperties -ResourceId
$ShareUserResourceId -Force
# Create backup
$BackupTime = (get-date).ToString("s").Replace(":", "_")
$BackupProperties = New-Object
Microsoft.Windows.NetworkController.NetworkControllerBackupProperties
$BackupProperties.BackupPath =
"\\fileshare\backups\NetworkController\$BackupTime"
$BackupProperties.Credential = $ShareCredential
$Backup = New-NetworkControllerBackup -ConnectionURI $URI -Credential

$Credential -Properties $BackupProperties -ResourceId $BackupTime -Force
Exemplo: verificando o status de uma operação de

backup do Controlador de Rede
PowerShell
PS C:\ > Get-NetworkControllerBackup -ConnectionUri $URI -Credential

$Credential -ResourceId $Backup.ResourceId
| ConvertTo-JSON -Depth 10
"Tags": null,
"ResourceRef": "/networkControllerBackup/2017-04-25T16_53_13",
"InstanceId": "c3ea75ae-2892-4e10-b26c-a2243b755dc8",
"Etag": "W/\"0dafea6c-39db-401b-bda5-d2885ded470e\"",
"ResourceId": "2017-04-25T16_53_13",
"Properties": {
"BackupPath":
"\\\\fileshare\backups\NetworkController\\2017-04-25T16_53_13",
"ErrorMessage": "",
"FailedResourcesList": [
],
"SuccessfulResourcesList": [
"/networking/v1/credentials/11ebfc10-438c-4a96-a1ee-8a048ce675be",
"/networking/v1/credentials/41229069-85d4-4352-be85-034d0c5f4658",
"/networking/v1/credentials/b2a82c93-2583-4a1f-91f8-232b801e11bb",
"/networking/v1/credentials/BackupUser",
"/networking/v1/credentials/fd5b1b96-b302-4395-b6cd-ed9703435dd1",
"/networking/v1/virtualNetworkManager/configuration",
"/networking/v1/virtualSwitchManager/configuration",
"/networking/v1/accessControlLists/f8b97a4c-4419-481d-b757-a58483512640",
"/networking/v1/logicalnetworks/24fa1af9-88d6-4cdc-aba0-66e38c1a7bb8",
"/networking/v1/logicalnetworks/48610528-f40b-4718-938e-99c2be76f1e0",
"/networking/v1/logicalnetworks/89035b49-1ee3-438a-8d7a-f93cbae40619",
"/networking/v1/logicalnetworks/a9c8eaa0-519c-4988-acd6-11723e9efae5",
"/networking/v1/logicalnetworks/d4ea002c-c926-4c57-a178-461d5768c31f",
"/networking/v1/macPools/11111111-1111-1111-1111-111111111111",
"/networking/v1/loadBalancerManager/config",
"/networking/v1/publicIPAddresses/2c502b2d-b39a-4be1-a85a-55ef6a3a9a1d",
"/networking/v1/GatewayPools/Default",
"/networking/v1/servers/4c4c4544-0058-5810-8056-b4c04f395931",
"/networking/v1/networkInterfaces/058430d3-af43-4328-a440-56540f41da50",
"/networking/v1/networkInterfaces/08756090-6d55-4dec-98d5-80c4c5a47db8",
"/networking/v1/networkInterfaces/2175d74a-aacd-44e2-80d3-03f39ea3bc5d",
"/networking/v1/networkInterfaces/2400c2c3-2291-4b0b-929c-9bb8da55851a",
"/networking/v1/networkInterfaces/4c695570-6faa-4e4d-a552-0b36ed3e0962",
"/networking/v1/networkInterfaces/7e317638-2914-42a8-a2dd-3a6d966028d6",
"/networking/v1/networkInterfaces/834e3937-f43b-4d3c-88be-d79b04e63bce",
"/networking/v1/networkInterfaces/9d668fe6-b1c6-48fc-b8b1-b3f98f47d508",
"/networking/v1/networkInterfaces/ac4650ac-c3ef-4366-96e7-d9488fb661ba",
"/networking/v1/networkInterfaces/b9f23e35-d79e-495f-a1c9-fa626b85ae13",
"/networking/v1/networkInterfaces/fdd929f1-f64f-4463-949a-77b67fe6d048",
"/networking/v1/virtualServers/15a891ee-7509-4e1d-878d-de0cb4fa35fd",
"/networking/v1/virtualServers/57416993-b410-44fd-9675-727cd4e98930",
"/networking/v1/virtualServers/5f8aebdc-ee5b-488f-ac44-dd6b57bd316a",
"/networking/v1/virtualServers/6c812217-5931-43dc-92a8-1da3238da893",
"/networking/v1/virtualServers/d78b7fa3-812d-4011-9997-aeb5ded2b431",
"/networking/v1/virtualServers/d90820a5-635b-4016-9d6f-bf3f1e18971d",
"/networking/v1/loadBalancerMuxes/5f8aebdc-ee5b-488f-ac44-
dd6b57bd316a_suffix",
"/networking/v1/loadBalancerMuxes/d78b7fa3-812d-4011-9997-
aeb5ded2b431_suffix",
"/networking/v1/loadBalancerMuxes/d90820a5-635b-4016-9d6f-
bf3f1e18971d_suffix",
"/networking/v1/Gateways/15a891ee-7509-4e1d-878d-de0cb4fa35fd_suffix",
"/networking/v1/Gateways/57416993-b410-44fd-9675-727cd4e98930_suffix",
"/networking/v1/Gateways/6c812217-5931-43dc-92a8-1da3238da893_suffix",
"/networking/v1/virtualNetworks/b3dbafb9-2655-433d-b47d-a0e0bbac867a",
"/networking/v1/virtualNetworks/d705968e-2dc2-48f2-a263-76c7892fb143",
"/networking/v1/loadBalancers/24fa1af9-88d6-4cdc-aba0-
66e38c1a7bb8_10.127.132.2",
66e38c1a7bb8_10.127.132.3",
66e38c1a7bb8_10.127.132.4"
],
"InProgressResourcesList": [
],
"Credential": {
"Tags": null,
"ResourceRef":
"/credentials/BackupUser",
"InstanceId": "00000000-0000-0000-
0000-000000000000",
"Etag": null,
"ResourceId": null,
"Properties": null
Restaurar a infraestrutura do SDN de um

backup
Quando você restaura todos os componentes necessários do backup, o ambiente SDN
retorna a um estado operacional.
） Importante
As etapas variam dependendo do número de componentes restaurados.
1. Se necessário, reimplante hosts Hyper-V e o armazenamento necessário.
2. Se necessário, restaure as VMs do Controlador de Rede, as VMs do gateway ras e

as VMs Mux do backup.
3. Pare o agente host NC e o agente host SLB em todos os hosts Hyper-V:
stop-service slbhostagent
stop-service nchostagent
4. Parar VMs do gateway RAS.
5. Parar VMs do SLB Mux.
6. Restaure o Controlador de Rede com o new-networkcontrollerrestore cmdlet.
7. Verifique a restauração provisioningState para saber quando a restauração foi

concluída com êxito.
8. Se estiver usando o SCVMM, restaure o banco de dados SCVMM usando o backup

que foi criado ao mesmo tempo que o backup do Controlador de Rede.
9. Se você quiser restaurar VMs de carga de trabalho do backup, faça isso agora.
10. Verifique a integridade do sistema com o cmdlet de debug-

networkcontrollerconfigurationstate.
PowerShell
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController
"https://NC.contoso.com" -Credential $cred
Fetching ResourceType: accessControlLists
Fetching ResourceType: servers
Fetching ResourceType: virtualNetworks
Fetching ResourceType: networkInterfaces
Fetching ResourceType: virtualGateways
Fetching ResourceType: loadbalancerMuxes
Fetching ResourceType: Gateways
Exemplo: restaurando um banco de dados do

Controlador de Rede
PowerShell
$URI = "https://NC.contoso.com"
$ShareUserResourceId = "BackupUser"
$ShareCredential = Get-NetworkControllerCredential -ConnectionURI $URI -

Credential $Credential | Where {$_.ResourceId -eq $ShareUserResourceId }
$RestoreProperties = New-Object
Microsoft.Windows.NetworkController.NetworkControllerRestoreProperties
$RestoreProperties.RestorePath =
"\\fileshare\backups\NetworkController\2017-04-25T16_53_13"
$RestoreProperties.Credential = $ShareCredential
$RestoreTime = (Get-Date).ToString("s").Replace(":", "_")
New-NetworkControllerRestore -ConnectionURI $URI -Credential $Credential -

Properties $RestoreProperties -ResourceId $RestoreTime -Force
Exemplo: verificando o status de uma restauração de

banco de dados do Controlador de Rede
PowerShell
PS C:\ > get-networkcontrollerrestore -connectionuri $uri -credential $cred

-ResourceId $restoreTime | convertto-json -depth 10
"Tags": null,
"ResourceRef": "/networkControllerRestore/2017-04-26T15_04_44",
"InstanceId": "22edecc8-a613-48ce-a74f-0418789f04f6",
"Etag": "W/\"f14f6b84-80a7-4b73-93b5-59a9c4b5d98e\"",
"ResourceId": "2017-04-26T15_04_44",
"Properties": {
"RestorePath":
"\\\\sa18fs\\sa18n22\\NetworkController\\2017-04-25T16_53_13",
"ErrorMessage": null,
"FailedResourcesList": null,
"SuccessfulResourcesList": null,
"Credential": null
Para obter informações sobre mensagens de estado de configuração que podem

aparecer, consulte Solucionar problemas do Windows Server 2016 Pilha de Rede
Definida pelo Software.
Proteger o controlador de rede
Neste tópico, você aprenderá a configurar a segurança para toda a comunicação entre o
Controlador de Rede e outros softwares e dispositivos.
Os caminhos de comunicação que você pode proteger incluem comunicação

northbound no plano de gerenciamento, comunicação de cluster entre VMs (máquinas
virtuais) do Controlador de Rede em um cluster e comunicação de direção sul no plano
de dados.
1. Comunicação norte. O Controlador de Rede se comunica no plano de

gerenciamento com software de gerenciamento compatível com SDN, como
Windows PowerShell e System Center Virtual Machine Manager (SCVMM). Essas
ferramentas de gerenciamento fornecem a capacidade de definir a política de rede
e criar um estado de meta para a rede, com o qual você pode comparar a
configuração de rede real para colocar a configuração real em paridade com o
estado de meta.
2. Comunicação de cluster do controlador de rede. Quando você configura três ou

mais VMs como nós de cluster do Controlador de Rede, esses nós se comunicam
entre si. Essa comunicação pode estar relacionada à sincronização e replicação de
dados entre nós ou à comunicação específica entre os serviços do Controlador de
Rede.
3. Comunicação de direção sul. O Controlador de Rede se comunica no plano de

dados com a infraestrutura de SDN e outros dispositivos, como balanceadores de
carga de software, gateways e computadores host. Você pode usar o Controlador
de Rede para configurar e gerenciar esses dispositivos de direção sul para que eles
mantenham o estado de meta configurado para a rede.
Comunicação norte
O Controlador de Rede dá suporte à autenticação, autorização e criptografia para
comunicação northbound. As seções a seguir fornecem informações sobre como definir
essas configurações de segurança.
Autenticação
Ao configurar a autenticação para a comunicação northbound do controlador de rede,
você permite que os nós de cluster do Controlador de Rede e os clientes de
gerenciamento verifiquem a identidade do dispositivo com o qual eles estão se
comunicando.
O Controlador de Rede dá suporte aos três modos de autenticação a seguir entre

clientes de gerenciamento e nós do Controlador de Rede.
７ Observação
Se você estiver implantando o Controlador de Rede com System Center Virtual

Machine Manager, somente o modo Kerberos terá suporte.
1. Kerberos. Use a autenticação Kerberos ao unir o cliente de gerenciamento e todos

os nós de cluster do Controlador de Rede a um domínio do Active Directory. O
domínio do Active Directory deve ter contas de domínio usadas para autenticação.
2. X509. Use x509 para autenticação baseada em certificado para clientes de

gerenciamento que não ingressaram em um domínio do Active Directory. Você
deve registrar certificados em todos os nós de cluster do Controlador de Rede e
clientes de gerenciamento. Além disso, todos os nós e clientes de gerenciamento
devem confiar nos certificados uns dos outros.
3. None. Use None para fins de teste em um ambiente de teste e, portanto, não é
recomendado para uso em um ambiente de produção. Quando você escolhe esse
modo, não há autenticação executada entre nós e clientes de gerenciamento.
Você pode configurar o modo de autenticação para comunicação northbound usando o

comando Windows PowerShell Install-NetworkController com o parâmetro
ClientAuthentication.
Autorização
Ao configurar a autorização para a comunicação northbound do controlador de rede,
você permite que os nós de cluster e os clientes de gerenciamento do Controlador de
Rede verifiquem se o dispositivo com o qual eles estão se comunicando é confiável e
tem permissão para participar da comunicação.
Use os seguintes métodos de autorização para cada um dos modos de autenticação

compatíveis com o Controlador de Rede.
1. Kerberos. Ao usar o método de autenticação Kerberos, você define os usuários e
computadores autorizados a se comunicar com o Controlador de Rede criando um
grupo de segurança no Active Directory e, em seguida, adicionando os usuários e
computadores autorizados ao grupo. Você pode configurar o Controlador de Rede
para usar o grupo de segurança para autorização usando o parâmetro
ClientSecurityGroup do comando Install-NetworkController Windows PowerShell.
Depois de instalar o Controlador de Rede, você pode alterar o grupo de segurança
usando o comando Set-NetworkController com o parâmetro -ClientSecurityGroup.
Se estiver usando o SCVMM, você deverá fornecer o grupo de segurança como um
parâmetro durante a implantação.
2. X509. Quando você está usando o método de autenticação X509, o Controlador

de Rede aceita apenas solicitações de clientes de gerenciamento cujas impressões
digitais de certificado são conhecidas pelo Controlador de Rede. Você pode
configurar essas impressões digitais usando o parâmetro
ClientCertificateThumbprint do comando Install-NetworkController Windows
PowerShell. Você pode adicionar outras impressões digitais do cliente a qualquer
momento usando o comando Set-NetworkController .
3. None. Quando você escolhe esse modo, não há autenticação executada entre nós
e clientes de gerenciamento. Use None para fins de teste em um ambiente de
teste e, portanto, não é recomendado para uso em um ambiente de produção.
Criptografia
A comunicação no sentido norte usa sSL (Secure Sockets Layer) para criar um canal
criptografado entre clientes de gerenciamento e nós do Controlador de Rede. A
criptografia SSL para comunicação northbound inclui os seguintes requisitos:
Todos os nós do Controlador de Rede devem ter um certificado idêntico que inclua
as finalidades de Autenticação de Servidor e Autenticação de Cliente em extensões
de EKU (Uso Avançado de Chave).
O URI usado pelos clientes de gerenciamento para se comunicar com o

Controlador de Rede deve ser o nome da entidade do certificado. O nome da
entidade do certificado deve conter o FQDN (Nome de Domínio Totalmente
Qualificado) ou o endereço IP do ponto de extremidade REST do controlador de
rede.
Se os nós do Controlador de Rede estiverem em sub-redes diferentes, o nome da

entidade de seus certificados deverá ser o mesmo que o valor usado para o
parâmetro RestName no comando Install-NetworkController Windows PowerShell.
Todos os clientes de gerenciamento devem confiar no certificado SSL.
Registro e configuração de certificado SSL

Você deve registrar manualmente o certificado SSL em nós do Controlador de Rede.
Depois que o certificado for registrado, você poderá configurar o Controlador de Rede
para usar o certificado com o parâmetro -ServerCertificate do comando Install-
NetworkController Windows PowerShell. Se você já instalou o Controlador de Rede,
poderá atualizar a configuração a qualquer momento usando o comando Set-
NetworkController .
７ Observação
Se você estiver usando o SCVMM, deverá adicionar o certificado como um recurso

de biblioteca. Para obter mais informações, consulte Configurar um controlador de
rede SDN na malha do VMM.
Comunicação de cluster do controlador de rede

O Controlador de Rede dá suporte à autenticação, autorização e criptografia para
comunicação entre nós do Controlador de Rede. A comunicação é por meio do WCF (
Windows Communication Foundation ) e do TCP.
Você pode configurar esse modo com o parâmetro ClusterAuthentication do comando

Install-NetworkControllerCluster Windows PowerShell.
Para obter mais informações, consulte Install-NetworkControllerCluster.
Autenticação
Ao configurar a autenticação para a comunicação do Cluster do Controlador de Rede,
você permite que os nós de cluster do Controlador de Rede verifiquem a identidade dos
outros nós com os quais eles estão se comunicando.
O Controlador de Rede dá suporte aos três modos de autenticação a seguir entre nós
do Controlador de Rede.
７ Observação
Se você implantar o Controlador de Rede usando o SCVMM, somente o modo
Kerberos terá suporte.
1. Kerberos. Você pode usar a autenticação Kerberos quando todos os nós de cluster
do Controlador de Rede forem ingressados em um domínio do Active Directory,
com contas de domínio usadas para autenticação.
2. X509. X509 é autenticação baseada em certificado. Você pode usar a autenticação

X509 quando os nós de cluster do Controlador de Rede não estiverem ingressados
em um domínio do Active Directory. Para usar x509, você deve registrar
certificados em todos os nós de cluster do Controlador de Rede e todos os nós
devem confiar nos certificados. Além disso, o nome da entidade do certificado
registrado em cada nó deve ser o mesmo que o nome DNS do nó.
3. None. Quando você escolhe esse modo, não há nenhuma autenticação executada
entre nós do Controlador de Rede. Esse modo é fornecido apenas para fins de
teste e não é recomendado para uso em um ambiente de produção.
Autorização
Ao configurar a autorização para a comunicação do Cluster do Controlador de Rede,
você permite que os nós de cluster do Controlador de Rede verifiquem se os nós com
os quais eles estão se comunicando são confiáveis e têm permissão para participar da
comunicação.
Para cada um dos modos de autenticação compatíveis com o Controlador de Rede, os

seguintes métodos de autorização são usados.
1. Kerberos. Os nós do Controlador de Rede aceitam solicitações de comunicação

somente de outras contas de computador do Controlador de Rede. Você pode
configurar essas contas ao implantar o Controlador de Rede usando o parâmetro
Name do comando New-NetworkControllerNodeObject Windows PowerShell.
2. X509. Os nós do Controlador de Rede aceitam solicitações de comunicação

somente de outras contas de computador do Controlador de Rede. Você pode
configurar essas contas ao implantar o Controlador de Rede usando o parâmetro
Name do comando New-NetworkControllerNodeObject Windows PowerShell.
3. None. Quando você escolhe esse modo, não há autorização executada entre nós
do Controlador de Rede. Esse modo é fornecido apenas para fins de teste e não é
recomendado para uso em um ambiente de produção.
Criptografia
A comunicação entre nós do Controlador de Rede é criptografada usando a criptografia
de nível de transporte do WCF. Essa forma de criptografia é usada quando os métodos
de autenticação e autorização são certificados Kerberos ou X509. Para obter mais
informações, consulte os tópicos a seguir.
Como: proteger um serviço com credenciais do Windows

Como proteger um serviço com certificados X.509.
Comunicação de southbound
O Controlador de Rede interage com diferentes tipos de dispositivos para comunicação
southbound. Essas interações usam protocolos diferentes. Por isso, há requisitos
diferentes para autenticação, autorização e criptografia, dependendo do tipo de
dispositivo e protocolo usado pelo Controlador de Rede para se comunicar com o
dispositivo.
A tabela a seguir fornece informações sobre a interação do Controlador de Rede com

diferentes dispositivos de direção sul.
Dispositivo/serviço de direção sul Protocolo Autenticação usada
Balanceador de Carga de Software WCF (MUX), TCP (Host) Certificados
Firewall OVSDB Certificados
Gateway WinRM Kerberos, Certificados
Rede Virtual OVSDB, WCF Certificados
Roteamento definido pelo usuário OVSDB Certificados
Para cada um desses protocolos, o mecanismo de comunicação é descrito na seção a

seguir.
Autenticação
Para comunicação southbound, os protocolos e métodos de autenticação a seguir são
usados.
1. WCF/TCP/OVSDB. Para esses protocolos, a autenticação é executada usando

certificados X509. O Controlador de Rede e os computadores MUX (Multiplexer)
de Balanceamento de Carga de Software (SLB) par apresentam seus certificados
uns aos outros para autenticação mútua. Cada certificado deve ser confiável pelo
par remoto.
Para autenticação no sentido sul, você pode usar o mesmo certificado SSL
configurado para criptografar a comunicação com os clientes northbound. Você
também deve configurar um certificado no SLB MUX e nos dispositivos host. O
nome da entidade do certificado deve ser o mesmo que o nome DNS do
dispositivo.
2. WinRM. Para esse protocolo, a autenticação é executada usando Kerberos (para

computadores ingressados no domínio) e usando certificados (para computadores
não ingressados no domínio).
Autorização
Para comunicação southbound, os protocolos e métodos de autorização a seguir são
usados.
1. WCF/TCP. Para esses protocolos, a autorização é baseada no nome do assunto da

entidade par. O Controlador de Rede armazena o nome DNS do dispositivo par e o
usa para autorização. Esse nome DNS deve corresponder ao nome da entidade do
dispositivo no certificado. Da mesma forma, o certificado do Controlador de Rede
deve corresponder ao nome DNS do Controlador de Rede armazenado no
dispositivo par.
2. WinRM. Se o Kerberos estiver sendo usado, a conta do cliente WinRM deverá estar
presente em um grupo predefinido no Active Directory ou no grupo
Administradores Locais no servidor. Se os certificados estiverem sendo usados, o
cliente apresentará um certificado ao servidor que o servidor autoriza usando o
nome/emissor da entidade e o servidor usará uma conta de usuário mapeada para
executar a autenticação.
3. OVSDB. Não há nenhuma autorização fornecida para este protocolo.
Criptografia
Para comunicação southbound, os métodos de criptografia a seguir são usados para
protocolos.
1. WCF/TCP/OVSDB. Para esses protocolos, a criptografia é executada usando o

certificado registrado no cliente ou servidor.
2. WinRM. O tráfego winRM é criptografado por padrão usando o SSP (provedor de
suporte de segurança) Kerberos. Você pode configurar a Criptografia adicional, na
forma de SSL, no servidor WinRM.
Gerenciar certificados para rede
definida pelo software
Você pode usar este tópico para saber como gerenciar certificados para comunicações
do Controlador de Rede norte e sul ao implantar o SDN (Software Defined Networking)
no Windows Server 2019 ou 2016 Datacenter e você estiver usando o System Center
Virtual Machine Manager (SCVMM) como seu cliente de gerenciamento do SDN.
７ Observação
Para obter informações de visão geral sobre o Controlador de Rede, consulte

Se você não estiver usando Kerberos para proteger a comunicação do Controlador de

Rede, poderá usar certificados X.509 para autenticação, autorização e criptografia.
O SDN no Windows Server 2019 e 2016 Datacenter dá suporte a certificados X.509

autoassinados e assinados pela AUTORIDADE de Certificação (CA). Este tópico fornece
instruções passo a passo para criar esses certificados e aplicá-los para proteger canais
de comunicação northbound do controlador de rede com clientes de gerenciamento e
comunicações de direção sul com dispositivos de rede, como o software Load Balancer
(SLB).
Ao usar a autenticação baseada em certificado, você deve registrar um certificado em

nós do Controlador de Rede usados das seguintes maneiras.
1. Criptografar a comunicação northbound com SSL (Secure Sockets Layer) entre nós
do Controlador de Rede e clientes de gerenciamento, como System Center Virtual
Machine Manager.
2. Autenticação entre nós do Controlador de Rede e dispositivos e serviços de
direção sul, como hosts Hyper-V e SLBs (Balanceadores de Carga de Software).
Criando e registrando um certificado X.509

Você pode criar e registrar um certificado autoassinado ou um certificado emitido por
uma AC.
７ Observação
Ao usar o SCVMM para implantar o Controlador de Rede, você deve especificar o

certificado X.509 que é usado para criptografar as comunicações norte durante a
configuração do Modelo de Serviço do Controlador de Rede.
A configuração do certificado deve incluir os valores a seguir.
O valor da caixa de texto RestEndPoint deve ser o FQDN (Nome de Domínio

Totalmente Qualificado) do Controlador de Rede ou o endereço IP.
O valor RestEndPoint deve corresponder ao nome da entidade (Nome Comum,
CN) do certificado X.509.
Criando um certificado X.509 Self-Signed

Você pode criar um certificado X.509 autoassinado e exportá-lo com a chave privada
(protegida com uma senha) seguindo estas etapas para implantações de nó único e
vários nós do Controlador de Rede.
Ao criar certificados autoassinados, você pode usar as diretrizes a seguir.
Você pode usar o endereço IP do ponto de extremidade REST do Controlador de

Rede para o parâmetro DnsName , mas isso não é recomendado porque exige que
os nós do Controlador de Rede estejam todos localizados em uma única sub-rede
de gerenciamento (por exemplo, em um único rack)
Para várias implantações NC de nó, o nome DNS especificado se tornará o FQDN
do Cluster do Controlador de Rede (os registros do Host A do DNS são criados
automaticamente.)
Para implantações de controlador de rede de nó único, o nome DNS pode ser o
nome de host do Controlador de Rede seguido pelo nome de domínio completo.
Vários nós
Você pode usar o comando New-SelfSignedCertificate Windows PowerShell para criar

um certificado autoassinado.
Sintaxe
PowerShell
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong
Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("
<NCRESTName>")
Uso de exemplo
PowerShell

Cryptographic Provider" -FriendlyName "MultiNodeNC" -DnsName
@("NCCluster.Contoso.com")
Nó único
Você pode usar o comando New-SelfSignedCertificate Windows PowerShell para criar
um certificado autoassinado.
Sintaxe
PowerShell

Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("
<NCFQDN>")
Uso de exemplo
PowerShell

Cryptographic Provider" -FriendlyName "SingleNodeNC" -DnsName
@("SingleNodeNC.Contoso.com")
Criando um certificado X.509 CA-Signed

Para criar um certificado usando uma AC, você já deve ter implantado uma PKI
(Infraestrutura de Chave Pública) com o AD CS (Active Directory Certificate Services).
７ Observação
Você pode usar CAs ou ferramentas de terceiros, como openssl, para criar um
certificado para uso com o Controlador de Rede, no entanto, as instruções neste
tópico são específicas para o AD CS. Para saber como usar uma AC ou ferramenta
de terceiros, consulte a documentação do software que você está usando.
A criação de um certificado com uma AC inclui as etapas a seguir.
1. Você ou o Administrador de Segurança ou Domínio da sua organização configura

o modelo de certificado
2. Você ou o Administrador do Controlador de Rede da sua organização ou
administrador do SCVMM solicita um novo certificado da AC.
Requisitos de configuração de certificado
Enquanto você estiver configurando um modelo de certificado na próxima etapa,

verifique se o modelo configurado inclui os seguintes elementos necessários.
1. O nome da entidade do certificado deve ser o FQDN do host Hyper-V

2. O certificado deve ser colocado no repositório pessoal do computador local (My –
cert:\localmachine\my)
3. O certificado deve ter a Autenticação do Servidor (EKU: 1.3.6.1.5.5.7.3.1) e a
Autenticação do Cliente (EKU: 1.3.6.1.5.5.7.3.2) Políticas de aplicativo.
７ Observação
Se o repositório de certificados Pessoal (Meu – cert:\localmachine\my) no host

Hyper-V tiver mais de um certificado X.509 com o Nome da Entidade (CN) como o
FQDN (Nome de Domínio Totalmente Qualificado) do host, verifique se o O
certificado que será usado pelo SDN tem uma propriedade de Uso avançado de
chave personalizada adicional com o OID 1.3.6.1.4.1.311.95.1.1.1. Caso contrário, a
comunicação entre o controlador de rede e o host pode não funcionar.
Para configurar o modelo de certificado
７ Observação
Antes de executar esse procedimento, você deve examinar os requisitos de

certificado e os modelos de certificado disponíveis no console de Modelos de
Certificado. Você pode modificar um modelo existente ou criar uma duplicata de
um modelo existente e modificar sua cópia do modelo. É recomendável criar uma
cópia de um modelo existente.
1. No servidor em que o AD CS está instalado, em Gerenciador do Servidor, clique
em Ferramentas e clique em Autoridade de Certificação. O MMC (Console de
Gerenciamento da Microsoft) da Autoridade de Certificação é aberto.
2. No MMC, clique duas vezes no nome da AC, clique com o botão direito do mouse
em Modelos de Certificado e clique em Gerenciar.
3. O console modelos de certificado é aberto. Todos os modelos de certificado são
exibidos no painel de detalhes.
4. No painel de detalhes, clique no modelo que você deseja duplicar.
5. Clique no menu Ação e clique em Duplicar Modelo. A caixa de diálogo
Propriedades do modelo é aberta.
6. Na caixa de diálogo Propriedades do modelo, na guia Nome da Entidade , clique
em Fornecer na solicitação. (Essa configuração é necessária para certificados SSL
do Controlador de Rede.)
7. Na caixa de diálogo Propriedades do modelo, na guia Tratamento de Solicitações
, verifique se Permitir que a chave privada seja exportada está selecionada.
Verifique também se a assinatura e a finalidade de criptografia estão selecionadas.
8. Na caixa de diálogo Propriedades do modelo, na guia Extensões , selecione Uso
da Chave e clique em Editar.
9. Em Assinatura, verifique se a Assinatura Digital está selecionada.
10. Na caixa de diálogo Propriedades do modelo, na guia Extensões , selecione
Políticas de Aplicativo e clique em Editar.
11. Em Políticas de Aplicativo, verifique se a Autenticação do Cliente e a
Autenticação de Servidor estão listadas.
12. Salve a cópia do modelo de certificado com um nome exclusivo, como modelo de
Para solicitar um certificado da AC

Você pode usar o snap-in Certificados para solicitar certificados. Você pode solicitar
qualquer tipo de certificado que tenha sido pré-configurado e disponibilizado por um
administrador da AC que processe a solicitação de certificado.
Usuários ou administradores locais são a associação de grupo mínima necessária para

1. Abra o snap-in Certificados para um computador.

2. Na árvore de console, clique em Certificados (Computador Local). Selecione o
repositório de certificados pessoal .
3. No menu Ação , aponte para** Todas as Tarefas e clique em **Solicitar Novo
Certificado para iniciar o assistente de Registro de Certificado. Clique em Próximo.
4. Selecione a Política de Registro de Certificado configurada pelo administrador e
clique em Avançar.
5. Selecione a Política de Registro do Active Directory (com base no modelo de AC
configurado na seção anterior).
6. Expanda a seção Detalhes e configure os itens a seguir.
a. Verifique se o uso da chave inclui a assinatura digital **e **Criptografia de
chave.
b. Verifique se as políticas de aplicativo incluem a Autenticação de Servidor
(1.3.6.1.5.5.7.3.1) e a Autenticação do Cliente (1.3.6.1.5.5.7.3.2).
7. Clique em Propriedades.
8. Na guia Assunto , em Nome da entidade, em Tipo, selecione Nome comum. Em
Valor, especifique o ponto de extremidade REST do controlador de rede.
9. Clique em Aplicar e em OK.
10. Clique em Registrar.
No MMC certificados, clique no repositório Pessoal para exibir o certificado que você
registrou da AC.
Exportando e copiando o certificado para a

biblioteca SCVMM
Depois de criar um certificado autoassinado ou assinado por AC, você deve exportar o
certificado com a chave privada (no formato .pfx) e sem a chave privada (no formato
Base-64 .cer) do snap-in Certificados.
Em seguida, você deve copiar os dois arquivos exportados para as pastas

ServerCertificate.cr e NCCertificate.cr especificadas no momento em que importou o
Modelo de Serviço NC.
1. Abra o snap-in Certificados (certlm.msc) e localize o certificado no repositório de

certificados pessoal do computador local.
2. Clique com o botão direito do mouse no certificado, clique em Todas as Tarefas e
clique em Exportar. O Assistente para Exportação de Certificados é aberto. Clique
em Próximo.
3. Selecione Sim, exporte a opção de chave privada e clique em Avançar.
4. Escolha Troca de Informações Pessoais – PKCS nº 12 (. PFX) e aceite o padrão para
Incluir todos os certificados no caminho de certificação , se possível.
5. Atribua os Usuários/Grupos e uma senha para o certificado que você está
exportando, clique em Avançar.
6. Na página Arquivo para exportar, procure o local em que você deseja colocar o
arquivo exportado e nomeá-lo.
7. Da mesma forma, exporte o certificado em . Formato CER. Observação: para
exportar para o formato .CER, desmarque a opção Sim, exportar a chave privada.
8. Copie o. PFX para a pasta ServerCertificate.cr.
9. Copiar o arquivo .CER para a pasta NCCertificate.cr.
Quando terminar, atualize essas pastas na Biblioteca SCVMM e verifique se você tem
esses certificados copiados. Continue com a Configuração e a Implantação do Modelo
de Serviço do Controlador de Rede.
Autenticando dispositivos e serviços

southbound
A comunicação do Controlador de Rede com hosts e dispositivos SLB MUX usa
certificados para autenticação. A comunicação com os hosts é pelo protocolo OVSDB,
enquanto a comunicação com os dispositivos MUX do SLB é por meio do protocolo
WCF.
Comunicação de host do Hyper-V com o controlador de

rede
Para comunicação com os hosts Hyper-V via OVSDB, o Controlador de Rede precisa
apresentar um certificado aos computadores host. Por padrão, o SCVMM pega o
certificado SSL configurado no Controlador de Rede e o usa para comunicação de
direção sul com os hosts.
Esse é o motivo pelo qual o certificado SSL deve ter o EKU de Autenticação do Cliente
configurado. Esse certificado é configurado no recurso REST "Servidores" (os hosts
Hyper-V são representados no Controlador de Rede como um recurso de servidor) e
podem ser exibidos executando o comando Windows PowerShell Get-
NetworkControllerServer.
Veja a seguir um exemplo parcial do recurso REST do servidor.
"resourceId": "host31.fabrikam.com",
"properties": {
"connections": [
"host31.fabrikam.com"
],
"credential": {
"resourceRef": "/credentials/a738762f-f727-43b5-9c50-
cf82a70221fa"
},
"credentialType": "X509Certificate"
],
Para autenticação mútua, o host Hyper-V também deve ter um certificado para se
comunicar com o Controlador de Rede.
Você pode registrar o certificado de uma AC (Autoridade de Certificação). Se um

certificado baseado em AC não for encontrado no computador host, o SCVMM criará
um certificado autoassinado e o provisionará no computador host.
O Controlador de Rede e os certificados de host do Hyper-V devem ser confiáveis entre

si. O certificado raiz do certificado de host do Hyper-V deve estar presente no
repositório Autoridades de Certificação Raiz Confiáveis do Controlador de Rede para o
Computador Local e vice-versa.
Quando você estiver usando certificados autoassinados, o SCVMM garante que os

certificados necessários estejam presentes no repositório Autoridades de Certificação
Raiz Confiáveis para o Computador Local.
Se você estiver usando certificados baseados em AC para os hosts Hyper-V, precisará

garantir que o certificado raiz da AC esteja presente no repositório Autoridades de
Certificação Raiz Confiáveis do Controlador de Rede para o Computador Local.
Comunicação de software Load Balancer MUX com o

controlador de rede
O MUX (Software Load Balancer Multiplexor) e o Controlador de Rede se comunicam
pelo protocolo WCF, usando certificados para autenticação.
Por padrão, o SCVMM pega o certificado SSL configurado no Controlador de Rede e o

usa para comunicação de direção sul com os dispositivos Mux. Esse certificado é
configurado no recurso REST "NetworkControllerLoadBalancerMux" e pode ser exibido
executando o cmdlet Get-NetworkControllerLoadBalancerMux do PowerShell.
Exemplo de recurso REST do MUX (parcial):
"resourceId": "slbmux1.fabrikam.com",
"properties": {
"connections": [
"slbmux1.fabrikam.com"
],
"credential": {
"resourceRef": "/credentials/a738762f-f727-43b5-9c50-
cf82a70221fa"
},
"credentialType": "X509Certificate"
],
Para autenticação mútua, você também deve ter um certificado nos dispositivos MUX
SLB. Esse certificado é configurado automaticamente pelo SCVMM quando você
implanta o balanceador de carga de software usando o SCVMM.
） Importante
No host e nos nós SLB, é fundamental que o repositório de certificados autoridades

de certificação raiz confiáveis não inclua nenhum certificado em que "Emitido" não
seja o mesmo que "Emitido por". Se isso ocorrer, a comunicação entre o
Controlador de Rede e o dispositivo no sentido sul falhará.
O Controlador de Rede e os certificados MUX SLB devem ser confiáveis uns com os
outros (o certificado raiz do certificado MUX do SLB deve estar presente no repositório
Autoridades de Certificação Raiz Confiáveis do computador controlador de rede e vice-
versa). Quando você estiver usando certificados autoassinados, o SCVMM garante que
os certificados necessários estejam presentes no repositório Autoridades de Certificação
Raiz Confiáveis para o Computador Local.
Renovar certificados do Controlador de
Rede antes que eles expirem
Aplica-se a: Azure Stack HCI, versões 22H2, 21H2 e 20H2; Windows Server 2022 e
Windows Server 2019
Este artigo fornece instruções sobre como renovar ou alterar certificados do

Controlador de Rede antes que eles expirem.
） Importante
Se os certificados do Controlador de Rede já expirarem, não use instruções neste

artigo para renová-los.
Em sua infraestrutura de SDN (Rede Definida por Software), o Controlador de Rede usa
a autenticação baseada em certificado para proteger canais de comunicação
northbound com clientes de gerenciamento e comunicações southbound com
dispositivos de rede, como o software Load Balancer. Os certificados do Controlador de
Rede vêm com um período de validade, após o qual eles se tornam inválidos e não
podem mais ser confiáveis para uso. Você deve renová-los antes que eles expirem.
Para obter informações de visão geral sobre o Controlador de Rede, consulte O que é o
Controlador de Rede?
Quando renovar ou alterar certificados do

Controlador de Rede
Você pode renovar ou alterar certificados do Controlador de Rede quando:
Os certificados estão prestes a expirar. Você pode, de fato, renovar certificados do

Controlador de Rede a qualquer momento antes que eles expirem.
７ Observação
Se você renovar certificados existentes com a mesma chave, você está pronto
e não precisa fazer nada.
Você deseja substituir um certificado autoassinado por um certificado assinado
pela AC (Autoridade de Certificação).
７ Observação
Ao alterar os certificados, verifique se você usa o mesmo nome da entidade

do certificado antigo.
Tipos de certificados do Controlador de Rede

No Azure Stack HCI, cada VM do Controlador de Rede usa dois tipos de certificados:
Certificado REST. Um único certificado para comunicação northbound com clientes

REST (como Windows Admin Center) e comunicação southbound com hosts
Hyper-V e balanceadores de carga de software. Esse mesmo certificado está
presente em todas as VMs do Controlador de Rede. Para renovar certificados REST,
consulte Renovar certificados REST.
Certificado de nó do Controlador de Rede. Um certificado em cada VM do

Controlador de Rede para autenticação entre nós. Para renovar certificados de nó
do Controlador de Rede, consulte Renovar certificados de nó.
２ Aviso
Não deixe que esse certificado expire. Renove-os antes da expiração para evitar
problemas de autenticação. Além disso, não remova nenhum certificado expirado
existente antes de renová-los. Para descobrir a data de validade de um certificado,
consulte Exibir expiração do certificado, abaixo.
Visualizar vencimento do certificado

Use o seguinte cmdlet em cada VM do Controlador de Rede para verificar a data de
validade de um certificado:
PowerShell
Get-ChildItem Cert:\LocalMachine\My | where{$_.Subject -eq "CN=<Certificate-

subject-name>"} | Select-Object NotAfter, Subject
Para obter a expiração de um certificado REST, substitua "Certificate-subject-

name" pelo RestIPAddress ou RestName do Controlador de Rede. Você pode obter
esse valor do Get-NetworkController cmdlet .
Para obter a expiração de um certificado de nó, substitua "Certificate-subject-

name" pelo FQDN (nome de domínio totalmente qualificado) da VM do
Controlador de Rede. Você pode obter esse valor do Get-NetworkController
cmdlet .
Renovar certificados REST

Você usa o certificado REST do Controlador de Rede para:
Comunicação norte com clientes REST

Criptografia de credenciais
Comunicação de direção sul para hosts e VMs de software Load Balancer
Ao atualizar um certificado REST, você deve atualizar os clientes de gerenciamento e os

dispositivos de rede para usar o novo certificado.
Para renovar o certificado REST, conclua as seguintes etapas:
1. Verifique se o certificado nas VMs do Controlador de Rede não expirou antes de

renová-lo. Confira Exibir expiração do certificado.
７ Observação
Se o certificado já tiver expirado, não use estas etapas.
2. Procure o novo certificado e coloque-o no repositório pessoal do computador

local (LocalMachine\My). Se for um certificado autoassinado, coloque-o no
repositório Raiz (LocalMachine\Root) de cada VM do Controlador de Rede. Para
obter informações sobre como criar um novo certificado ou emiti-lo de uma
Autoridade de Certificação, consulte Gerenciar certificados para rede definida pelo
software.
3. Atribua o novo certificado a uma variável:
PowerShell
$cert= Get-ChildItem Cert:\LocalMachine\My | where{$_.Thumbprint -eq "

<thumbprint of the new certificate>"}
4. Copie o certificado para todas as VMs do Controlador de Rede.
5. Forneça permissões de Leitura e Permissão para Autoridade/Serviço de Rede NT

no certificado:
PowerShell
$targetCertPrivKey = $Cert.PrivateKey
$privKeyCertFile = Get-Item -path
"$ENV:ProgramData\Microsoft\Crypto\RSA\MachineKeys\*" | where-object
{$_.Name -eq
$targetCertPrivKey.CspKeyContainerInfo.UniqueKeyContainerName}
$privKeyAcl = Get-Acl $privKeyCertFile
$permission = "NT AUTHORITY\NETWORK SERVICE","Read","Allow"
$accessRule = new-object
System.Security.AccessControl.FileSystemAccessRule $permission
$privKeyAcl.AddAccessRule($accessRule)
Set-Acl $privKeyCertFile.FullName $privKeyAcl
6. (Somente para certificado autoassinado) Copie a chave pública do certificado para

todos os hosts e VMs do Software Load Balancer.
7. Modifique as configurações do Controlador de Rede para usar o novo certificado.
Copiar o certificado para todas as VMs do Controlador de

Rede
Siga estas etapas para copiar um certificado para todas as VMs do Controlador de Rede.
1. Certifique-se de adquirir o novo certificado e colocá-lo no repositório pessoal do

computador local (My – cert:\localmachine\my).
2. Na primeira VM do Controlador de Rede, exporte o certificado para um arquivo

PFX (Troca de Informações Pessoais).
PowerShell
$mypwd = ConvertTo-SecureString -String "<password>" -Force -

AsPlainText
Export-PfxCertificate -FilePath "C:\newpfx.pfx" -Password $mypwd -Cert

$cert
# Here, $cert is the new certificate
3. Em outras VMs do Controlador de Rede, importe o certificado e as chaves privadas

de um arquivo PFX para o repositório de destino:
PowerShell
$mypwd = ConvertTo-SecureString -String "<password>" -Force -

AsPlainText
Import-PfxCertificate -FilePath C:\newpfx.pfx -CertStoreLocation

Cert:\LocalMachine\My -Password $mypwd
# Ensure that you copy the pfx file into the local machine before
importing the cert
Copie a chave pública do certificado para todos os hosts

e VMs do Software Load Balancer (somente para
certificado autoassinado)
Se você estiver usando um certificado autoassinado, coloque-o no repositório raiz do
computador local (LocalMachine\Root) para cada um dos seguintes:
Todas as VMs do Controlador de Rede.

Cada computador host do Azure Stack HCI e VMs de software Load Balancer. Isso
garante que o certificado seja confiável pelas entidades pares.
Aqui está um comando de exemplo para importar a chave pública do certificado que já
foi exportada:
PowerShell
Import-Certificate -FilePath "\\sa18fs\SU1_LibraryShare1\RestCert.cer\" -

CertStoreLocation cert:\localMachine\Root
Modificar as configurações do Controlador de Rede para

usar o novo certificado
Modifique as configurações de nó, cluster e aplicativo do Controlador de Rede para usar
o novo certificado.
Para comunicação norte
Para alterar o certificado que o Controlador de Rede usa para comunicação northbound,
execute o seguinte comando em qualquer uma das VMs do Controlador de Rede:
PowerShell
Set-NetworkController -ServerCertificate \$cert
Para criptografia de credenciais
Para alterar o certificado que o Controlador de Rede usa para criptografar as

credenciais, execute o seguinte comando em qualquer uma das VMs do Controlador de
Rede:
PowerShell
Set-NetworkControllerCluster -CredentialEncryptionCertificate $cert
Para comunicação de direção sul
Para alterar o certificado que o Controlador de Rede usa para se comunicar com hosts e
Balanceadores de Carga de Software, execute o seguinte comando:
PowerShell
$certCred = Get-NetworkControllerCredential -ConnectionUri <REST uri of

deployment> |where-object { $_.properties.type -eq "X509Certificate" }
$certCred[0].Properties.Value ="<Thumbprint of the new certificate>"
New-NetworkControllerCredential -ConnectionUri <REST uri of deployment> -

ResourceId $certCred[0].ResourceId -Properties $certCred[0].Properties -
Force
Renovar certificados de nó
Para renovar o certificado de nó do Controlador de Rede, execute as seguintes etapas
em cada VM do Controlador de Rede:
1. Procure o novo certificado e coloque-o no repositório Pessoal do Computador

Local (LocalMachine\My). Se for um certificado autoassinado, ele também deverá
ser colocado no repositório (LocalMachine\Root) de cada VM do Controlador de
Rede. Para obter informações sobre como criar um novo certificado ou emiti-lo de
uma Autoridade de Certificação, consulte Gerenciar certificados para rede definida
pelo software.
2. Atribua o novo certificado a uma variável:
PowerShell
$cert = Get-ChildItem Cert:\LocalMachine\My | where{$_.Thumbprint -eq "

<thumbprint of the new certificate>"}
3. Forneça permissões de Leitura e Permissão para Autoridade/Serviço de Rede NT

no certificado:
PowerShell
$targetCertPrivKey = $Cert.PrivateKey
$privKeyCertFile = Get-Item -path
"$ENV:ProgramData\Microsoft\Crypto\RSA\MachineKeys\*" | where-object
{$_.Name -eq
$targetCertPrivKey.CspKeyContainerInfo.UniqueKeyContainerName}
$privKeyAcl = Get-Acl $privKeyCertFile
$permission = "NT AUTHORITY\NETWORK SERVICE","Read","Allow"
$accessRule = new-object
System.Security.AccessControl.FileSystemAccessRule $permission
$privKeyAcl.AddAccessRule($accessRule)
Set-Acl $privKeyCertFile.FullName $privKeyAcl
4. Execute o seguinte comando para alterar o certificado do nó:
PowerShell
Set-NetworkControllerNode -Name "<Name of the Network Controller node>"

-NodeCertificate $cert
Kerberos com o nome da entidade de

serviço (SPN)
Windows Server 2019
O Controlador de Rede dá suporte a vários métodos de autenticação para comunicação

com clientes de gerenciamento. Você pode usar a autenticação baseada em Kerberos,
autenticação baseada em certificado X509. Você também tem a opção de não usar
nenhuma autenticação para implantações de teste.
System Center Virtual Machine Manager usa a autenticação baseada em Kerberos. Se

você estiver usando a autenticação baseada em Kerberos, deverá configurar um SPN
(Nome da Entidade de Serviço) para o Controlador de Rede no Active Directory. O SPN
é um identificador exclusivo para a instância de serviço do Controlador de Rede, que é
usada pela autenticação Kerberos para associar uma instância de serviço a uma conta de
logon de serviço. Para obter mais detalhes, consulte Nomes da entidade de serviço.
Configurar nomes de entidade de serviço (SPN)

O Controlador de Rede configura automaticamente o SPN. Tudo o que você precisa
fazer é fornecer permissões para que os computadores controladores de rede registrem
e modifiquem o SPN.
1. No computador do controlador de domínio, inicie Usuários e Computadores do

Active Directory.
2. Selecone Exibir > Avançado.
3. Em Computadores, localize uma das contas de computador do Controlador de

Rede e clique com o botão direito do mouse e selecione Propriedades.
4. Selecione a guia Segurança , clique em Avançado.
5. Na lista, se todas as contas de computador do Controlador de Rede ou um grupo

de segurança com todas as contas de computador do Controlador de Rede não
estiverem listadas, clique em Adicionar para adicioná-la.
6. Para cada conta de computador do Controlador de Rede ou um único grupo de

segurança que contém as contas de computador do Controlador de Rede:
a. Selecione a conta ou o grupo e clique em Editar.
b. Em Permissões, selecione Validar Gravação de servicePrincipalName.
d. Role para baixo e, em Propriedades, selecione:
Ler servicePrincipalName
Gravar servicePrincipalName
e. Clique em OK duas vezes.
7. Repita as etapas 3 a 6 para cada computador controlador de rede.
8. Feche Usuários e Computadores do Active Directory.
Falha ao fornecer permissões para

registro/modificação do SPN
Em uma nova implantação do Windows Server 2019, se você escolher Kerberos para
autenticação de cliente REST e não conceder permissão para nós do Controlador de
Rede registrarem ou modificarem o SPN, as operações REST no Controlador de Rede
falharão impedindo que você gerencie o SDN.
Para uma atualização do Windows Server 2016 para o Windows Server 2019 e você
escolheu Kerberos para autenticação de cliente REST, as operações REST não são
bloqueadas, garantindo transparência para implantações de produção existentes.
Se o SPN não estiver registrado, a autenticação do cliente REST usará NTLM, o que é
menos seguro. Você também obtém um evento crítico no canal Administração do canal
de eventos NetworkController-Framework solicitando que você forneça permissões aos
nós do Controlador de Rede para registrar o SPN. Depois de fornecer permissão, o
Controlador de Rede registrará o SPN automaticamente e todas as operações de cliente
usarão Kerberos.
 Dica
Normalmente, você pode configurar o Controlador de Rede para usar um endereço

IP ou um nome DNS para operações baseadas em REST. No entanto, ao configurar
o Kerberos, você não pode usar um endereço IP para consultas REST no
Controlador de Rede. Por exemplo, você pode usar
<https://networkcontroller.consotso.com>, mas não pode usar
<https://192.34.21.3>. Os Nomes da Entidade de Serviço não poderão funcionar se
os endereços IP forem usados.
Se você estivesse usando o endereço IP para operações REST junto com a

autenticação Kerberos em Windows Server 2016, a comunicação real teria sido
sobre a autenticação NTLM. Nessa implantação, depois de atualizar para o
Windows Server 2019, você continuará a usar a autenticação baseada em NTLM.
Para migrar para a autenticação baseada em Kerberos, você deve usar o nome DNS
do Controlador de Rede para operações REST e fornecer permissão para que os
nós do Controlador de Rede registrem o SPN.
com o PowerShell



PowerShell
PowerShell

７ Observação


de de
origem destino
PowerShell
$aclrules = @()



rede virtual.
 Dica


segurança de rede.
PowerShell


de rede.
PowerShell


adaptador de rede.
PowerShell
$acl
PowerShell


rede.
PowerShell

PowerShell
$null
PowerShell

PowerShell
param(
$Path
mkdir $path -force


syntax
---- ------------- ------ ----
-a---- 7/19/2018 6:28 AM 17055

1bf2f0e0dc4a.20180719TL122803093.json
-a---- 7/19/2018 7:28 AM 7880

1bf2f0e0dc4a.20180719TL132803173.json
-a---- 7/19/2018 8:28 AM 7867

1bf2f0e0dc4a.20180719TL142803264.json
-a---- 7/19/2018 9:28 AM 10949

1bf2f0e0dc4a.20180719TL152803360.json
-a---- 7/19/2018 9:28 AM 0

1bf2f0e0dc4a.20180719TL162803464.json
syntax
"records": [
"properties":{
"Version":"1.0",
"flows":[
"flows":[
{
"flowTuples":
["1531963580,192.122.0.22,192.122.255.255,138,138,U,I,A"],
"portId":"9",
"portName":"7290436D-0422-498A-8EB8-
C6CF5115DACE"
],
},
"time":"20180719:L012620622",
},
syntax
{
"Tags": null,
"Properties": {
"AclRules": [
"ResourceRef":
422b-9038-d1f2390645d7",
"Etag": "W/\"1535a780-0fc8-
"ResourceId":
"AllowAll_Inbound",
"Properties": {
"Protocol":
"All",
"Action":
"Allow",
"Priority":
"101",
"Type":
"Inbound",
"Logging":
"Enabled",
}
},
"ResourceRef":
"InstanceId": "068264c6-2186-
"Etag": "W/\"1535a780-0fc8-
"ResourceId":
"Properties": {
"Protocol":
"All",
"Action":
"Allow",
"Priority":
"110",
"Type":
"Outbound",
"Logging":
"Enabled",
}
],
],
"Subnets": [
"ResourceRef":
"InstanceId": "00000000-0000-
0000-0000-000000000000",
"Etag": null,
"ResourceId": null,
"Properties": null
Próximas etapas

Emparelhamento de rede virtual
O peering de rede virtual permite que você conecte duas redes virtuais perfeitamente.
Uma vez pares, para fins de conectividade, as redes virtuais aparecem como uma.
Os benefícios do uso do emparelhamento de rede virtual incluem:
O tráfego entre máquinas virtuais nas redes virtuais ponto a ponto é roteado por
meio da infraestrutura de backbone apenas por meio de endereços IP privados. A
comunicação entre as redes virtuais não exige a Internet ou gateways públicos.
Baixa latência, conexão com largura de banda alta entre os recursos em redes
virtuais diferentes.
A capacidade de recursos em uma rede virtual para se comunicar com recursos em

uma rede virtual diferente.
Nenhum tempo de inatividade para recursos em nenhuma das redes virtuais ao

criar o peering.
Requisitos e restrições
O peering de rede virtual tem alguns requisitos e restrições:
As redes virtuais de pares devem:
Ter espaços de endereço IP não sobrepostos
Ser gerenciado pelo mesmo controlador de rede
Depois de fazer o par de uma rede virtual com outra rede virtual, você não poderá
adicionar ou excluir intervalos de endereços no espaço de endereço.
 Dica
Se você precisar adicionar intervalos de endereços:
1. Remova o peering.
2. Adicione o espaço de endereço.
3. Adicione o peering novamente.
Como o peering de rede virtual está entre duas redes virtuais, não há nenhuma
relação transitiva derivada entre os pares. Por exemplo, se você fizer o par
virtualNetworkA com virtualNetworkB e virtualNetworkB com virtualNetworkC,
virtualNetworkA não será ponto a ponto com virtualNetworkC.
Conectividade
Depois que você faz o par de redes virtuais, os recursos em qualquer rede virtual podem
se conectar diretamente com recursos na rede virtual peered.
A latência de rede entre máquinas virtuais em redes virtuais peered é a mesma que
a latência em uma única rede virtual.
A produtividade da rede é baseada na largura de banda permitida para a máquina

virtual. Não existe restrição adicional quanto à largura de banda no
emparelhamento.
O tráfego entre máquinas virtuais em redes virtuais pares é roteado diretamente

por meio da infraestrutura de backbone, não por meio de um gateway ou pela
Internet pública.
As máquinas virtuais em uma rede virtual podem acessar o balanceador de carga

interno na rede virtual peered.
Você pode aplicar ACLs (listas de controle de acesso) em qualquer rede virtual para
bloquear o acesso a outras redes virtuais ou sub-redes, se desejado. Se você abrir a
conectividade completa entre redes virtuais ponto a ponto (que é a opção padrão),
poderá aplicar ACLs a sub-redes ou máquinas virtuais específicas para bloquear ou
negar acesso específico. Para saber mais sobre ACLs, consulte Usar ACLs (listas de
controle de acesso) para gerenciar o tráfego de rede do datacenter Flow.
Encadeamento de serviços
Você pode configurar rotas definidas pelo usuário que apontam para máquinas virtuais
em redes virtuais pares como o endereço IP do próximo salto, para habilitar o
encadeamento de serviço. O encadeamento de serviço permite direcionar o tráfego de
uma rede virtual para uma dispositivo virtual, em uma rede virtual em pares, por meio
de rotas definidas pelo usuário.
Você pode implantar redes hub-spoke, em que a rede virtual do hub pode hospedar
componentes de infraestrutura, como uma dispositivo de rede virtual. Todas as redes
virtuais do spoke são emparelhadas com a rede virtual do hub. O tráfego pode fluir por
meio de dispositivos de virtualização de rede na rede virtual do hub.
O peering de rede virtual permite que o próximo salto em uma rota definida pelo
usuário seja o endereço IP de uma máquina virtual na rede virtual peered. Para saber
mais sobre rotas definidas pelo usuário, consulte Usar dispositivos de virtualização de
rede em uma rede virtual.
Gateways e conectividade local

Cada rede virtual, independentemente de estar em pares com outra rede virtual, ainda
pode ter seu próprio gateway para se conectar a uma rede local. Ao fazer o par de redes
virtuais, você também pode configurar o gateway na rede virtual peered como um
ponto de trânsito para uma rede local. Nesse caso, a rede virtual que usa um gateway
remoto não pode ter seu próprio gateway. Uma rede virtual pode ter apenas um
gateway que pode ser um gateway local ou remoto (na rede virtual peered).
Monitoramento
Ao fazer o par de duas redes virtuais, você deve configurar um peering para cada rede
virtual no peering.
Você pode monitorar o status da conexão de peering, que pode estar em um dos
seguintes estados:
Iniciado: Mostrado quando você cria o peering da primeira rede virtual para a
segunda rede virtual.
Conectado: Mostrado depois de criar o peering da segunda rede virtual para a

primeira rede virtual. O estado de emparelhamento da primeira rede virtual muda
de Iniciado para Conectado. Ambos os pares de rede virtual devem ter o estado
Conectado antes de estabelecer um par de rede virtual com êxito.
Desconectado: Mostrado se uma rede virtual se desconecta de outra rede virtual.
[infográfico dos estados]
Próximas etapas
Configurar o peering de rede virtual: neste procedimento, você usa o Windows
PowerShell para encontrar a rede lógica do provedor de HNV para criar duas redes
virtuais, cada uma com uma sub-rede. Você também configura o peering entre as duas
redes virtuais.
Configure emparelhamento de rede
virtual
Neste procedimento, você usa o Windows PowerShell para criar duas redes virtuais,
cada uma com uma sub-rede. Em seguida, configure o peering entre as duas redes
virtuais para habilitar a conectividade entre elas.
Etapa 1. Criar sua primeira rede virtual
Etapa 2. Criar a segunda rede virtual
Etapa 3. Configurar o peering da primeira rede virtual para a segunda rede virtual
Etapa 4. Configurar o peering da segunda rede virtual para a primeira rede virtual
） Importante
Lembre-se de atualizar as propriedades do seu ambiente.
Etapa 1. Criar sua primeira rede virtual

Nesta etapa, você usa Windows PowerShell a rede lógica do provedor de HNV para criar
a primeira rede virtual com uma sub-rede. O script de exemplo a seguir cria a rede
virtual da Contoso com uma sub-rede.
PowerShell
#Find the HNV Provider Logical Network
$logicalnetworks = Get-NetworkControllerLogicalNetwork -ConnectionUri $uri
foreach ($ln in $logicalnetworks) {
if ($ln.Properties.NetworkVirtualizationEnabled -eq "True") {
$HNVProviderLogicalNetwork = $ln
$vsubnet.ResourceId = "Contoso"
$uri=”https://restserver”

Etapa 2. Criar a segunda rede virtual

Nesta etapa, você cria uma segunda rede virtual com uma sub-rede. O script de
exemplo a seguir cria a rede virtual do Woodgrove com uma sub-rede.
PowerShell
$vsubnet.ResourceId = "Woodgrove"
$uri=”https://restserver”
New-NetworkControllerVirtualNetwork -ResourceId "Woodgrove_VNet1" -

Etapa 3. Configurar o peering da primeira rede

virtual para a segunda rede virtual
Nesta etapa, você configura o peering entre a primeira rede virtual e a segunda rede
virtual criada nas duas etapas anteriores. O script de exemplo a seguir estabelece o
peering de rede virtual Contoso_vnet1 para Woodgrove_vnet1.
PowerShell
$peeringProperties = New-Object
Microsoft.Windows.NetworkController.VirtualNetworkPeeringProperties
$vnet2 = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId

"Woodgrove_VNet1"
$peeringProperties.remoteVirtualNetwork = $vnet2
#Indicate whether communication between the two virtual networks
$peeringProperties.allowVirtualnetworkAccess = $true
#Indicates whether forwarded traffic is allowed across the vnets
$peeringProperties.allowForwardedTraffic = $true
#Indicates whether the peer virtual network can access this virtual networks
gateway
$peeringProperties.allowGatewayTransit = $false
#Indicates whether this virtual network uses peer virtual networks gateway
$peeringProperties.useRemoteGateways =$false
New-NetworkControllerVirtualNetworkPeering -ConnectionUri $uri -

VirtualNetworkId “Contoso_vnet1” -ResourceId “ContosotoWoodgrove” -
Properties $peeringProperties
） Importante
Depois de criar esse peering, o status da vnet mostra Iniciado.
Etapa 4. Configurar o peering da segunda rede

virtual para a primeira rede virtual
Nesta etapa, você configura o peering entre a segunda rede virtual e a primeira rede
virtual criada nas etapas 1 e 2 acima. O script de exemplo a seguir estabelece o peering
de rede virtual Woodgrove_vnet1 para Contoso_vnet1.
PowerShell
$peeringProperties = New-Object
Microsoft.Windows.NetworkController.VirtualNetworkPeeringProperties
$vnet2=Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId

"Contoso_VNet1"
$peeringProperties.remoteVirtualNetwork = $vnet2
# Indicates whether communication between the two virtual networks is

allowed
$peeringProperties.allowVirtualnetworkAccess = $true
# Indicates whether forwarded traffic will be allowed across the vnets
$peeringProperties.allowForwardedTraffic = $true
# Indicates whether the peer virtual network can access this virtual
network's gateway
$peeringProperties.allowGatewayTransit = $false
# Indicates whether this virtual network will use peer virtual network's
gateway
$peeringProperties.useRemoteGateways =$false
New-NetworkControllerVirtualNetworkPeering -ConnectionUri $uri -

VirtualNetworkId “Woodgrove_vnet1” -ResourceId “WoodgrovetoContoso” -
Properties $peeringProperties
Depois de criar esse peering, o status de peering vnet mostra Conectado para ambos os
pares. Agora, as máquinas virtuais em uma rede virtual podem se comunicar com
máquinas virtuais na rede virtual peered.
Desempenho do Gateway do Windows
Server 2019
21H2 e 20H2
Em Windows Server 2016, uma das preocupações do cliente era a incapacidade do

gateway de SDN de atender aos requisitos de taxa de transferência das redes modernas.
A taxa de transferência de rede de túneis IPsec e GRE tinha limitações com a taxa de
transferência de conexão única para conectividade IPsec de cerca de 300 Mbps e para
conectividade GRE sendo de cerca de 2,5 Gbps.
Melhoramos significativamente no Windows Server 2019, com os números subindo para

1,8 Gbps e 15 Gbps para conexões IPsec e GRE, respectivamente. Tudo isso, com
reduções significativas nos ciclos de CPU/por byte, fornecendo assim uma taxa de
transferência de desempenho ultra-alto com muito menos utilização da CPU.
Habilitar alto desempenho com gateways no

Windows Server 2019
Para conexões GRE, depois de implantar/atualizar para builds do Windows Server 2019
nas VMs de gateway, você deverá ver automaticamente o desempenho aprimorado.
Nenhuma etapa manual está envolvida.
Para conexões IPsec, por padrão, ao criar a conexão para suas redes virtuais, você
obtém o caminho de dados Windows Server 2016 e os números de desempenho. Para
habilitar o caminho de dados do Windows Server 2019, faça o seguinte:
1. Em uma VM de gateway SDN, acesse Console de serviços (services.msc).

2. Localize o serviço chamado Serviço de Gateway do Azure e defina o tipo de
inicialização como Automático.
3. Reinicie a VM do gateway.
As conexões ativas nesse gateway fazem failover para
uma VM de gateway redundante.
4. Repita as etapas anteriores para o restante das VMs do gateway.
 Dica
Para obter os melhores resultados de desempenho, verifique se
cipherTransformationConstant e authenticationTransformConstant nas
configurações quickMode da conexão IPsec usa o conjunto de criptografias
GCMAES256 .
Para obter o desempenho máximo, o hardware do host do gateway deve dar

suporte a conjuntos de instruções de CPU AES-NI e PCLMULQDQ. Eles estão
disponíveis em qualquer CPU da Intel westmere (32nm) e posterior, exceto em
modelos em que o AES-NI foi desabilitado. Você pode examinar a documentação
do fornecedor de hardware para ver se a CPU dá suporte a conjuntos de instruções
de CPU AES-NI e PCLMULQDQ.
Veja abaixo um exemplo rest de conexão IPsec com algoritmos de segurança ideais:
PowerShell
# NOTE: The virtual gateway must be created before creating the IPsec
connection. More details here.
# Create a new object for Tenant Network IPsec Connection
$nwConnectionProperties.ConnectionType = "IPSec"
$nwConnectionProperties.IpSecConfiguration = New-Object
$nwConnectionProperties.IpSecConfiguration.AuthenticationMethod = "PSK"
$nwConnectionProperties.IpSecConfiguration.SharedSecret = "111_aaa"
$nwConnectionProperties.IpSecConfiguration.QuickMode = New-Object
$nwConnectionProperties.IpSecConfiguration.QuickMode.PerfectForwardSecrecy =
"PFS2048"
$nwConnectionProperties.IpSecConfiguration.QuickMode.AuthenticationTransform
ationConstant = "GCMAES256"
$nwConnectionProperties.IpSecConfiguration.QuickMode.CipherTransformationCon
stant = "GCMAES256"
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeSeconds =
3600
$nwConnectionProperties.IpSecConfiguration.QuickMode.IdleDisconnectSeconds =
500
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeKiloBytes =
2000
$nwConnectionProperties.IpSecConfiguration.MainMode = New-Object
$nwConnectionProperties.IpSecConfiguration.MainMode.DiffieHellmanGroup =
"Group2"
$nwConnectionProperties.IpSecConfiguration.MainMode.IntegrityAlgorithm =
"SHA256"
$nwConnectionProperties.IpSecConfiguration.MainMode.EncryptionAlgorithm =
"AES256"
$nwConnectionProperties.IpSecConfiguration.MainMode.SALifeTimeSeconds =
28800
$nwConnectionProperties.IpSecConfiguration.MainMode.SALifeTimeKiloBytes =
2000
# L3 specific configuration (leave blank for IPSec)
# Update the IPv4 Routes that are reachable over the site-to-site VPN Tunnel
$ipv4Route.DestinationPrefix = "<<On premise subnet that must be reachable

over the VPN tunnel. Ex: 10.0.0.0/24>>"
$nwConnectionProperties.DestinationIPAddress = "<<Public IP address of the

On-Premise VPN gateway. Ex: 192.168.3.4>>"
# Add the new Network Connection for the tenant. Note that the virtual
gateway must be created before creating the IPsec connection. $uri is the
REST URI of your deployment and must be in the form of “https://<REST URI>”
New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -

VirtualGatewayId $virtualGW.ResourceId -ResourceId "Contoso_IPSecGW" -
Properties $nwConnectionProperties -Force
Resultados de teste
Fizemos testes de desempenho extensivos para os gateways de SDN em nossos
laboratórios de teste. Nos testes, comparamos o desempenho de rede do gateway com
o Windows Server 2019 em cenários de SDN e cenários não SDN. Você pode encontrar
os resultados e os detalhes da configuração de teste capturados no artigo do blog
aqui .
Alocação de largura de banda de
gateway
22H2, 21H2 e 20H2
Em Windows Server 2016, a largura de banda de túnel individual para IPsec, GRE e L3 foi
uma proporção da capacidade total do gateway. Portanto, os clientes forneceriam a
capacidade do gateway com base na largura de banda TCP padrão que esperava isso
fora da VM do gateway.
Além disso, a largura de banda máxima do túnel IPsec no gateway foi limitada a
(3/20)*Capacidade de gateway fornecida pelo cliente. Portanto, por exemplo, se você
definir a capacidade do gateway como 1000 Mbps, a capacidade do túnel IPsec será de
150 Mbps. As taxas equivalentes para túneis GRE e L3 são 1/5 e 1/2, respectivamente.
Embora isso tenha funcionado para a maioria das implantações, o modelo de taxa fixa
não era apropriado para ambientes de alta taxa de transferência. Mesmo quando as
taxas de transferência de dados eram altas (digamos, mais de 40 Gbps), a taxa de
transferência máxima de túneis de gateway de SDN foi limitada devido a fatores
internos.
No Windows Server 2019, para um tipo de túnel, a taxa de transferência máxima é fixa.
Mesmo que o host/VM do gateway dê suporte a NICs com taxa de transferência muito
maior, a taxa de transferência máxima de túnel disponível é fixa. Outro problema que
isso cuida é o excesso de provisionamento arbitrário de gateways, o que acontece ao
fornecer um número muito alto para a capacidade do gateway.
A taxa de transferência máxima disponível para diferentes tipos de túnel é:
IPsec = 5 Gbps
GRE = 15 Gbps
L3 = 5 Gbps
７ Observação
Por padrão, a alocação de largura de banda IPsec usa Windows Server 2016
comportamento descrito posteriormente neste artigo. Para obter a taxa de
transferência máxima (5 Gbps), siga estas etapas em cada VM de gateway:
1. Execute o seguinte comando para habilitar o serviço de gateway:
PowerShell
Set-Service gatewayservice -StartupType Automatic -Status Running
2. Reinicie a VM do gateway.
Cálculo de capacidade do gateway

O ideal é definir a capacidade de taxa de transferência do gateway como a taxa de
transferência disponível para a VM do gateway. Portanto, por exemplo, se você tiver
uma única VM de gateway e a taxa de transferência nic do host subjacente for de 25
Gbps, a taxa de transferência do gateway também poderá ser definida como 25 Gbps.
Se estiver usando um gateway somente para conexões IPsec, a capacidade fixa máxima
disponível será de 5 Gbps. Portanto, por exemplo, se você provisionar conexões IPsec no
gateway, só poderá provisionar para uma largura de banda agregada (entrada + saída)
como 5 Gbps.
Se estiver usando o gateway para conectividade IPsec e GRE, você poderá provisionar
no máximo 5 Gbps de taxa de transferência IPsec ou no máximo 15 Gbps de taxa de
transferência GRE. Portanto, por exemplo, se você provisionar 2 Gbps de taxa de
transferência IPsec, terá 3 Gbps de taxa de transferência IPsec restantes para provisionar
no gateway ou 9 Gbps de taxa de transferência GRE restantes.
Para colocar isso em termos mais matemáticos:
Capacidade total do gateway = 25 Gbps
Capacidade total de IPsec disponível = 5 Gbps (fixo)
Capacidade total de GRE disponível = 15 Gbps (fixo)
Taxa de transferência de IPsec para esse gateway = 25/5 = 5 Gbps
Taxa de transferência de GRE para esse gateway = 25/15 = 5/3 Gbps
Por exemplo, se você alocar 2 Gbps de taxa de transferência IPsec para um cliente:
Capacidade restante disponível no gateway = Capacidade total do gateway – taxa de

transferência IPsec*Taxa de transferência IPsec alocada (capacidade usada)
25–5*2 = 15 Gbps
Taxa de transferência IPsec restante que você pode alocar no gateway
5-2 = 3 Gbps
Taxa de transferência GRE restante que você pode alocar no gateway = Capacidade
restante da taxa de transferência de gateway/GRE
15*3/5 = 9 Gbps
A taxa de transferência varia dependendo da capacidade total do gateway. Uma coisa a

observar é que você deve definir a capacidade total para a largura de banda TCP
disponível para a VM do gateway. Se você tiver várias VMs hospedadas no gateway,
deverá ajustar a capacidade total do gateway adequadamente.
Além disso, se a capacidade do gateway for menor que a capacidade total de túnel
disponível, a capacidade total de túnel disponível será definida como a capacidade do
gateway. Por exemplo, se você definir a capacidade do gateway como 4 Gbps, a
capacidade total disponível para IPsec, L3 e GRE será definida como 4 Gbps, deixando a
taxa de taxa de transferência para cada túnel como 1 Gbps.
Windows Server 2016 comportamento

O algoritmo de cálculo de capacidade do gateway para Windows Server 2016
permanece inalterado. Em Windows Server 2016, a largura de banda máxima do túnel
IPsec era limitada à (3/20)*capacidade do gateway em um gateway. As taxas
equivalentes para túneis GRE e L3 foram de 1/5 e 1/2, respectivamente.
Se você estiver atualizando do Windows Server 2016 para o Windows Server 2019:
1. Túneis GRE e L3: A lógica de alocação do Windows Server 2019 entra em vigor
depois que os nós do Controlador de Rede são atualizados para o Windows Server
2019
2. Túneis IPSec: A lógica de alocação do gateway Windows Server 2016 continua

funcionando até que todos os gateways no pool de gateway sejam atualizados
para o Windows Server 2019. Para todos os gateways no pool de gateway, você
deve definir o serviço de gateway do Azure como Automático.
７ Observação
É possível que, após a atualização para o Windows Server 2019, um gateway se

torne superprovisionado (à medida que a lógica de alocação muda de Windows
Server 2016 para o Windows Server 2019). Nesse caso, as conexões existentes no
gateway continuam a existir. O recurso REST para o Gateway lança um aviso de que
o gateway está superprovisionado. Nesse caso, você deve mover algumas conexões
para outro gateway.
Os tópicos desta seção fornecem informações sobre como solucionar problemas das
tecnologias de SDN (Rede Definida por Software) incluídas no Azure Stack HCI,
Windows Server 2019 e Windows Server 2016.
７ Observação
Para documentação adicional de Rede Definida pelo Software, você pode usar as
Tecnologias SDN
Planejar O SDN
Implantar SDN
Gerenciar SDN
Segurança para SDN
Solucionar problemas de pilha de rede definida pelo software do Windows Server

Solução de problemas de SDN de postagem no blog: falhas de comunicação UDP
e alteração do certificado do controlador de rede
Postagem no blog Solução de problemas de certificado no SDN (Rede Definida
pelo Software)
Postagem no blog Como localizar o endereço local do gateway SDN para
emparelhamento BGP no Windows Server 2016
Postagem no blog Solução de problemas de configuração das configurações de
largura de banda de VPN do Gateway de RAS do SDN no Virtual Machine Manager
Solucionar problemas de pilha de rede
definida do Windows Server Software
Este guia examina os erros comuns de SDN (Rede Definida por Software) e cenários de
falha e descreve um fluxo de trabalho de solução de problemas que usa as ferramentas
de diagnóstico disponíveis.
Para obter mais informações sobre o SDN, consulte Rede Definida pelo Software.
Tipos de erro
A lista a seguir representa a classe de problemas mais frequentemente visto com
Virtualização de Rede Hyper-V (HNVv1) no Windows Server 2012 R2 de implantações de
produção no mercado e coincide de várias maneiras com os mesmos tipos de
problemas vistos em Windows Server 2016 HNVv2 com a nova pilha SDN (Rede
Definida por Software).
A maioria dos erros pode ser classificada em um pequeno conjunto de classes:
Configuração inválida ou sem suporte Um usuário invoca a API NorthBound

incorretamente ou com uma política inválida.
Erro no aplicativo de política A política do Controlador de Rede não foi entregue

a um host Hyper-V, atrasada ou não atualizada em todos os hosts Hyper-V (por
exemplo, após uma Migração Dinâmica).
Descompasso de configuração ou bug de software Problemas de caminho de

dados que resultam em pacotes descartados.
Erro externo relacionado ao hardware/drivers nic ou à malha de rede de

subposição Descarregamentos de tarefas mal comportados (como VMQ) ou malha
de rede de subposição configurada incorretamente (como MTU)
Este guia de solução de problemas examina cada uma dessas categorias de erro e
recomenda as melhores práticas e ferramentas de diagnóstico disponíveis para
identificar e corrigir o erro.
Ferramentas de diagnóstico
Antes de discutir os fluxos de trabalho de solução de problemas para cada um desses
tipos de erros, vamos examinar as ferramentas de diagnóstico disponíveis.
Para usar as ferramentas de diagnóstico do Controlador de Rede (caminho de controle),

primeiro você deve instalar o recurso RSAT-NetworkController e importar o
NetworkControllerDiagnostics módulo:
PowerShell
Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics
Para usar as ferramentas de diagnóstico de diagnóstico HNV (caminho de dados), você

deve importar o HNVDiagnostics módulo:
PowerShell
# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics
Diagnóstico do controlador de rede

Esses cmdlets são documentados no TechNet no Tópico do Cmdlet de Diagnóstico do
Controlador de Rede. Eles ajudam a identificar problemas com a consistência da política
de rede no caminho de controle entre nós do Controlador de Rede e entre o
Controlador de Rede e os Agentes host NC em execução nos hosts Hyper-V.
Os cmdlets Debug-ServiceFabricNodeStatus e Get-NetworkControllerReplica devem ser

executados em uma das máquinas virtuais do nó controlador de rede. Todos os outros
cmdlets de diagnóstico NC podem ser executados a partir de qualquer host, que tem
conectividade com o Controlador de Rede e está no grupo de segurança de
Gerenciamento de Controlador de Rede (Kerberos) ou tem acesso ao certificado X.509
para gerenciar o Controlador de Rede.
Diagnóstico de host do Hyper-V

Esses cmdlets são documentados no TechNet no Tópico de Cmdlet de Diagnóstico do
Virtualização de Rede Hyper-V (HNV). Eles ajudam a identificar problemas no caminho
de dados entre máquinas virtuais de locatário (Leste/Oeste) e tráfego de entrada por
meio de um VIP SLB (Norte/Sul).
O Debug-VirtualMachineQueueOperation, Get-CustomerRoute, Get-PACAMapping, Get-
ProviderAddress, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortId e Test-
EncapOverheadSettings são todos os testes locais que podem ser executados em
qualquer host Hyper-V. Os outros cmdlets invocam testes de caminho de dados por
meio do Controlador de Rede e, portanto, precisam de acesso ao Controlador de Rede,
conforme descrito acima.
GitHub
O Microsoft/SDN GitHub Repo tem muitos scripts de exemplo e fluxos de trabalho
que se baseiam nesses cmdlets in-box. Em particular, scripts de diagnóstico podem ser
encontrados na pasta Diagnóstico . Ajude-nos a contribuir para esses scripts enviando
solicitações de pull.
Solução de problemas de fluxos de trabalho e

guias
[Hoster] Validar a integridade do sistema

Há um recurso inserido chamado Estado de Configuração em vários recursos do
Controlador de Rede. O estado de configuração fornece informações sobre a
integridade do sistema, incluindo a consistência entre a configuração do controlador de
rede e o estado real (em execução) nos hosts Hyper-V.
Para verificar o estado de configuração, execute o seguinte em qualquer host Hyper-V

com conectividade com o Controlador de Rede.
７ Observação
O valor do parâmetro NetworkController deve ser o FQDN ou o endereço IP com

base no nome da entidade do certificado X.509 >criado para o Controlador de
Rede.
O parâmetro Credencial só precisa ser especificado se o controlador de rede estiver

usando a autenticação Kerberos (típica em implantações do VMM). A credencial
deve ser para um usuário que esteja no Grupo de Segurança de Gerenciamento do
Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP>
[-Credential <PS Credential>]
# Healthy State Example - no status reported
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211

-Credential $cred
Fetching ResourceType: accessControlLists
Fetching ResourceType: virtualNetworks
Fetching ResourceType: networkInterfaces
Fetching ResourceType: virtualGateways
Fetching ResourceType: loadbalancerMuxes
Fetching ResourceType: Gateways
Uma mensagem de estado de configuração de exemplo é mostrada abaixo:
----------------------------------------------------------------------------
-----------------------------
ResourcePath: https://10.127.132.211/Networking/v1/servers/4c4c4544-
0056-4b10-8058-b8c04f395931
Status: Warning
Source: SoftwareLoadBalancerManager
Code: HostNotConnectedToController
Message: Host is not Connected.
----------------------------------------------------------------------------
------------------------------
７ Observação
Há um bug no sistema em que os recursos da Interface de Rede para a NIC da VM

de Trânsito do SLB Mux estão em um estado de falha com o erro "Comutador
Virtual – Host Não Conectado ao Controlador". Esse erro poderá ser ignorado com
segurança se a configuração de IP no recurso NIC da VM estiver definida como um
endereço IP do pool de IP da Rede Lógica de Trânsito.
Há um segundo bug no
sistema em que os recursos da Interface de Rede para as NICs de VM do Provedor
de HNV de Gateway estão em um estado de falha com o erro "Comutador Virtual –
PortBlocked". Esse erro também poderá ser ignorado com segurança se a
configuração de IP no recurso NIC da VM estiver definida como nula (por design).
A tabela a seguir mostra a lista de códigos de erro, mensagens e ações de
acompanhamento a serem executadas com base no estado de configuração observado.
Código Mensagem Ação
Unknown (desconhecido) Erro desconhecido
HostUnreachable O computador Verificar a conectividade de rede de

host não é gerenciamento entre o controlador
acessível de rede e o host
PAIpAddressExhausted Os endereços IP Aumentar o tamanho do pool de IP

de PA esgotados do provedor HNV
PAMacAddressExhausted Os endereços Mac Aumentar o intervalo do Pool de

pa esgotados Mac
PAAddressConfigurationFailure Falha ao enviar Verifique a conectividade de rede

endereços pa para de gerenciamento entre o
o host Controlador de Rede e o Host.
CertificateNotTrusted O certificado não é Corrija os certificados usados para

confiável comunicação com o host.
CertificateNotAuthorized Certificado não Corrija os certificados usados para

autorizado comunicação com o host.
PolicyConfigurationFailureOnVfp Falha na Esta é uma falha de runtime.

configuração de Nenhuma solução alternativa
políticas VFP definitiva. Coletar logs.
PolicyConfigurationFailure Falha ao enviar Nenhuma ação definitiva. Isso

políticas por push ocorre devido a uma falha no
para os hosts, processamento de estado de meta
devido a falhas de nos módulos do Controlador de
comunicação ou Rede. Coletar logs.
outros erros no
NetworkController.
HostNotConnectedToController O Host ainda não O Perfil de Porta não aplicado no

está conectado ao host ou no host não pode ser
Controlador de acessado pelo Controlador de
Rede Rede. Valide se a chave do registro
HostID corresponde à ID da
instância do recurso do servidor
MultipleVfpEnabledSwitches Há vários Exclua uma das opções, uma vez

Comutadores que o Agente host do Controlador
habilitados para de Rede dá suporte apenas a um
VFp no host vSwitch com a extensão VFP
habilitada
PolicyConfigurationFailure Falha ao enviar por Verifique se os certificados

push políticas de apropriados foram implantados (o
VNet para uma nome da entidade do certificado
VmNic devido a deve corresponder ao FQDN do
erros de host). Verifique também a
certificado ou de conectividade do host com o
conectividade Controlador de Rede
PolicyConfigurationFailure Falha ao enviar por Verifique se os certificados

push políticas apropriados foram implantados (o
vSwitch para uma nome da entidade do certificado
VmNic devido a deve corresponder ao FQDN do
erros de host). Verifique também a
certificado ou conectividade do host com o
erros de Controlador de Rede
conectividade
PolicyConfigurationFailure Falha ao fazer Verifique se os certificados

push de políticas apropriados foram implantados (o
de firewall para nome da entidade do certificado
uma VmNic devido deve corresponder ao FQDN do
a erros de host). Verifique também a
certificado ou de conectividade do host com o
conectividade Controlador de Rede
DistributedRouterConfigurationFailure Falha ao definir as Erro de pilha TCPIP. Pode exigir a

configurações do limpeza dos vNICs de host de PA e
roteador DR no servidor no qual esse erro
distribuído no host foi relatado
vNic
DhcpAddressAllocationFailure Falha na alocação Verificar se o atributo de endereço

de endereço DHCP IP estático está configurado no
para uma VMNic recurso NIC
CertificateNotTrusted
Falha ao se Verifique o código numérico
CertificateNotAuthorized conectar ao Mux fornecido no código da mensagem
devido a erros de de erro: isso corresponde ao
rede ou certificado código de erro winsock. Os erros
de certificado são granulares (por
exemplo, o certificado não pode
ser verificado, certificado não
autorizado etc.)
HostUnreachable MUX não está O par BGP na opção RRAS

íntegro (o caso (máquina virtual BGP) ou ToR (Top-
comum é of-Rack) é inacessível ou não está
BGPRouter emparelhando com êxito. Verifique
desconectado) as configurações do BGP no
recurso De software Load Balancer
Multiplexer e no par BGP (máquina
virtual ToR ou RRAS)
HostNotConnectedToController O agente host SLB Verifique se o serviço do Agente de

não está Host SLB está em execução;
conectado Consulte os logs do agente host
SLB (execução automática) por
motivos pelos quais, caso o SLBM
(NC) rejeite o certificado
apresentado pelo estado de
execução do agente host mostrará
informações matizadas
PortBlocked A porta VFP está Verifique se há outros erros, o que

bloqueada devido pode fazer com que as políticas
à falta de políticas não sejam configuradas.
de VNET/ACL
Sobrecarregado Loadbalancer MUX Problema de desempenho com o

está MUX
sobrecarregado
RoutePublicationFailure O Loadbalancer Verifique se o MUX tem

MUX não está conectividade com os roteadores
conectado a um BGP e se o emparelhamento BGP
roteador BGP está configurado corretamente
VirtualServerUnreachable O MUX do Verificar a conectividade entre o

Loadbalancer não SLBM e o MUX
está conectado ao
gerenciador SLB
QosConfigurationFailure Falha ao Veja se a largura de banda

configurar suficiente está disponível para
políticas de QOS todas as VMs se a reserva de QOS
for usada
Verificar a conectividade de rede entre o controlador de rede e o

Host do Hyper-V (serviço do Agente de Host NC)
Execute o comando netstat abaixo para validar se há três conexões ESTABELECIDAS
entre o Agente de Host NC e os nós do Controlador de Rede e um soquete LISTENING
no Host do Hyper-V
ESCUTAndo na porta TCP:6640 no host hyper-v (serviço do agente de host NC)

Duas conexões estabelecidas do IP do host Hyper-V na porta 6640 para o IP do nó
NC em portas efêmeras (> 32000)
Uma conexão estabelecida do IP do host Hyper-V na porta efêmera para o IP REST
do controlador de rede na porta 6640
７ Observação
Só poderá haver duas conexões estabelecidas em um host Hyper-V se não houver

máquinas virtuais de locatário implantadas nesse host específico.
netstat -anp tcp |findstr 6640
# Successful output
TCP 0.0.0.0:6640 0.0.0.0:0 LISTENING
TCP 10.127.132.153:6640 10.127.132.213:50095 ESTABLISHED
TCP 10.127.132.153:6640 10.127.132.214:62514 ESTABLISHED
TCP 10.127.132.153:50023 10.127.132.211:6640 ESTABLISHED
Verificar serviços de agente do host
O controlador de rede se comunica com dois serviços de agente de host do Hyper-V:

Agente de Host SLB e Agente de Host NC. É possível que um ou ambos os serviços não
estejam em execução. Verifique seu estado e reinicie se eles não estiverem em
execução.
Get-Service SlbHostAgent
Get-Service NcHostAgent
# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force
Verificar a integridade do controlador de rede

Se não houver três conexões ESTABELECIDAS ou se o Controlador de Rede aparecer sem
resposta, verifique se todos os nós e módulos de serviço estão em execução usando os
cmdlets a seguir.
none
# Prints a DIFF state (status is automatically updated if state is changed)

of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>
Os módulos de serviço do controlador de rede são:
ControllerService
ApiService
SlbManagerService
ServiceInsertion
FirewallService
VSwitchService
GatewayManager
FnmService
HelperService
UpdateService
Check that ReplicaStatus is **Ready** and HealthState is **Ok**.
In a production deployment is with a multi-node Network Controller, you can

also check which node each service is primary on and its individual replica
status.
```powershell
Get-NetworkControllerReplica
# Sample Output for the API service module
Replicas for service: ApiService
ReplicaRole : Primary
NodeName : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready
Verifique se o Status da Réplica está pronto para cada serviço.

Verifique se há hostIDs e certificados correspondentes entre o
controlador de rede e cada host do Hyper-V
Em um host Hyper-V, execute os comandos a seguir para verificar se o HostID

corresponde à ID da Instância de um recurso de servidor no Controlador de Rede
PowerShell
Get-ItemProperty
"hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name
HostId |fl HostId
HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq

"162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}
Tags :
ResourceRef : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties : Microsoft.Windows.NetworkController.ServerProperties
Remediação Se estiver usando scripts SDNExpress ou implantação manual, atualize a

chave HostId no registro para corresponder à ID da Instância do recurso do servidor.
Reinicie o Agente host do Controlador de Rede no host Hyper-V (servidor físico) Se
estiver usando o VMM, exclua o Servidor Hyper-V do VMM e remova a chave do
Registro HostId. Em seguida, adicione novamente o servidor por meio do VMM.
Verifique se as impressões digitais dos certificados X.509 usados pelo host Hyper-V (o
nome do host será o Nome da Entidade do certificado) para comunicação (SouthBound)
entre o host hyper-v (serviço do Agente de Host NC) e os nós do Controlador de Rede
são iguais. Verifique também se o certificado REST do Controlador de Rede tem o nome
da entidade CN=<FQDN ou IP>.
# On Hyper-V Host
dir cert:\\localmachine\my
Thumbprint Subject
---------- -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9 CN=SA18n30-
4.sa18.nttest.microsoft.com
...
dir cert:\\localmachine\root
Thumbprint Subject
---------- -------
30674C020268AA4E40FD6817BA6966531FB9ADA4 CN=10.127.132.211 **# NC REST IP

ADDRESS**
# On Network Controller Node VM
dir cert:\\localmachine\root
Thumbprint Subject
---------- -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9 CN=SA18n30-
4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4 CN=10.127.132.211 **# NC REST IP

ADDRESS**
...
Você também pode verificar os parâmetros a seguir de cada certificado para verificar se
o nome da entidade é o esperado (nome do host ou NC REST FQDN ou IP), o certificado
ainda não expirou e se todas as autoridades de certificado na cadeia de certificados
estão incluídas na autoridade raiz confiável.
Nome do assunto
Data de Validade
Confiável por autoridade raiz
Remediação Se vários certificados tiverem o mesmo nome de assunto no host Hyper-V,

o Agente de Host do Controlador de Rede escolherá aleatoriamente um para apresentar
ao Controlador de Rede. Isso pode não corresponder à impressão digital do recurso do
servidor conhecido pelo Controlador de Rede. Nesse caso, exclua um dos certificados
com o mesmo nome de assunto no host Hyper-V e reinicie o serviço Agente de Host do
Controlador de Rede. Se uma conexão ainda não puder ser feita, exclua o outro
certificado com o mesmo nome de assunto no Host Hyper-V e exclua o recurso de
servidor correspondente no VMM. Em seguida, recrie o recurso de servidor no VMM,
que gerará um novo certificado X.509 e o instalará no host Hyper-V.
Verificar o estado de configuração do SLB
O Estado de Configuração do SLB pode ser determinado como parte da saída para o
cmdlet Debug-NetworkController. Esse cmdlet também produzirá o conjunto atual de
recursos do Controlador de Rede em arquivos JSON, todas as configurações de IP de
cada host do Hyper-V (servidor) e a política de rede local das tabelas de banco de
dados do Agente de Host.
Mais rastreamentos serão coletados por padrão. Para não coletar rastreamentos,
adicione o parâmetro -IncludeTraces:$false.
Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS

Credential>] [-IncludeTraces:$false]
# Don't collect traces
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred

-IncludeTraces:$false
Transcript started, output file is C:\\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes
７ Observação
O local de saída padrão será o <diretório working_directory>\NCDiagnostics\. O

diretório de saída padrão pode ser alterado usando o -OutputDirectory parâmetro.
As informações do Estado de Configuração do SLB podem ser encontradas no arquivo

diagnostics-slbstateResults.Json neste diretório.
Esse arquivo JSON pode ser dividido nas seguintes seções:
Fabric
SlbmVips – Esta seção lista o endereço IP do endereço VIP do Gerenciador SLB,
que é usado pelo Controlador de Rede para coordenar a configuração e a
integridade entre os Muxes SLB e os Agentes de Host SLB.
MuxState – Esta seção listará um valor para cada SLB Mux implantado,
fornecendo o estado do mux
Configuração do roteador – Esta seção listará o NÚMERO do Sistema
Autônomo (ASN) do Roteador Upstream (Par BGP), o Endereço IP de Trânsito e
a ID. Ele também listará o ASN do SLB Muxes e o IP de trânsito.
Informações do Host Conectado – Esta seção listará o endereço IP de
Gerenciamento de todos os hosts Hyper-V disponíveis para executar cargas de
trabalho com balanceamento de carga.
Intervalos Vip – Esta seção listará os intervalos de pools de IP VIP públicos e
privados. O VIP do SLBM será incluído como um IP alocado de um desses
intervalos.
Rotas do Mux – esta seção listará um valor para cada SLB Mux implantado
contendo todos os anúncios de rota para esse mux específico.
Locatário
VipConsolidatedState - Esta seção listará o estado de conectividade para cada
VIP do Locatário, incluindo prefixo de rota anunciado, host Hyper-V e pontos de
extremidade DIP.
７ Observação
O Estado do SLB pode ser apurado diretamente usando o script

DumpSlbRestState disponível no repositório GitHub do SDN da Microsoft .
Validação de gateway
Do Controlador de Rede:
PowerShell
Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface
Na VM do Gateway:
PowerShell
Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation
Na parte superior do rack (ToR) comutador:
sh ip bgp summary (for 3rd party BGP Routers)
Roteador BGP Windows
PowerShell
Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation
Além disso, dos problemas que vimos até agora (especialmente em implantações
baseadas em SDNExpress), o motivo mais comum para o Compartimento de Locatário
não ser configurado em VMs GW parece ser o fato de que a capacidade GW em
FabricConfig.psd1 é menos comparada com o que as pessoas tentam atribuir às
Conexões de Rede (Túneis S2S) em TenantConfig.psd1. Isso pode ser verificado
facilmente comparando as saídas dos seguintes comandos:
PowerShell
PS > (Get-NetworkControllerGatewayPool -ConnectionUri

$uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri

$uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri

$uri -VirtualGatewayId "TenantName").property
[Hoster] Validar Data-Plane

Depois que o Controlador de Rede tiver sido implantado, redes virtuais de locatário e
sub-redes foram criadas e as VMs foram anexadas às sub-redes virtuais, testes de nível
de malha adicionais podem ser realizados pelo hoster para verificar a conectividade do
locatário.
Verificar a conectividade de rede lógica do provedor HNV

Depois que a primeira VM convidada em execução em um host Hyper-V tiver sido
conectada a uma rede virtual de locatário, o Controlador de Rede atribuirá dois
Endereços IP do Provedor HNV (Endereços IP de PA) ao Host hyper-V. Esses IPs virão do
pool de IP da rede lógica do provedor HNV e serão gerenciados pelo Controlador de
Rede. Para descobrir quais são esses dois endereços IP HNV
PowerShell
PS > Get-ProviderAddress
# Sample Output
ProviderAddress : 10.10.182.66
MAC Address : 40-1D-D8-B7-1C-04
Subnet Mask : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN : VLAN11
ProviderAddress : 10.10.182.67
MAC Address : 40-1D-D8-B7-1C-05
Subnet Mask : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN : VLAN11
Esses IPs (Endereços IP do Provedor de HNV) são atribuídos aos Adaptadores Ethernet
criados em um compartimento de rede TCPIP separado e têm um nome de adaptador
de VLANX em que X é a VLAN atribuída à rede lógica do Provedor HNV (transporte).
A conectividade entre dois hosts Hyper-V usando a rede lógica do Provedor de HNV
pode ser feita por um ping com um parâmetro de compartimento adicional (-c Y), em
que Y é o compartimento de rede TCPIP no qual os PAhostVNICs são criados. Esse
compartimento pode ser determinado executando:
C:\> ipconfig /allcompartments /all
<snip> ...
============================================================================
==
Network Information for *Compartment 3*
============================================================================
==
Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...
Ethernet adapter VLAN11:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . :

fe80::5937:a365:d135:2899%39(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 10.10.182.1
NetBIOS over Tcpip. . . . . . . . : Disabled
Ethernet adapter VLAN11:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . :

fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.128
Default Gateway . . . . . . . . . : 10.10.182.1
NetBIOS over Tcpip. . . . . . . . : Disabled
*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...
７ Observação
Os Adaptadores vNIC do host pa não são usados no caminho de dados e, portanto,

não têm um IP atribuído ao "adaptador vEthernet (PAhostVNic)".
Por exemplo, suponha que os hosts Hyper-V 1 e 2 tenham endereços IP pa (provedor de

HNV) de:
Host do Hyper-V Endereço IP pa 1 Endereço IP pa 2
Host 1 10.10.182.64 10.10.182.65
Host 2 10.10.182.66 10.10.182.67
podemos executar ping entre os dois usando o comando a seguir para verificar a
conectividade de rede lógica do Provedor HNV.
# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP

address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64
# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP

C:\> ping -c 3 10.10.182.67 -S 10.10.182.64
# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP

C:\> ping -c 3 10.10.182.66 -S 10.10.182.65
# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP

C:\> ping -c 3 10.10.182.67 -S 10.10.182.65
Remediação Se o ping do provedor HNV não funcionar, verifique sua conectividade de

rede física, incluindo a configuração de VLAN. As NICs físicas em cada host Hyper-V
devem estar no modo tronco sem nenhuma VLAN específica atribuída. O vNIC do Host
de Gerenciamento deve ser isolado para a VLAN da Rede Lógica de Gerenciamento.
PowerShell
PS C:\> Get-NetAdapter "Ethernet 4" |fl
Name : Ethernet 4
InterfaceDescription : <NIC> Ethernet Adapter
InterfaceIndex : 2
MacAddress : F4-52-14-55-BC-21
MediaType : 802.3
PhysicalMediaType : 802.3
InterfaceOperationalStatus : Up
AdminStatus : Up
LinkSpeed(Gbps) : 10
MediaConnectionState : Connected
ConnectorPresent : True
*VlanID : 0*
DriverInformation : Driver Date 2016-08-28 Version 5.25.12665.0

NDIS 6.60
# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set

VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>
VMName VMNetworkAdapterName Mode VlanList
------ -------------------- ---- --------
<snip> ...
Mgmt Access 7
<snip> ...
# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-

VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS
<snip> ...
IsolationMode : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID : 7
MultiTenantStack : Off
ParentAdapter : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate : True
CimSession : CimSession: .
ComputerName : SA18N30-2
IsDeleted : False
<snip> ...
Verificar o suporte a QUADRO MTU e Jumbo na Rede Lógica do

Provedor HNV
Outro problema comum na rede lógica do Provedor HNV é que as portas de rede física
e/ou o cartão Ethernet não têm uma MTU grande o suficiente configurada para lidar
com a sobrecarga do encapsulamento VXLAN (ou NVGRE).
７ Observação
Alguns cartões Ethernet e drivers dão suporte à nova palavra-chave

*EncapOverhead, que será definida automaticamente pelo Agente de Host do
Controlador de Rede como um valor de 160. Esse valor será adicionado ao valor da
palavra-chave *JumboPacket cuja soma é usada como a MTU anunciada.
por
exemplo, *EncapOverhead = 160 e *JumboPacket = 1514 => MTU = 1674B
# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings
Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic.

Encapoverhead value set on the nic is 160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead
value set on the nic is 160
Para testar se a rede lógica do Provedor HNV dá suporte ou não ao tamanho maior de
MTU de ponta a ponta, use o cmdlet Test-LogicalNetworkSupportsJumboPacket :
PowerShell
# Get credentials for both source host and destination host (or use the same
credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential
# Use the Management IP Address or FQDN of the Source and Destination Hyper-
V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -

DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -
DestinationHostCreds $desthostcred
# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with

Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with

Payload: 1472
Checking if physical nics support jumbo packets on host

Cannot send jumbo packets to the destination. Physical switch ports may not
be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host

Cannot send jumbo packets to the destination. Physical switch ports may not
be configured to support jumbo packets.
Remediação
Ajuste o tamanho da MTU nas portas de comutador físico para ter pelo menos
1674B (incluindo cabeçalho e trailer de Ethernet de 14B)
Se o cartão NIC não oferecer suporte à palavra-chave EncapOverhead, ajuste a
palavra-chave JumboPacket para ter pelo menos 1674B
Verificar a conectividade nic da VM do locatário

Cada NIC de VM atribuída a uma VM convidada tem um mapeamento de CA-PA entre o
CA (Endereço do Cliente) privado e o espaço de PA (Endereço do Provedor HNV). Esses
mapeamentos são mantidos nas tabelas do servidor OVSDB em cada host Hyper-V e
podem ser encontrados executando o cmdlet a seguir.
# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping
CA IP Address CA MAC Address Virtual Subnet ID PA IP Address
------------- -------------- ----------------- -------------
10.254.254.2 00-1D-D8-B7-1C-43 4115 10.10.182.67
10.254.254.3 00-1D-D8-B7-1C-43 4115 10.10.182.67
192.168.1.5 00-1D-D8-B7-1C-07 4114 10.10.182.65
10.254.254.1 40-1D-D8-B7-1C-06 4115 10.10.182.66
192.168.1.1 40-1D-D8-B7-1C-06 4114 10.10.182.66
192.168.1.4 00-1D-D8-B7-1C-05 4114 10.10.182.66
７ Observação
Se os mapeamentos ca-PA esperados não forem saída para uma determinada VM

de locatário, verifique os recursos de CONFIGURAção de IP e NIC da VM no
Controlador de Rede usando o cmdlet Get-NetworkControllerNetworkInterface .
Além disso, verifique as conexões estabelecidas entre o Agente de Host NC e os
nós do Controlador de Rede.
Com essas informações, um ping de VM de locatário agora pode ser iniciado pelo
Hoster do Controlador de Rede usando o cmdlet Test-VirtualNetworkConnection .
Cenários específicos de solução de problemas
As seções a seguir fornecem diretrizes para solucionar problemas de cenários
específicos.
Nenhuma conectividade de rede entre duas máquinas

virtuais de locatário
1. [Locatário] Verifique se Windows Firewall em máquinas virtuais de locatário não
está bloqueando o tráfego.
2. [Locatário] Verifique se os endereços IP foram atribuídos à máquina virtual do
locatário executando ipconfig.
3. [Hoster] Execute Test-VirtualNetworkConnection do host Hyper-V para validar a
conectividade entre as duas máquinas virtuais de locatário em questão.
７ Observação
O VSID refere-se à ID da Sub-rede Virtual. No caso da VXLAN, esse é o VNI

(Identificador de Rede VXLAN). Você pode encontrar esse valor executando o
cmdlet Get-PACAMapping .
Exemplo
PowerShell
$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)
Crie ca-ping entre "VM da Web verde 1" com IP SenderCA de 192.168.1.4 no Host
"sa18n30-2.sa18.nttest.microsoft.com" com IP Mgmt de 10.127.132.153 para IP de
ListenerCA de 192.168.1.5, ambos anexados à Sub-rede Virtual (VSID) 4114.
PowerShell
Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-

2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName
"Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP
192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1
Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms
CA Routing Information:
Local IP: 192.168.1.4
Local VSID: 4114
Remote IP: 192.168.1.5
Remote VSID: 4114
Distributed Router Local IP: 192.168.1.1
Distributed Router Local MAC: 40-1D-D8-B7-1C-06
Local CA MAC: 00-1D-D8-B7-1C-05
Remote CA MAC: 00-1D-D8-B7-1C-07
Next Hop CA MAC Address: 00-1D-D8-B7-1C-07
PA Routing Information:
Local PA IP: 10.10.182.66
Remote PA IP: 10.10.182.65
<snip> ...
1. [Locatário] Verifique se não há políticas de firewall distribuídas especificadas nas

interfaces de rede de sub-rede virtual ou VM que bloqueariam o tráfego.
Consulte a API REST do Controlador de Rede encontrada no ambiente de demonstração

em sa18n30nc no domínio sa18.nttest.microsoft.com.
$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri
Examine a configuração de IP e sub-redes

virtuais que estão fazendo referência a essa
ACL
1. [Hoster] Execute Get-ProviderAddress em ambos os hosts Hyper-V que hospedam
as duas máquinas virtuais de locatário em questão e, em seguida, execute Test-
LogicalNetworkConnection ou ping -c <compartment> a partir do host Hyper-V para
validar a conectividade na rede lógica do Provedor HNV
2. [Hoster] Verifique se as configurações de MTU estão corretas nos hosts do Hyper-
V e em qualquer dispositivo de alternância de Camada 2 entre os Hosts do Hyper-
V. Execute Test-EncapOverheadValue em todos os hosts Hyper-V em questão.
Verifique também se todos os comutadores de Camada 2 entre eles têm MTU
definido como pelo menos 1674 bytes para levar em conta a sobrecarga máxima
de 160 bytes.
3. [Hoster] Se os endereços IP de PA não estiverem presentes e/ou a conectividade
de AC estiver interrompida, verifique se a política de rede foi recebida. Execute
Get-PACAMapping para ver se as regras de encapsulamento e os mapeamentos de
AC-PA necessários para criar redes virtuais de sobreposição estão estabelecidos

corretamente.
4. [Hoster] Verifique se o Agente host do Controlador de Rede está conectado ao
Controlador de Rede. Executar netstat -anp tcp |findstr 6640 para ver se o
5. [Hoster] Verifique se a ID do host no HKLM/ corresponde à ID da Instância dos
recursos do servidor que hospedam as máquinas virtuais do locatário.
6. [Hoster] Verifique se a ID do Perfil de Porta corresponde à ID da Instância das
Interfaces de Rede de VM das máquinas virtuais de locatário.
Registro em log, rastreamento e diagnóstico

avançado
As seções a seguir fornecem informações sobre diagnóstico avançado, registro em log e
rastreamento.
Log centralizado do controlador de rede

O Controlador de Rede pode coletar automaticamente logs do depurador e armazená-
los em um local centralizado. A coleção de logs pode ser habilitada quando você
implanta o Controlador de Rede pela primeira vez ou em qualquer momento posterior.
Os logs são coletados do Controlador de Rede e dos elementos de rede gerenciados
pelo Controlador de Rede: computadores host, SLB (balanceadores de carga de
software) e computadores de gateway.
Esses logs incluem logs de depuração para o cluster controlador de rede, o aplicativo
Controlador de Rede, logs de gateway, SLB, rede virtual e o firewall distribuído. Sempre
que um novo host/SLB/gateway é adicionado ao Controlador de Rede, o registro em log
é iniciado nesses computadores.
Da mesma forma, quando um host/SLB/gateway é
removido do Controlador de Rede, o registro em log é interrompido nesses
computadores.
Habilitar o registro em log

O log é habilitado automaticamente quando você instala o cluster controlador de rede
usando o cmdlet Install-NetworkControllerCluster . Por padrão, os logs são coletados
localmente nos nós do Controlador de Rede em %systemdrive%\SDNDiagnostics. É
ALTAMENTE RECOMENDÁVEL que você altere esse local para ser um
compartilhamento de arquivos remoto (não local).
Os logs de cluster do Controlador de Rede são armazenados em

%programData%\Windows Fabric\log\Traces. Você pode especificar um local
centralizado para coleta de logs com o parâmetro DiagnosticLogLocation com a
recomendação de que esse também seja um compartilhamento de arquivos remoto.
Se você quiser restringir o acesso a esse local, poderá fornecer as credenciais de acesso
com o parâmetro LogLocationCredential . Se você fornecer as credenciais para acessar
o local do log, também deverá fornecer o parâmetro CredentialEncryptionCertificate ,
que é usado para criptografar as credenciais armazenadas localmente nos nós do
Com as configurações padrão, é recomendável que você tenha pelo menos 75 GB de

espaço livre no local central e 25 GB nos nós locais (se não estiver usando um local
central) para um cluster do Controlador de Rede de três nós.
Alterar configurações de log

Você pode alterar as configurações de log a qualquer momento usando o Set-
NetworkControllerDiagnostic cmdlet. As seguintes configurações podem ser alteradas:
Local de log centralizado. Você pode alterar o local para armazenar todos os logs,
com o DiagnosticLogLocation parâmetro.
Credenciais para acessar o local do log. Você pode alterar as credenciais para
acessar o local do log, com o LogLocationCredential parâmetro.
Mover para o log local. Se você tiver fornecido o local centralizado para
armazenar logs, poderá voltar ao registro em log localmente nos nós do
Controlador de Rede com o UseLocalLogLocation parâmetro (não recomendado
devido a grandes requisitos de espaço em disco).
Escopo do registro em log. Por padrão, todos os logs são coletados. Você pode
alterar o escopo para coletar somente logs de cluster do Controlador de Rede.
Nível de log. O nível de log padrão é Informativo. Você pode alterá-lo para Erro,
Aviso ou Detalhado.
Tempo de envelhecimento do log. Os logs são armazenados de forma circular.
Você tem três dias de registro em log por padrão, seja usando registro em log
local ou registro em log centralizado. Você pode alterar esse limite de tempo com
o parâmetro LogTimeLimitInDays .
Tamanho do Envelhecimento do Log. Por padrão, você terá um máximo de 75 GB
de dados de log se estiver usando log centralizado e 25 GB se estiver usando o
registro em log local. Você pode alterar esse limite com o parâmetro
LogSizeLimitInMBs .
Coletando logs e rastreamentos
As implantações do VMM usam o log centralizado para o Controlador de Rede por

padrão. O local do compartilhamento de arquivos para esses logs é especificado ao
implantar o modelo de serviço do Controlador de Rede.
Se um local de arquivo não tiver sido especificado, o log local será usado em cada nó
do Controlador de Rede com logs salvos em C:\Windows\tracing\SDNDiagnostics. Esses
logs são salvos usando a seguinte hierarquia:
CrashDumps
NCApplicationCrashDumps
NCApplicationLogs
PerfCounters
SDNDiagnostics
Rastreamentos
O Controlador de Rede usa Service Fabric (Azure). Service Fabric logs podem ser
necessários ao solucionar determinados problemas. Esses logs podem ser encontrados
em cada nó do Controlador de Rede em C:\ProgramData\Microsoft\Service Fabric.
Se um usuário tiver executado o cmdlet Debug-NetworkController , mais logs estarão

disponíveis em cada host Hyper-V, que foi especificado com um recurso de servidor no
Controlador de Rede. Esses logs (e rastreamentos, se habilitados) são mantidos sob
C:\NCDiagnostics
Diagnóstico de SLB
Erros do SLBM Fabric (ações do provedor de serviços de

hospedagem)
1. Verifique se o SLBM (Software Load Balancer Manager) está funcionando e se as

camadas de orquestração podem conversar entre si: SLBM –> SLB Mux e SLBM –>
Agentes host SLB. Execute DumpSlbRestState de qualquer nó com acesso ao
ponto de extremidade REST do Controlador de Rede.
2. Valide o SDNSLBMPerfCounters no PerfMon em uma das VMs de nó do
Controlador de Rede (preferencialmente o nó principal do Controlador de Rede –
Get-NetworkControllerReplica):
a. O mecanismo Load Balancer (LB) está conectado ao SLBM? (SLBM LBEngine
Configurations Total> 0)
b. O SLBM pelo menos sabe sobre seus próprios pontos de extremidade? (Pontos
de extremidade VIP Total>= 2)
c. Os hosts HYPER-V (DIP) estão conectados ao SLBM? (Clientes HP conectados ==
num servers)
d. O SLBM está conectado a Muxes? (Muxes Connected == Muxes Healthy no SLBM
== Muxes relatando íntegro = # VMs SLB Muxes).
3. Verifique se o roteador BGP configurado está emparelhando com êxito com o SLB
MUX
a. Se estiver usando RRAS com Acesso Remoto (ou seja, máquina virtual BGP):
i. Get-BgpPeer deve mostrar conectado
ii. Get-BgpRouteInformation deve mostrar pelo menos uma rota para o SLBM
auto VIP
b. Se estiver usando o comutador de ToR (Top-of-Rack) físico como par BGP,
consulte sua documentação
i. Por exemplo: # mostrar instância bgp
4. Validar os contadores SlbMuxPerfCounters e SLBMUX no PerfMon na VM do SLB
Mux
5. Verificar o estado de configuração e os intervalos VIP no Recurso do Gerenciador
de Load Balancer software
a. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://
FQDN ou IP>| convertto-json -depth 8 (verifique os intervalos VIP em pools de
IP e verifique se o SLBM auto-VIP (LoadBalanacerManagerIPAddress) e quaisquer
VIPs voltados para locatários estão dentro desses intervalos<)
i. Get-NetworkControllerIpPool -NetworkId "<ID> do recurso de rede lógica
VIP pública/privada" -SubnetId "<ID> de recurso de sub-rede lógica VIP
pública/privada" -ResourceId "<ID> do recurso do pool de IP" -
ConnectionUri $uri |convertto-json -depth 8
b. Debug-NetworkControllerConfigurationState -
Se qualquer uma das verificações acima falhar, o estado do SLB do locatário também
estará no modo de falha.
Remediação Com base nas seguintes informações de diagnóstico apresentadas, corrija

o seguinte:
Verifique se os Multiplexers SLB estão conectados

Corrigir problemas de certificado
Corrigir problemas de conectividade de rede
Verifique se as informações de emparelhamento BGP foram configuradas com
êxito
Verifique se a ID do Host no registro corresponde à ID da Instância do Servidor no
Recurso do Servidor (apêndice de referência para o código de erro
HostNotConnected )
Coletar logs
Erros de locatário do SLBM (hospedagem do provedor de serviços

e ações de locatário)
1. [Hoster] Verifique Debug-NetworkControllerConfigurationState para ver se algum
recurso loadBalancer está em um estado de erro. Tente atenuar seguindo a Tabela
de itens de ação no Apêndice.
a. Verifique se um ponto de extremidade VIP está presente e as rotas de
publicidade
b. Verifique quantos pontos de extremidade DIP foram descobertos para o ponto
de extremidade VIP
2. [Locatário] Validar Load Balancer Recursos são especificados corretamente
a. Validar os pontos de extremidade DIP registrados no SLBM estão hospedando
máquinas virtuais de locatário, que correspondem às configurações de IP do
pool de endereços back-end do LoadBalancer
3. [Hoster] Se os pontos de extremidade DIP não forem descobertos ou conectados:
a. Verificar Debug-NetworkControllerConfigurationState
i. Valide se o agente host NC e SLB está conectado com êxito ao Coordenador
de Eventos do Controlador de Rede usando netstat -anp tcp |findstr
6640)
b. Verificar HostId na regkey de serviço nchostagent (referência ao código de erro

HostNotConnected no Apêndice) corresponde à ID da instância do recurso de
servidor correspondente ( Get-NCServer |convertto-json -depth 8 )
c. Verificar a ID do perfil da porta para a porta da máquina virtual corresponde à
ID da Instância do recurso NIC da máquina virtual correspondente
4. [Provedor de hospedagem] Coletar logs
Rastreamento do SLB Mux
Informações do Software Load Balancer Muxes também podem ser determinadas por
meio de Visualizador de Eventos.
1. Clique em "Mostrar Logs de Análise e Depuração" no menu exibir Visualizador de

Eventos
2. Navegue até "Logs de Aplicativos e Serviços" > Microsoft > Windows >
Rastreamento do SlbMuxDriver > em Visualizador de Eventos
3. Clique com o botão direito do mouse e selecione "Habilitar Log"
７ Observação
É recomendável que você tenha esse log habilitado apenas por um curto período
de tempo enquanto tenta reproduzir um problema
Rastreamento VFP e vSwitch

Em qualquer host Hyper-V que esteja hospedando uma VM convidada anexada a uma
rede virtual de locatário, você pode coletar um rastreamento VFP para determinar onde
os problemas podem estar.
netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes

tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes
VPN (rede virtual privada)

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 e
Windows 10
Gateway ras como um servidor VPN de

locatário único
Em Windows Server 2016, a função de servidor de Acesso Remoto é um agrupamento
lógico das seguintes tecnologias de acesso à rede relacionadas.
RAS (Serviço de Acesso Remoto)

Roteamento
Proxy de aplicativo Web
Essas tecnologias são os serviços de função da função do servidor de acesso remoto.
Ao instalar a função de servidor de Acesso Remoto com o Assistente para Adicionar

Funções e Recursos ou Windows PowerShell, você pode instalar um ou mais desses três
serviços de função.
Ao instalar o serviço de função RAS (DirectAccess e VPN ), você está implantando o

Gateway do RAS (Gateway de Serviço de Acesso Remoto). Você pode implantar o
Gateway ras como um servidor VPN (rede virtual privada) de gateway ras de locatário
único que fornece muitos recursos avançados e funcionalidade aprimorada.
７ Observação
Você também pode implantar o Gateway ras como um servidor VPN multilocatário
para uso com SDN (Rede Definida por Software) ou como um servidor
DirectAccess. Para obter mais informações, consulte Gateway ras, SDN (Rede
Definida por Software) e DirectAccess.
Always On recursos e funcionalidades de VPN: neste tópico, você aprenderá sobre
os recursos e a funcionalidade de Always On VPN.
Configurar túneis de dispositivo VPN em Windows 10: Always On VPN oferece a
capacidade de criar um perfil vpn dedicado para dispositivo ou computador.
Always On conexões VPN incluem dois tipos de túneis: túnel de dispositivo e túnel
de usuário. O túnel do dispositivo é usado para cenários de conectividade pré-
logon e para fins de gerenciamento de dispositivo. O túnel do usuário permite que
os usuários acessem recursos da organização por meio de servidores VPN.
Always On Implantação de VPN para Windows Server 2016 e Windows 10: fornece
instruções sobre como implantar o Acesso Remoto como um gateway DE VPN de
locatário único para conexões VPN ponto a site que permitem que seus
funcionários remotos se conectem à rede da sua organização com conexões VPN
Always On. É recomendável que você examine os guias de design e implantação
para cada uma das tecnologias usadas nesta implantação.
Windows 10 Guia Técnico de VPN: orienta você pelas decisões que tomará para
Windows 10 clientes em sua solução vpn corporativa e como configurar sua
implantação. Você pode encontrar referências ao CSP (Provedor de Serviços de
Configuração) VPNv2 e fornece instruções de configuração de MDM
(gerenciamento de dispositivo móvel) usando Microsoft Intune e o modelo de
perfil VPN para Windows 10.
Como criar perfis VPN no Configuration Manager: neste tópico, você aprenderá a
criar perfis VPN no Configuration Manager.
Configurar Windows 10 Cliente Always On Conexões VPN: este tópico descreve as

opções e o esquema ProfileXML e como criar a VPN ProfileXML. Depois de
configurar a infraestrutura do servidor, você deve configurar o Windows 10
computadores cliente para se comunicar com essa infraestrutura com uma
conexão VPN.
Opções de perfil VPN: este tópico descreve as configurações do perfil VPN em

Windows 10 e aprende a configurar perfis VPN usando Intune ou Configuration
Manager. Você pode definir todas as configurações de VPN em Windows 10
usando o nó ProfileXML no CSP VPNv2.
Serviço de Cadastramento na Internet
do Windows (WINS)
O serviço WINS é um serviço herdado de registro e resolução de nomes de

computadores que mapeia nomes NetBIOS de computadores para endereços IP.
Se você ainda não tiver o WINS implantado em sua rede, não implante WINS – em vez
disso, implante o DNS (Sistema de Nomes de Domínio). O DNS também fornece
serviços de registro e resolução de nome de computador e inclui muitos benefícios
adicionais sobre WINS, como a integração com o Active Directory Domain Services.
Para obter mais informações, consulte DNS (Sistema de Nomes de Domínio)
Se você já tiver implantado o WINS em sua rede, é recomendável implantar o DNS e, em

seguida, descomissionar o WINS.
Serviço de Horário do Windows
(W32Time)
Windows Server 2012 R2, Windows Server 2012, Windows 10 ou posterior, Azure
Stack HCI, versões 21H2 e 20H2
O Serviço de Horário do Windows (W32Time) sincroniza a data e a hora de todos os

computadores em execução em um AD DS (Active Directory Domain Services). A
sincronização de tempo é essencial para a operação adequada de muitos serviços do
Windows e de aplicativos LOB (linha de negócios). O Serviço de Horário do Windows
usa o protocolo NTP para sincronizar os relógios dos computadores na rede. O NTP
verifica se um valor de relógio exato ou um carimbo de data/hora pode ser atribuído a
solicitações de validação de rede e de acesso a recursos.
No tópico do Serviço de Horário do Windows (W32Time), o seguinte conteúdo está

disponível:
Hora Precisa do Windows Server 2016. A precisão da sincronização de hora no

Windows Server 2016 foi substancialmente aprimorada, mantendo, ao mesmo
tempo, a compatibilidade completa do NTP com versões mais antigas do
Windows. Em condições operacionais razoáveis, você pode manter uma precisão
de 1 ms em relação ao UTC ou melhor para membros do domínio Windows Server
2016 e Windows 10 atualização de aniversário.
Limite de suporte para ambientes de alta precisão. Este artigo descreve os limites
de suporte para o Serviço de Horário do Windows (W32Time) em ambientes que
exigem que a hora do sistema seja altamente precisa e estável.
Configurar sistemas para oferecer alta precisão. A sincronização de tempo no
Windows 10 e no Windows Server 2016 foi substancialmente aprimorada. Em
condições operacionais razoáveis, os sistemas podem ser configurados para
manter uma precisão de 1 ms (milissegundo) ou melhor (em relação ao UTC).
Windows tempo para rastreabilidade. As regulamentações em muitos setores
exigem que os sistemas sejam rastreáveis para o UTC. Isso significa que a diferença
de um sistema pode ser atestada com respeito ao UTC. Para habilitar cenários de
conformidade regulatória, o Windows 10 e o Server 2016 fornecem novos logs de
eventos para fornecer uma visão da perspectiva do Sistema Operacional para
formar uma compreensão das ações realizadas no relógio do sistema. Esses logs
de evento são gerados continuamente para o Serviço de Horário do Windows e
podem ser examinados ou arquivados para análise posterior.
Referência técnica do Serviço de Horário do Windows. O serviço W32Time
fornece sincronização de relógio de rede para computadores sem a necessidade
de configuração extensiva. O serviço W32Time é essencial para a operação bem-
sucedida da autenticação do Kerberos V5 e, portanto, para a autenticação baseada
em AD DS.
Como o Serviço de data/hora do Windows Funciona. Embora o Serviço de
Horário do Windows não seja uma implementação exata do protocolo NTP, ele
usa o complexo conjunto de algoritmos definido nas especificações do NTP
para verificar se os relógios em computadores em toda a rede são os mais
precisos possíveis.
Ferramentas e configurações do Serviço de Horário do Windows. A maioria
dos computadores membros do domínio tem um tipo de cliente de tempo de
NT5DS, o que significa que eles sincronizam o tempo com base na hierarquia
de domínio. A única exceção comum a isso é o controlador de domínio que
funciona como o mestre de operações do emulador PDC (controlador de
domínio primário) do domínio raiz da floresta, que geralmente é configurado
para sincronizar o tempo com uma fonte de horário externa.
Para obter mais informações sobre a hierarquia de domínio e o sistema de pontuação,
consulte a postagem no blog "O que é Windows Serviço de Horário?".
O modelo de plug-in do provedor de horário do Windows está documentado no

TechNet.
Um adendo referenciado pelo artigo Tempo Preciso do Windows 2016 pode ser baixado
aqui
Para obter uma visão geral rápida do Serviço de Horário do Windows, assista a este
vídeo de visão geral de alto nível .
Insider Preview
Suporte a segundo bissexto

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows 10, versão
1809, Azure Stack HCI, versões 21H2 e 20H2
Um segundo bissexto é um ajuste ocasional de 1 segundo para UTC. À medida que a

rotação da Terra desacelera, o UTC (escala de tempo atômica) diverge da hora solar
ou do tempo astronômico. Depois que o UTC tiver divergido em pelo menos 0,9
segundos, um segundo bissexto será inserido para manter o UTC em sincronia com o
tempo solar médio.
Os segundos intercalares se tornaram importantes para atender aos requisitos

regulatórios de precisão e rastreabilidade nos Estados Unidos e na União Europeia.
Nosso blog de comunicado
Guia de Validação para Desenvolvedores
Guia de Validação para Profissionais de TI
Protocolo de tempo de precisão

Um novo provedor de horário incluído no Windows Server 2019 e no Windows 10

(versão 1809) permite que você sincronize a hora usando o protocolo PTP. Conforme o
tempo é distribuído em uma rede, ocorre atraso (latência) que, se não for contabilizado
ou não for simétrico, dificultará cada vez mais o entendimento do carimbo de data/hora
enviado do servidor de horário. O PTP permite que os dispositivos de rede adicionem a
latência introduzida por cada dispositivo de rede nas medições de tempo, fornecendo,
assim, um tempo bem mais preciso ao cliente Windows.

Guia de Validação para Profissionais de TI
Carimbo de data/hora do software

Ao receber um pacote de tempo pela rede de um servidor de horário, ele deve ser
processado pela pilha de rede do sistema operacional antes de ser consumido no
serviço de horário. Cada componente na pilha de rede introduz uma quantidade variável
de latência que afeta a precisão da medição de tempo.
Para resolver esse problema, o carimbo de data/hora do software nos permite carimbar
pacotes com data/hora antes e depois dos "Componentes de Rede do Windows"
mostrados acima para considerar o atraso no sistema operacional.
Guias de validação para desenvolvedores e profissionais de TI

Hora precisa no Windows Server 2016
O Serviço de Horário do Windows é um componente que usa um modelo de plug-in

para provedores de sincronização de hora do cliente e do servidor. Há dois provedores
de cliente internos no Windows e há plug-ins de terceiros disponíveis. Um provedor usa
o NTP (RFC 1305) ou o MS-NTP para sincronizar a hora do sistema local com um
servidor de referência em conformidade com o NTP e/ou o MS-NTP. O outro provedor
destina-se ao Hyper-V e sincroniza as VMs (máquinas virtuais) com o host do Hyper-V.
Quando houver vários provedores, o Windows escolherá o melhor provedor usando o
nível de camada primeiro, seguido pelo atraso de raiz, dispersão de raiz e, por fim, a
diferença de horário.
７ Observação
Para obter uma visão geral rápida do Serviço de Horário do Windows, assista a este
vídeo de visão geral de alto nível .
Neste tópico, abordaremos... estes tópicos conforme estão relacionados com a

habilitação da hora precisa:
Aprimoramentos
Medidas
Práticas recomendadas
） Importante
Um adendo referenciado pelo artigo Hora precisa do Windows 2016 pode ser
baixado aqui . Esse documento fornece mais detalhes sobre nossas metodologias
de teste e medição.
７ Observação
O modelo de plug-in do provedor de horário do Windows está documentado no

TechNet.
Hierarquia de domínio
As configurações autônomas e de domínio funcionam de maneira diferente.
Os membros do domínio usam um protocolo NTP seguro, que usa a autenticação

para garantir a segurança e a autenticidade da referência de tempo. Os membros
do domínio são sincronizados com um relógio mestre determinado pela hierarquia
de domínio e um sistema de pontuação. Em um domínio, há uma camada
hierárquica de camadas de tempo, na qual cada controlador de domínio aponta
para um controlador de domínio pai com uma camada de tempo mais precisa. A
hierarquia é resolvida como o controlador de domínio primário ou um controlador
de domínio na floresta raiz ou um controlador de domínio com o sinalizador de
domínio do GTIMESERV, o que indica um Servidor de Horário Certo para o
domínio. Confira a seção [Especificar um serviço de hora confiável local usando o
GTIMESERV] abaixo.
Os computadores autônomos são configurados para usar o time.windows.com por

padrão. Esse nome é resolvido pelo servidor DNS, que deverá apontar para um
recurso pertencente à Microsoft. Como todas as referências de tempo localizadas
remotamente, as interrupções de rede podem impedir a sincronização. As cargas
de tráfego de rede e os caminhos de rede assimétrica poderão reduzir a precisão
da sincronização de hora. Para uma precisão de 1 ms, você não pode depender de
fontes de horário remotas.
Como os convidados do Hyper-V terão, pelo menos, dois provedores de tempo do

Windows à escolha, a hora do host e o NTP, você poderá ver comportamentos
diferentes com Domínio ou Autônomo na execução como convidado.
７ Observação
para obter mais informações sobre a hierarquia de domínio e o sistema de

pontuação, consulte a postagem do blog "o que é o serviço de tempo de
Windows?" .
７ Observação
A camada é um conceito usado nos provedores NTP e Hyper-V; o valor delas indica
a localização dos relógios na hierarquia. A camada 1 é reservada para o relógio de
nível mais alto e a camada 0 é reservada para o hardware considerado preciso e
que tenha pouco ou nenhum atraso associado a ele. A camada 2 se comunica com
os servidores da camada 1, a camada 3 com a camada 2 e assim por diante.
Embora uma camada mais baixa geralmente indique um relógio mais preciso, é
possível encontrar discrepâncias. Além disso, o W32Time aceita apenas a hora da
camada 15 ou abaixo. Para ver a camada de um cliente, use w32tm /query /status.
Fatores críticos para a hora precisa

Em cada caso, para uma hora precisa, há três fatores críticos:
1. Relógio de origem sólido: o relógio de origem no domínio precisa ser estável e

preciso. Isso geralmente significa a instalação de um dispositivo GPS ou apontá-lo
para uma origem da camada 1, levando o nº 3 em conta. A analogia continua: se
você tiver dois barcos na água e estiver tentando medir a altitude de um em
comparação com o outro, a precisão será melhor se o barco de origem for muito
estável e não estiver se movendo. O mesmo acontece com o tempo e, se o relógio
de origem não estiver estável, a cadeia inteira de relógios sincronizados será
afetada e ampliada em cada fase. Ele também precisa estar acessível porque as
interrupções na conexão interferirão na sincronização da hora. E, finalmente, ele
precisa ser seguro. Se a referência de tempo não for mantida corretamente ou for
operada por uma parte potencialmente mal-intencionada, você poderá expor seu
domínio a ataques baseados em tempo.
2. Relógio de cliente estável: um relógio de cliente estável garante que o
descompasso natural do oscilador possa ser confinado. O NTP usa várias amostras
de potencialmente vários servidores NTP para condicionar e disciplinar o relógio
dos computadores locais. Ele não percorre as alterações de horário, mas, em vez
disso, reduz ou acelera o relógio local para que você se aproxime da hora exata
rapidamente e fique preciso entre as solicitações do NTP. No entanto, se o
oscilador do relógio do computador cliente não for estável, mais flutuações entre
os ajustes poderão ocorrer e os algoritmos que o Windows usa para condicionar o
relógio não funcionarão com precisão. Em alguns casos, atualizações de firmware
podem ser necessárias para obter uma hora precisa.
3. Comunicação do NTP simétrica: é essencial que a conexão para a comunicação do
NTP seja simétrica. O NTP usa cálculos para ajustar o tempo que pressupõe que o
caminho de rede seja simétrico. Se o caminho que o pacote NTP usa para o
servidor levar um período diferente para ser retornado, a precisão será afetada. Por
exemplo, o caminho pode ser alterado devido a alterações na topologia de rede
ou os pacotes estão sendo roteados por meio de dispositivos com velocidades de
interface diferentes.
Para dispositivos com bateria, móveis e portáteis, é necessário considerar estratégias
diferentes. De acordo com nossa recomendação, a manutenção de hora precisa exige
que o relógio seja disciplinado uma vez por segundo, o que se correlaciona com a
Frequência de Atualização do Relógio. Essas configurações consumirão mais energia da
bateria do que o esperado e podem interferir nos modos de economia de energia
disponíveis no Windows para esses dispositivos. Os dispositivos com bateria também
têm alguns modos de energia que interrompem a execução de todos os aplicativos, o
que interfere na capacidade do W32Time de disciplinar o relógio e manter a hora
precisa. Além disso, primeiramente, os relógios em dispositivos móveis podem não ser
muito precisos. As condições do ambiente afetam a precisão do relógio. Um dispositivo
móvel pode passar de uma condição de ambiente para a seguinte, o que pode interferir
na capacidade de manter a hora precisa. Portanto, a Microsoft não recomenda que você
configure dispositivos portáteis com bateria usando configurações de alta precisão.
Por que a hora é importante?

Há muitas razões diferentes pelas quais você pode necessitar da hora precisa. O caso
típico do Windows é o Kerberos, que exige 5 minutos de precisão entre o cliente e o
servidor. No entanto, há muitas outras áreas que podem ser afetadas pela precisão do
tempo, incluindo:
Regulamentações do governo como:

50 ms de precisão para FINRA nos EUA
1 ms para ESMA (MiFID II) na UE.
Algoritmos de criptografia
Sistemas distribuídos, como BDs de Documentos e Cluster/SQL/Exchange
Estrutura de blockchain para transações de bitcoin
Logs distribuídos e análise de ameaças
Replicação do AD
PCI (Payment Card Industry), atualmente, precisão de 1 segundo
Aprimoramentos de precisão de tempo para o Windows Server 2016
Limite de suporte para a hora de alta
precisão
Windows 10 versão 1607 ou posterior, Azure Stack HCI, versões 21H2 e 20H2
Este artigo descreve os limites de suporte para o Serviço de Horário do Windows

(W32Time) em ambientes que exigem que a hora do sistema seja altamente precisa e
estável.
Suporte de Alta Precisão para Windows 8.1 e

2012 R2 (ou anterior)
Versões anteriores do Windows (antes do Windows 10 1607 ou do Windows Server
2016 1607) não podem garantir um tempo altamente preciso. O Serviço de Horário do
Windows nesses sistemas:
Fornecia a precisão de tempo necessária para atender aos requisitos de

autenticação do Kerberos versão 5
Fornecia um tempo menos preciso para clientes e servidores Windows ingressados

em uma floresta do Active Directory comum
Os requisitos de precisão mais rígidos estavam fora da especificação de design do

serviço de Horário do Windows nesses sistemas operacionais e não há suporte para isso.
Windows 10 e Windows Server 2016

A precisão de tempo no Windows 10 e no Windows Server 2016 foi substancialmente
aprimorada, mantendo, ao mesmo tempo, compatibilidade de NTP completa com
versões mais antigas do Windows. Sob as condições operacionais corretas, os sistemas
que executam Windows 10 ou Windows Server 2016 e versões mais novas podem
fornecer precisão de 1 segundo, 50 ms (milissegundos) ou 1 ms de precisão.
） Importante
Fontes de tempo altamente precisas
A precisão de tempo resultante em sua topologia é altamente dependente do uso

de uma fonte de horário precisa e de raiz estável (estrato 1). Há hardware de fonte
de horário NTP altamente preciso baseado em Windows, não baseado em
Windows e compatível com o Windows vendido por fornecedores terceiros. Entre
em contato com seu fornecedor com relação à precisão dos produtos dele.
） Importante
Precisão do tempo
A precisão do tempo envolve a distribuição de ponta a ponta de tempo preciso de

uma fonte de horário autoritativo altamente preciso para o dispositivo final.
Qualquer coisa que introduz a assimetria de rede influenciará negativamente a
precisão, por exemplo, dispositivos de rede física ou alta carga de CPU no sistema
de destino.
Requisitos de alta precisão

O restante deste documento descreve os requisitos ambientais que devem ser
atendidos para dar suporte aos respectivos destinos de alta precisão.
Precisão de destino: 1 s (1 segundo)

Para obter a precisão de 1s para um computador de destino específico em comparação
com uma fonte de horário altamente precisa:
O sistema de destino deve executar o Windows 10 e o Windows Server 2016.
O sistema de destino deve sincronizar o tempo de uma hierarquia de NTP de

servidores de horário, ocasionando uma fonte de horário NTP altamente precisa e
compatível com o Windows.
Todos os sistemas operacionais Windows na hierarquia de NTP mencionados

acima devem ser configurados conforme documentado na documentação
Configurar Sistemas para Alta Precisão.
A latência de rede única cumulativa entre o destino e a origem não deve exceder
100 ms. O atraso de rede cumulativa é medido adicionando atrasos unidirecionais
individuais entre pares de nós cliente-servidor NTP na hierarquia começando com
o destino e terminando na origem. Para obter mais informações, leia o documento
de sincronização de tempo de alta precisão.
Precisão de destino: 50 milissegundos

Todos os requisitos descritos na seção Precisão de destino: 1 segundo se aplicam,
exceto em situações em que controles mais estritos forem descritos nesta seção.
Os outros requisitos para atingir a precisão de 50 ms para um sistema de destino

específico são:
O computador de destino deve ter mais de 5 ms de latência de rede entre sua

fonte de horário.
O sistema de destino não deve ser maior do que o estrato 5 com base em uma
fonte de horário altamente precisa
７ Observação
Execute "w32tm /query /status" na linha de comando para ver o estrato.
O sistema de destino deve estar dentro de 6 ou menos saltos de rede da fonte de

horário altamente precisa
A utilização média de CPU de um dia em todos os estratos não deve exceder 90%
Para sistemas virtualizados, a utilização média de um dia da CPU do host não deve
exceder 90%
Precisão de destino: 1 milissegundo

Todos os requisitos descritos nas seções Precisão de destino: 1 segundo e Precisão de
destino: 50 milissegundos se aplicam, exceto em situações em que controles mais
estritos forem descritos nesta seção.
Os outros requisitos para obter precisão de 1 ms para um sistema de destino específico

são:
O computador de destino deve ter latência de rede melhor que 0,1 ms entre a
fonte de horário
O sistema de destino não deve ser maior do que o estrato 5 com base em uma
fonte de horário altamente precisa
７ Observação
Execute 'w32tm /query /status' na linha de comando para ver o estrato
O sistema de destino deve estar dentro de 4 ou menos saltos de rede da fonte de

horário altamente precisa
A utilização média de CPU de um dia em cada estrato não deve exceder 80%
Para sistemas virtualizados, a utilização média de um dia da CPU do host não deve
exceder 80%
Configurar sistemas para oferecer alta
precisão
Windows 10 versão 1607 ou posterior, Azure Stack HCI, versões 21H2 e 20H2
A sincronização de tempo no Windows 10 e no Windows Server 2016 foi

substancialmente aprimorada. Em condições operacionais razoáveis, os sistemas podem
ser configurados para manter a precisão de 1 ms (milissegundo) ou melhor (com
respeito ao UTC).
As diretrizes a seguir ajudarão você a configurar seus sistemas para obter alta precisão.
Este artigo aborda os seguintes requisitos:
Sistemas operacionais com suporte

Configuração do sistema
２ Aviso
Metas de precisão anteriores dos sistemas operacionais
O Windows Server 2012 R2 e versões inferiores não podem atender aos mesmos
objetivos de alta precisão. Esses sistemas operacionais não têm suporte para alta
precisão.
Nessas versões, o Serviço de Horário do Windows atendeu aos seguintes requisitos:
Forneceu a precisão de tempo necessária para atender aos requisitos de

autenticação do Kerberos versão 5.
Forneceu um tempo menos preciso para clientes e servidores Windows
ingressados em uma floresta do Active Directory comum.
Tolerâncias maiores no 2012 R2 e abaixo estão fora da especificação de design do

Serviço de Horário do Windows.
Configuração Padrão do Windows 10 e do

Windows Server 2016
Embora demos suporte à precisão de até 1 ms no Windows 10 ou no Windows Server
2016, a maioria dos clientes não exige tempo altamente preciso.
Assim, a configuração padrão destina-se a atender aos mesmos requisitos dos sistemas
operacionais anteriores que são:
Fornecer a precisão de tempo necessária para atender aos requisitos de

autenticação do Kerberos versão 5.
Fornecer um tempo menos preciso para clientes e servidores Windows ingressados
em uma floresta do Active Directory comum.
Como configurar sistemas para oferecer alta

precisão
） Importante
Observação sobre a compatibilidade de sistemas altamente precisos
A precisão do tempo envolve a distribuição de ponta a ponta de tempo preciso de

uma fonte de horário autoritativo para o dispositivo final. Qualquer coisa que
adiciona assimetria em medições ao longo desse caminho influenciará
negativamente a precisão que pode ser obtida em seus dispositivos.
Por esse motivo, documentamos o Limite de suporte para configurar o Serviço de

Horário do Windows para ambientes de alta precisão descrevendo os requisitos
ambientais que também devem ser atendidos para alcançar metas de alta precisão.
Requisitos do Sistema Operacional

As configurações de alta precisão exigem o Windows 10 ou o Windows Server 2016.
Todos os dispositivos Windows na topologia de tempo devem atender a esse requisito,
incluindo servidores de horário do Windows de estrato mais alto e, em cenários
virtualizados, os hosts Hyper-V que executam as máquinas virtuais sensíveis ao tempo.
Todos esses dispositivos devem ser pelo menos Windows 10 ou Windows Server 2016.
Na ilustração mostrada abaixo, as máquinas virtuais que exigem alta precisão estão
executando o Windows 10 ou o Windows Server 2016. Da mesma forma, o host Hyper-
V no qual as máquinas virtuais residem e o servidor de horário do Windows upstream
também devem executar o Windows Server 2016.
 Dica
Determinar a versão do Windows
Você pode executar o comando winver em um prompt de comando para verificar

se a versão do sistema operacional é 1607 (ou superior) e se o build do sistema
operacional é 14393 (ou superior) conforme mostrado abaixo:
Configuração do sistema
Atingir destinos de alta precisão requer a configuração do sistema. Há várias maneiras
de executar essa configuração, incluindo diretamente no Registro ou por meio da
política de grupo. Mais informações para cada uma dessas configurações podem ser
encontradas na Referência Técnica do Serviço de Tempo Windows: Windows
Ferramentas de Serviço de Tempo.
Tipo de Inicialização do Serviço de Horário do Windows

O Serviço de Horário do Windows (W32Time) deve ser executado continuamente. Para
fazer isso, configure o tipo de inicialização do Serviço de Horário do Windows como
início “Automático”.
Latência de rede unidirecional cumulativa

A incerteza da medição e o “ruído” aparecem conforme a latência de rede aumenta.
Assim, é imperativo que uma latência de rede esteja dentro de um limite razoável. Os
requisitos específicos dependem de sua precisão de destino e são descritos no artigo
Limite de suporte para configurar o Serviço de Horário do Windows para ambientes de
alta precisão.
Para calcular a latência de rede unidirecional cumulativa, adicione os atrasos

unidirecionais individuais entre pares dos nós cliente-servidor NTP na topologia de
tempo, começando com o destino e terminando na fonte de horário de estrato 1 de alta
precisão.
Por exemplo: Considere uma hierarquia de sincronização de tempo com uma fonte
altamente precisa, dois servidores NTP intermediários A e B e o computador de destino
nessa ordem. Para obter a latência de rede cumulativa entre o destino e a origem, meça
os RTTs (tempos de ida e volta) médios NTP individuais entre:
O destino e o servidor de horário B

O servidor B e o servidor de horário A
O servidor de horário A e a fonte
Essa medida pode ser obtida usando a ferramenta w32tm.exe da caixa de entrada. Para
fazer isso:
1. Execute o cálculo do destino e do servidor de horário B.
w32tm /stripchart /computer:TimeServerB /rdtsc /samples:450 >
c:\temp\Target_TsB.csv
2. Realize o cálculo do servidor de horário B em relação ao (apontado no) servidor de

horário A.
w32tm /stripchart /computer:TimeServerA /rdtsc /samples:450 >

c:\temp\Target_TsA.csv
3. Realize o cálculo do servidor de horário A em relação à origem.
4. Em seguida, adicione o RoundTripDelay médio medido na etapa anterior e divida

por 2 para obter o atraso de rede cumulativo entre o destino e a origem.
Configurações do Registro
MinPollInterval
Configura o menor intervalo em log2 segundos permitido para sondagem do sistema.
Descrição Valor
Localização principal HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config
Configuração 6
Resultado O intervalo de sondagem mínimo agora é de 64 segundos.

O seguinte comando sinaliza o Horário do Windows para selecionar as configurações
atualizadas: w32tm /config /update
MaxPollInterval
Configura o maior intervalo em log2 segundos permitido para sondagem do sistema.
Descrição Valor
Configuração 6
Resultado O intervalo de sondagem máximo agora é de 64 segundos.

UpdateInterval
O número de tiques de relógio entre os ajustes de correção de fase.
Descrição Valor
Localização HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Config
principal
Configuração 100
Resultado O número de tiques de relógio entre os ajustes de correção de fase agora é

de 100 tiques.

SpecialPollInterval
Configura o intervalo de sondagem em segundos quando o sinalizador SpecialInterval
0x1 está habilitado.
Descrição Valor
Localização HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
principal
Descrição Valor
Configuração 64
Resultado O intervalo de sondagem agora é de 64 segundos.
O seguinte comando reinicia o Horário do Windows para selecionar as configurações

atualizadas: net stop w32time && net start w32time
FrequencyCorrectRate
Descrição Valor
Configuração 2
Horário do Windows para
rastreabilidade
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016
versão 1709 ou posterior e Windows 10 versão 1703 ou posterior, Azure Stack HCI,
versões 21H2 e 20H2
As regulamentações em muitos setores exigem que os sistemas sejam rastreáveis para o

UTC. Isso significa que a diferença de um sistema pode ser atestada com respeito ao
UTC. Para habilitar cenários de conformidade regulatória, o Windows 10 (versão 1703 ou
posterior) e o Windows Server 2016 (versão 1709 ou posterior) fornecem novos logs de
eventos para oferecer uma visão da perspectiva do Sistema Operacional a fim de criar
uma compreensão das ações executadas no relógio do sistema. Esses logs de evento
são gerados continuamente para o Serviço de Horário do Windows e podem ser
examinados ou arquivados para análise posterior.
Esses novos eventos permitem que as seguintes perguntas sejam respondidas:
O relógio do sistema foi alterado

A frequência do relógio foi modificada
A configuração do Serviço de Horário do Windows foi modificada
Disponibilidade
Esses aprimoramentos estão incluídos no Windows 10 versão 1703 ou posterior e no
Windows Server 2016 versão 1709 ou posterior.
Configuração
Nenhuma configuração é necessária para usar este recurso. Esses logs de eventos são
habilitados por padrão e podem ser encontrados no visualizador de eventos no canal
Applications and Services Log\Microsoft\Windows\Time-Service\Operational.
Lista de logs de eventos

A seção a seguir descreve os eventos registrados para uso em cenários de
rastreabilidade.
257
Esse evento é registrado quando o Windows Time Service (W32Time) é iniciado e

registra informações sobre a hora atual, a contagem de tiques atual, a configuração
de runtime, os provedores de tempo e a taxa de relógio atual.
Descrição do evento Início do serviço
Detalhes Ocorre na inicialização do W32time
Dados registrados Hora atual em UTC

Contagem atual de tiques
Configuração do W32Time
Configuração do Provedor de Tempo
Taxa do relógio
Mecanismo de Nenhum. Esse evento é disparado sempre que o serviço é

limitação iniciado.
Exemplo:
W32time service has started at 2018-02-27T04:25:17.156Z (UTC), System

Tick Count 3132937.
Comando:
Essas informações também podem ser consultadas usando os comandos a seguir
Configuração do W32Time e do Provedor de Tempo
w32tm.exe /query /configuration
Taxa do relógio
w32tm.exe /query /status /verbose

Referência Técnica do Serviço de
Horário do Windows
O serviço W32Time fornece sincronização de relógio de rede para computadores sem a

necessidade de configuração extensiva. O serviço W32Time é essencial para a operação
bem-sucedida da autenticação do Kerberos V5 e, portanto, para a autenticação baseada
em AD DS. Qualquer aplicativo com reconhecimento de Kerberos, incluindo a maioria
dos serviços de segurança, depende da sincronização de tempo entre os computadores
que participam da solicitação de autenticação. Os controladores de domínio do AD DS
também devem ter relógios sincronizados para ajudar a garantir uma replicação de
dados precisa.
７ Observação
No Windows Server 2003 e no Microsoft Windows 2000 Server, o serviço de

diretório é denominado serviço de diretório Active Directory. No Windows Server
2008 R2 e Windows Server 2008, o serviço de diretório é nomeado Active Directory
Domain Services (AD DS). O restante deste tópico se refere ao AD DS, mas as
informações também se aplicam ao Active Directory Domain Services no Windows
Server 2016.
O serviço W32Time é implementado em uma biblioteca de vínculo dinâmico chamada

W32Time.dll, instalada por padrão no %Systemroot%\System32. O W32Time.dll foi
originalmente desenvolvido para o Windows 2000 Server dar suporte a uma
especificação pelo protocolo de autenticação Kerberos V5 que exigia que os relógios
estivessem em uma rede para serem sincronizados. Do Windows Server 2003 em diante,
o W32Time.dll fornecia maior precisão na sincronização do relógio de rede no sistema
operacional Windows Server 2000. Além disso, no Windows Server 2003, o W32Time.dll
dava suporte a uma variedade de dispositivos de hardware e protocolos de horário de
rede usando provedores de horário.
Embora originalmente criado para fornecer sincronização de relógio para a autenticação

do Kerberos, muitos aplicativos atuais usam carimbos de data/hora para garantir a
consistência transacional, registrar o temo de importantes eventos e outras informações
críticas para os negócios e sensíveis ao tempo. Esses aplicativos se beneficiam da
sincronização de tempo entre computadores fornecidos pelo Serviço de Horário do
Windows.
Importância dos Protocolos de Tempo

Os protocolos de tempo se comunicam entre dois computadores para trocar
informações sobre tempo e usá-las para sincronizar os relógios deles. Com o protocolo
de tempo do Serviço de Horário do Windows, um cliente solicita informações sobre
tempo de um servidor e sincroniza o relógio dele com base nas informações recebidas.
O Serviço de Horário do Windows usa o NTP para ajudar a sincronizar o tempo em uma
rede. O NTP é um protocolo de tempo da Internet que inclui os algoritmos de disciplina
necessários para sincronizar relógios. O NTP é um protocolo de tempo mais preciso que
o SNTP (protocolo NTP simples) usado em algumas versões do Windows; no entanto, o
W32Time continua dando suporte ao SNTP para habilitar a compatibilidade com
versões anteriores com computadores que executam serviços de tempo baseados em
SNTP, como o Windows 2000.
Onde encontrar informações relacionadas à

configuração do Serviço de Horário do
Windows
Este guia não discute a configuração do Serviço de Horário do Windows. Há vários
tópicos diferentes no Microsoft TechNet e na Base de Dados de Conhecimento
Microsoft que explicam os procedimentos para configurar o Serviço de Horário do
Windows. Se você precisar de informações de configuração, os tópicos a seguir deverão
ajudar a localizar as informações apropriadas.
Para configurar o Serviço de Horário do Windows para o emulador PDC

(controlador de domínio primário) raiz da floresta, confira:
Configurar o Serviço de Horário do Windows no emulador PDC no domínio raiz

da floresta
Configurar uma fonte de horário para a floresta
O artigo 816042 da Base de Dados de Conhecimento Microsoft, Como

configurar um servidor de horário autoritativo no Windows Server, que descreve
as configurações para computadores que executam o Windows Server 2008 R2,
Windows Server 2008, Windows Server 2003 e Windows Server 2003 R2.
Para configurar o Serviço de Horário do Windows em qualquer cliente ou servidor
membro do domínio ou até mesmo controladores de domínio que não estejam
configurados como o emulador PDC raiz da floresta, confira Configurar um
computador cliente para sincronização automática de horário de domínio.
２ Aviso
Alguns aplicativos podem exigir que os computadores deles tenham serviços

de tempo de alta precisão. Se esse for o caso, você poderá optar por
configurar uma fonte de horário manual, mas saiba que o Serviço de Horário
do Windows não foi criado para funcionar como uma fonte de horário
altamente precisa. Verifique se você conhece as limitações de suporte para
ambientes de tempo de alta precisão conforme descrito no artigo 939322 da
Base de Dados de Conhecimento Microsoft, Limite de suporte para
configurar o Serviço de Horário do Windows para ambientes de alta
precisão.
Para configurar o Serviço de Horário do Windows em computadores cliente ou de

servidor baseados em Windows que estão configurados como membros de um
grupo de trabalho em vez de membros de domínio, confira Configurar uma fonte
de horário manual para um computador cliente selecionado.
Para configurar o Serviço de Horário do Windows em um computador host que

executa um ambiente virtual, confira o artigo 816042 da Base de Dados de
Conhecimento Microsoft, Como configurar um servidor de horário autoritativo no
Windows Server. Se estiver trabalhando com um produto de virtualização que não
seja da Microsoft, confira a documentação do fornecedor desse produto.
Para configurar o Serviço de Horário do Windows em um controlador de domínio

que está sendo executado em uma máquina virtual, é recomendável que você
desabilite parcialmente a sincronização de tempo entre o sistema host e o sistema
operacional convidado que funciona como um controlador de domínio. Isso
permitirá que seu controlador de domínio convidado sincronize o tempo da
hierarquia de domínio, mas a proteja contra uma distorção de tempo se ela for
restaurada de um estado Salvo. Para obter mais informações, confira o artigo
976924 da Base de Dados de Conhecimento Microsoft, Você recebe as IDs de
evento 24, 29 e 38 do Serviço de Horário do Windows em um controlador de
domínio virtualizado em execução em um host baseado em Windows Server 2008
com Hyper-V e Considerações de Implantação para Controladores de Domínio
Virtualizados.
Para configurar o Serviço de Horário do Windows em um controlador de domínio
que funciona como o emulador PDC raiz da floresta que também está em
execução em um computador virtual, siga as mesmas instruções para um
computador físico conforme descrito em Configurar o Serviço de Horário do
Windows no emulador PDC no domínio raiz da floresta.
Para configurar o Serviço de Horário do Windows em um servidor membro em

execução como um computador virtual, use a hierarquia de tempo de domínio
conforme descrito em Configurar um computador cliente para sincronização
automática de tempo de domínio.
） Importante
Antes do Windows Server 2016, o serviço W32Time não era criado para atender a
necessidades de aplicativos sensíveis ao tempo. Contudo, agora as atualizações do
Windows Server 2016 permitem que você implemente uma solução para ter
precisão de 1 ms em seu domínio. Para obter mais informações sobre, consulte
Windows limite de tempo e suporte precisos de 2016para configurar o serviço
Windows Time para ambientes de alta precisão para obter mais informações.
Hora precisa do Windows 2016
Aprimoramentos de precisão de tempo para o Windows Server 2016
Como o serviço de Horário do Windows funciona
Ferramentas e configurações do Serviço de Tempo do Windows
Limite de suporte para configurar o Serviço de Horário do Windows para
ambientes de alta precisão
Como funciona o serviço Horário do
Windows
Nesta seção
Arquitetura do Serviço de Horário do Windows
Protocolos de tempo do Serviço de Horário do Windows
Processos e interações do Serviço de Horário do Windows
Portas de rede usadas pelo Serviço de Horário do Windows
７ Observação
Este tópico explica como funciona o Serviço de Horário do Windows (W32Time).

Para obter informações de como configurar o Serviço de Horário do Windows,
confira Configuração de sistemas para alta precisão.
７ Observação
No Windows Server 2003 e no Microsoft Windows 2000 Server, o serviço de

diretório é denominado serviço de diretório Active Directory. No Windows Server
2008 e versões posteriores, o serviço de diretório é nomeado Active Directory
Domain Services (AD DS). O restante deste tópico refere-se ao AD DS, mas as
informações também são aplicáveis para o Active Directory.
Embora o Serviço de Horário do Windows não seja uma implementação exata do

protocolo NTP, ele usa o complexo conjunto de algoritmos definido nas especificações
do NTP para verificar se os relógios em computadores em toda a rede são os mais
precisos possíveis. O ideal é que todos os relógios dos computadores de um domínio
do AD DS sejam sincronizados com a hora de um computador oficial. Muitos fatores
podem afetar a sincronização de horário em uma rede. Os seguintes fatores geralmente
afetam a precisão da sincronização no AD DS:
Condições da rede
A precisão do relógio do hardware do computador
A quantidade de recursos de CPU e de rede disponíveis para o Serviço de Horário

do Windows
） Importante
Antes do Windows Server 2016, o serviço W32Time não era criado para atender a
necessidades de aplicativos sensíveis ao tempo. Contudo, agora as atualizações do
Windows Server 2016 permitem que você implemente uma solução para ter
precisão de 1 ms em seu domínio. Exiba o limite de tempo e suporte precisos do
Windows 2016para configurar o serviço tempo do Windows para ambientes de
alta precisão para obter mais informações.
Os computadores que sincronizam o horário com menos frequência ou que não são
associados a um domínio, são configurados para sincronizar com o time.windows.com
por padrão. Portanto, é impossível garantir a precisão do tempo em computadores que
têm conexões de rede intermitentes ou que não têm conexão.
Uma floresta do AD DS tem uma hierarquia de sincronização de tempo predeterminada.

O Serviço de Horário do Windows sincroniza o tempo entre computadores da
hierarquia, com os relógios de referência mais precisos na parte superior. Se mais de
uma fonte de horário estiver configurada em um computador, o Horário do Windows
usará algoritmos NTP para selecionar a melhor fonte de horário dentre as fontes
configuradas com base na capacidade do computador de sincronizar com essa fonte de
horário. O Serviço de Horário do Windows não é compatível com a sincronização de
rede de pares de difusão ou difusão seletiva. Para obter mais informações sobre esses
recursos de NTP, confira RFC 1305 no banco de dados RFC da IETF.
Todos os computadores que executam o Serviço de Horário do Windows usam o serviço

para manter o tempo mais preciso. Os computadores que são membros de um domínio
atuam como um cliente de tempo por padrão, portanto, na maioria dos casos, não é
necessário configurar o Serviço de Horário do Windows. No entanto, o Serviço de
Horário do Windows pode ser configurado para solicitar a hora de uma fonte de horário
de referência designada e também pode fornecer o horário aos clientes.
O grau de precisão da hora de um computador é chamado de estrato. A fonte de

horário mais precisa em uma rede (como um relógio de hardware) ocupa o nível mais
baixo de estrato ou estrato um. Essa fonte de horário precisa é chamada de relógio de
referência. Um servidor NTP que adquire o horário diretamente de um relógio de
referência ocupa um estrato que é um nível acima do relógio de referência. Os recursos
que adquirem o tempo do servidor NTP são dois níveis acima do relógio de referência e,
portanto, ocupam um estrato maior do que a fonte de horário mais precisa e assim por
diante. À medida que o número de estrato de um computador aumenta, o tempo no
relógio do sistema pode se tornar menos preciso. Portanto, o nível de estrato de
qualquer computador é um indicador de quão próximo ele está sincronizado com a
fonte de horário mais precisa.
Quando o Gerenciador do W32Time recebe amostras de tempo, ele usa algoritmos

especiais do protocolo NTP para determinar qual das amostras de tempo é a mais
apropriada para uso. O serviço de horário também usa outro conjunto de algoritmos
para determinar qual das fontes de horário configuradas é a mais precisa. Quando o
serviço de horário tiver determinado qual amostra de tempo é a melhor, com base nos
critérios acima, ele ajustará a velocidade do relógio local para permitir que ela convirja
em direção ao horário correto. Se a diferença de tempo entre o relógio local e a
amostra de hora precisa selecionada (também chamada de distorção de tempo) for
muito grande para ser corrigida ajustando a velocidade do relógio local, o serviço de
horário definirá o relógio local com a hora correta. Esse ajuste da velocidade do relógio
ou alteração direta do horário do relógio é conhecida como disciplina do relógio.
Arquitetura de serviço de tempo do Windows

O Serviço de Horário do Windows consiste nos seguintes componentes:
Gerenciador de Controle de Serviço
Gerenciador do Serviço de Horário do Windows
Disciplina do relógio
Provedores de tempo
A figura a seguir mostra a arquitetura do Serviço de Horário do Windows.
Arquitetura do Serviço de Horário do Windows

O Gerenciador de Controle de Serviço é responsável por iniciar e parar o Serviço de
Horário do Windows. O Gerenciador do Serviço de Horário do Windows é responsável
por iniciar a ação dos provedores de horário de NTP incluídos no sistema operacional. O
Gerenciador do Serviço de Horário do Windows controla todas as funções do Serviço de
Horário do Windows e o agrupamento de todas as amostras de tempo. Além de
fornecer informações sobre o estado atual do sistema, como a fonte de horário atual ou
a última vez em que o relógio do sistema foi atualizado, o Gerenciador do Serviço de
Horário do Windows também é responsável pela criação de eventos no log de eventos.
O processo de sincronização do tempo envolve as seguintes etapas:
Os provedores de entrada solicitam e recebem amostras de tempo de fontes de

horário de NTP configuradas.
Essas amostras de tempo são passadas para o Gerenciador do Serviço de Horário

do Windows, que coleta todas as amostras e as passa para o subcomponente de
disciplina do relógio.
O subcomponente de disciplina do relógio aplica os algoritmos do NTP que

resultam na seleção da melhor amostra de tempo.
O subcomponente de disciplina do relógio ajusta a hora do relógio do sistema

com o tempo mais preciso ajustando a velocidade do relógio ou alterando
diretamente a hora.
Se um computador tiver sido designado como um servidor de horário, ele poderá enviar
a hora para qualquer computador solicitando a sincronização de horário a qualquer
momento nesse processo.
Protocolos de tempo do Serviço de Horário do

Windows
Os protocolos de tempo determinam qual a precisão entre a sincronia dos relógios de
dois computadores. Um protocolo de tempo é responsável por determinar as melhores
informações de tempo disponíveis e convergir os relógios para garantir que um tempo
consistente seja mantido em sistemas separados.
O Serviço de Horário do Windows usa o NTP (protocolo NTP) para ajudar a sincronizar o
tempo em uma rede. O NTP é um protocolo de tempo da Internet que inclui os
algoritmos de disciplina necessários para sincronizar relógios. O NTP é um protocolo de
tempo mais preciso que o SNTP (protocolo NTP simples) usado em algumas versões do
Windows; no entanto, o W32Time continua dando suporte ao SNTP para permitir a
compatibilidade com versões anteriores com computadores que executam serviços de
tempo baseados em SNTP, como o Windows 2000.
Protocolo NTP
O NTP (protocolo NTP) é o protocolo de sincronização de tempo padrão usado pelo
Serviço de Horário do Windows no sistema operacional. O NTP é um protocolo de
tempo altamente escalonável e tolerante a falhas e é o protocolo usado com mais
frequência para sincronizar os relógios dos computadores usando uma referência de
hora designada.
A sincronização de tempo do NTP ocorre durante um período de tempo e envolve a

transferência de pacotes de NTP por uma rede. Os pacotes de NTP contêm carimbos de
data/hora que incluem uma amostra de tempo do cliente e do servidor que participa da
sincronização de tempo.
O NTP depende de um relógio de referência para definir o tempo mais preciso a ser
usado e sincroniza todos os relógios em uma rede de acordo com esse relógio de
referência. O NTP usa o UTC (Tempo Universal Coordenado) como o padrão universal
para a hora atual. O UTC não depende dos fusos horários e permite que o NTP seja
usado em qualquer lugar do mundo, independentemente das configurações de fuso
horário.
Algoritmos de NTP
O NTP inclui dois algoritmos, um algoritmo de filtragem de relógio e um algoritmo de

seleção de relógio, para auxiliar o Serviço de Horário do Windows na determinação da
melhor amostra de tempo. O algoritmo de filtragem de relógio foi projetado para
percorrer amostras de tempo recebidas de fontes de horário consultadas e determinar
as melhores amostras de tempo de cada fonte. O algoritmo de seleção de relógio
determina então o servidor de tempo mais preciso na rede. Essas informações são
passadas para o algoritmo de disciplina do relógio, que usa as informações coletadas
para corrigir o relógio local do computador e compensar erros devido à latência da rede
e à imprecisão do relógio do computador.
Os algoritmos NTP são mais precisos em condições de cargas de servidor e rede leves a
moderadas. Assim como acontece com qualquer algoritmo que leva em conta o tempo
de trânsito na rede, os algoritmos NTP podem funcionar inadequadamente em
condições de congestionamento extremo da rede. Para obter mais informações sobre os
algoritmos NTP, confira RFC 1305 no banco de dados RFC da IETF.
Provedor de tempo do NTP

O Serviço de Horário do Windows é um pacote de sincronização de tempo completo
compatível com uma variedade de dispositivos de hardware e protocolos de tempo.
Para habilitar essa compatibilidade, o serviço usa provedores de horário conectáveis.
Um provedor de horário é responsável por obter carimbos de data/hora precisos (da
rede ou do hardware) ou por fornecer esses carimbos de data/hora a outros
computadores na rede.
O provedor de NTP é o provedor de horário padrão incluído no sistema operacional. O

provedor de NTP segue os padrões especificados pelo NTP versão 3 para um cliente e
servidor e pode interagir com clientes e servidores SNTP para compatibilidade com
versões anteriores do Windows 2000 e outros clientes SNTP. O provedor de NTP no
Serviço de Horário do Windows consiste nas duas partes abaixo:
Provedor de saída NtpServer. Esse é um servidor de horário que responde às

solicitações de tempo do cliente na rede.
Provedor de entrada NtpClient. Esse é um cliente de horário que obtém

informações de horário de outra fonte (seja um dispositivo de hardware ou um
servidor de NTP) e pode retornar amostras de tempo que são úteis para
sincronizar o relógio local.
Embora as operações reais desses dois provedores estejam fortemente relacionadas,

eles aparecem de maneira independente ao serviço de horário. Começando com o
Windows 2000 Server, quando um computador com Windows está conectado a uma
rede, ele é configurado como um cliente de NTP. Além disso, os computadores que
executam o Serviço de Horário do Windows só tentam sincronizar a hora com um
controlador de domínio ou uma fonte de horário especificada manualmente por padrão.
Esses são os provedores de horário preferidos porque são fontes de horário seguras
disponíveis automaticamente.
Segurança de NTP
Dentro de uma floresta do AD DS, o Serviço de Horário do Windows depende de
recursos de segurança de domínio padrão para impor a autenticação dos dados de
tempo. A segurança dos pacotes de NTP que são enviados entre um computador
membro do domínio e um controlador de domínio local que está agindo como um
servidor de horário é baseada na autenticação de chave compartilhada. O Serviço de
Horário do Windows usa a chave da sessão Kerberos do computador para criar
assinaturas autenticadas em pacotes de NTP que são enviados pela rede. Os pacotes de
NTP não são transmitidos dentro do canal seguro do Logon de Rede. Em vez disso,
quando um computador solicita a hora de um controlador de domínio na hierarquia de
domínio, o Serviço de Horário do Windows requer que o tempo seja autenticado. O
controlador de domínio retorna as informações necessárias na forma de um valor de 64
bits que foi autenticado com a chave da sessão do serviço Logon de Rede. Se o pacote
NTP retornado não for assinado com a chave da sessão do computador ou estiver
assinado incorretamente, a hora será rejeitada. Todas essas falhas de autenticação são
registradas no Log de eventos. Dessa forma, o Serviço de Horário do Windows fornece
segurança para dados do NTP em uma floresta do AD DS.
Geralmente, os clientes de tempo do Windows obtêm automaticamente de

controladores de domínio no mesmo domínio o tempo preciso para a sincronização. Em
uma floresta, os controladores de domínio de um domínio filho sincronizam a hora com
controladores de domínio em seus domínios pai. Quando um servidor de horário
retorna um pacote de NTP autenticado para um cliente que solicita a hora, o pacote é
assinado por meio de uma chave da sessão Kerberos definida por uma conta de
confiança entre domínios. A conta de confiança entre domínios é criada quando um
novo domínio do AD DS ingressa em uma floresta e o serviço Logon de Rede gerencia a
chave da sessão. Dessa forma, o controlador de domínio configurado como confiável no
domínio raiz da floresta torna-se a fonte de horário autenticada para todos os
controladores de domínio nos domínios pai e filho e, indiretamente, para todos os
computadores localizados na árvore do domínio.
O Serviço de Horário do Windows pode ser configurado para funcionar entre florestas,
mas é importante observar que essa configuração não é segura. Por exemplo, um
servidor NTP pode estar disponível em uma floresta diferente. No entanto, como esse
computador está em uma floresta diferente, não há nenhuma chave da sessão Kerberos
com a qual assinar e autenticar pacotes de NTP. Para obter uma sincronização de tempo
precisa de um computador em uma floresta diferente, o cliente precisa de acesso à rede
para esse computador e o serviço de horário deve ser configurado para usar uma fonte
de horário específica localizada na outra floresta. Se um cliente for configurado
manualmente para acessar o horário de um servidor NTP fora da própria hierarquia de
domínio, os pacotes de NTP enviados entre o cliente e o servidor de horário não serão
autenticados e, portanto, não serão protegidos. Mesmo com a implementação de
relações de confiança de floresta, o Serviço de Horário do Windows não é seguro entre
florestas. Embora o canal de segurança Logon de Rede seja o mecanismo de
autenticação do Serviço de Horário do Windows, não há suporte para autenticação
entre florestas.
Dispositivos de hardware compatíveis com o Serviço de Horário do

Windows
Os relógios baseados em hardware, como o GPS ou os relógios de rádio, geralmente

são usados como dispositivos de relógio de referência altamente precisos. Por padrão, o
provedor de horário NTP do Serviço de Horário do Windows não é compatível com a
conexão direta de um dispositivo de hardware com um computador, embora seja
possível criar um provedor de horário independente baseado em software compatível
com esse tipo de conexão. Esse tipo de provedor, em conjunto com o Serviço de
Horário do Windows, pode fornecer uma referência de tempo estável e confiável.
Dispositivos de hardware, como um relógio atômico ou um receptor de GPS, fornecem

tempo atual preciso seguindo um padrão para obter uma definição precisa do tempo.
Os relógios atômicos são extremamente estáveis e não são afetados por fatores como
temperatura, pressão ou umidade, mas também são muito caros. Um receptor GPS é
muito menos dispendioso para operar e também é um relógio de referência preciso. Os
receptores GPS obtêm seu tempo de satélites que obtêm seu tempo de um relógio
atômico. Sem o uso de um provedor de horário independente, os servidores de horário
do Windows podem obter a hora conectando-se a um servidor de NTP externo, que é
conectado a um dispositivo de hardware por meio de um telefone ou da Internet.
Organizações como o Observatório Naval dos Estados Unidos fornecem servidores NTP
conectados a relógios de referência extremamente confiáveis.
Muitos receptores de GPS e outros dispositivos de tempo podem funcionar como

servidores de NTP em uma rede. Você poderá configurar sua floresta do AD DS para
sincronizar a hora desses dispositivos de hardware externos somente se eles também
estiverem agindo como servidores NTP em sua rede. Para fazer isso, configure o
controlador de domínio que funciona como o emulador do PDC (controlador de
domínio primário) na raiz da floresta para sincronizar com o servidor NTP fornecido pelo
dispositivo GPS. Para fazer isso, confira Configurar o Serviço de Horário do Windows no
emulador do PDC no domínio raiz da floresta.
Protocolo NTP Simples

O SNTP (Protocolo NTP Simples) é um protocolo de tempo simplificado destinado a
servidores e clientes que não exigem o grau de precisão que o NTP fornece. O SNTP,
uma versão mais rudimentar do NTP, é o protocolo de tempo primário usado no
Windows 2000. Como os formatos de pacote de rede do SNTP e do NTP são idênticos,
os dois protocolos são interoperáveis. A principal diferença entre os dois é que o SNTP
não tem o gerenciamento de erros e os sistemas de filtragem complexos que o NTP
fornece. Para obter mais informações sobre o Protocolo NTP Simples, confira RFC 1769
no banco de dados RFC da IETF.
Interoperabilidade de protocolo de tempo

O Serviço de Horário do Windows pode operar em um ambiente misto de
computadores que executam o Windows 2000, o Windows XP e o Windows Server 2003,
pois o protocolo SNTP usado no Windows 2000 é interoperável com o protocolo NTP
no Windows XP e no Windows Server 2003.
O serviço de horário no Windows NT Server 4.0, chamado TimeServ, sincroniza o tempo

em uma rede do Windows NT 4.0. O TimeServ é um recurso complementar disponível
como parte do Kit de Recursos do Microsoft Windows NT 4.0 e não fornece o grau de
confiabilidade da sincronização de tempo necessária para o Windows Server 2003.
O Serviço de Horário do Windows pode interoperar com computadores que executam o

Windows NT 4.0 porque eles podem sincronizar a hora com computadores que
executam o Windows 2000 ou o Windows Server 2003; no entanto, um computador que
executa o Windows 2000 ou o Windows Server 2003 não descobre automaticamente os
servidores de tempo do Windows NT 4.0. Por exemplo, se o domínio estiver configurado
para sincronizar a hora usando o método de sincronização baseado em hierarquia de
domínio e você quiser que os computadores na hierarquia de domínio sincronizem a
hora com um controlador de domínio do Windows NT 4.0, precisará configurar esses
computadores manualmente para sincronizar com os controladores de domínio do
Windows NT 4.0.
O Windows NT 4.0 usa um mecanismo mais simples do que o usado pelo Serviço de
Horário do Windows para a sincronização de tempo. Portanto, para garantir uma
sincronização precisa de tempo em sua rede, é recomendável que você atualize todos
os controladores de domínio do Windows NT 4.0 para o Windows 2000 ou o Windows
Server 2003.
Processos e interações do Serviço de Horário

do Windows
O Serviço de Horário do Windows foi projetado para sincronizar os relógios dos
computadores em uma rede. O processo de sincronização do horário da rede, também
chamado de convergência de tempo, ocorre em uma rede à medida que cada
computador acessa o tempo de um servidor de tempo mais preciso. A convergência de
tempo envolve um processo pelo qual um servidor oficial fornece a hora atual para os
computadores cliente na forma de pacotes de NTP. As informações fornecidas em um
pacote indicam se um ajuste precisa ser feito na hora atual do relógio do computador
para que ele seja sincronizado com o servidor mais preciso.
Como parte do processo de convergência de tempo, os membros do domínio tentam

sincronizar a hora com qualquer controlador de domínio localizado no mesmo domínio.
Se o computador for um controlador de domínio, ele tentará sincronizar com um
controlador de domínio mais confiável.
Computadores que executam o Windows XP Home Edition ou computadores que não

ingressaram em um domínio não tentam sincronizar com a hierarquia de domínio, mas
são configurados por padrão para obter o tempo de time.windows.com.
Para estabelecer um computador executando o Windows Server 2003 como oficial, o

computador deve ser configurado para ser uma fonte de horário confiável. Por padrão,
o primeiro controlador de domínio instalado em um domínio do Windows Server 2003 é
configurado automaticamente para ser uma fonte de horário confiável. Como é o
computador oficial do domínio, ele deve ser configurado para sincronizar com uma
fonte de horário externa em vez de fazê-lo com a hierarquia de domínio. Além disso,
por padrão, todos os outros membros do domínio do Windows Server 2003 são
configurados para sincronizar com a hierarquia de domínio.
Depois de estabelecer uma rede do Windows Server 2003, você pode configurar o
Serviço de Horário do Windows para usar uma das seguintes opções de sincronização:
Sincronização baseada em hierarquia de domínio
Uma origem de sincronização especificada manualmente
Todos os mecanismos de sincronização disponíveis
Nenhuma sincronização.
Cada um desses tipos de sincronização é discutido na seção a seguir.
Sincronização baseada em hierarquia de domínio

A sincronização baseada em uma hierarquia de domínio usa a hierarquia de domínio do
AD DS para encontrar uma fonte confiável com a qual sincronizar a hora. Com base na
hierarquia de domínio, o Serviço de Horário do Windows determina a precisão de cada
servidor de horário. Em uma floresta do Windows Server 2003, o computador que
contém a função de mestre de operações do emulador de PDC (controlador de domínio
primário), localizada no domínio raiz da floresta, mantém a posição da melhor fonte de
horário, a menos que outra fonte de horário confiável tenha sido configurada. A figura a
seguir ilustra um caminho de sincronização de tempo entre computadores em uma
hierarquia de domínio.
Sincronização de tempo em uma hierarquia do AD DS
Configuração de fonte de horário confiável
Um computador configurado para ser uma fonte de horário confiável é identificado

como a raiz do serviço de horário. A raiz do serviço de horário é o servidor oficial para o
domínio e normalmente é configurada para recuperar o tempo de um servidor NTP
externo ou dispositivo de hardware. Um servidor de horário pode ser configurado como
uma fonte de horário confiável para otimizar como o tempo é transferido por toda a
hierarquia de domínio. Se um controlador de domínio estiver configurado para ser uma
fonte de horário confiável, o serviço Logon de Rede anunciará esse controlador de
domínio como uma fonte de horário confiável quando ele fizer logon na rede. Quando
outros controladores de domínio procuram uma fonte de horário com a qual
sincronizar, eles escolhem uma fonte confiável primeiro, se disponível.
Seleção de fonte de horário

O processo de seleção da fonte de horário pode criar dois problemas em uma rede:
Ciclos de sincronização adicionais.
Aumento do volume no tráfego de rede.
Um ciclo na rede de sincronização ocorre quando o tempo permanece consistente entre

um grupo de controladores de domínio e o mesmo tempo é compartilhado entre eles
continuamente sem uma ressincronização com outra fonte de horário confiável. O
algoritmo de seleção de fonte de horário do Serviço de Horário do Windows é
projetado para proteger contra esses tipos de problemas.
Um computador usa um dos seguintes métodos para identificar uma fonte de horário
com a qual sincronizar:
Se o computador não é membro de um domínio, ele deve ser configurado para

sincronizar com uma fonte de horário especificada.
Se o computador é um servidor membro ou uma estação de trabalho em um

domínio, por padrão, ele segue a hierarquia do AD DS e sincroniza seu horário
com um controlador de domínio em seu domínio local que esteja atualmente
executando o Serviço de Horário do Windows.
Se o computador é um controlador de domínio, ele faz até seis consultas para localizar
outro controlador de domínio com o qual sincronizar. Cada consulta é projetada para
identificar uma fonte de horário com determinados atributos, como um tipo de
controlador de domínio, uma localização específica e se é uma fonte de horário
confiável ou não. A fonte de horário também deve aderir às seguintes restrições:
Uma fonte de horário confiável só pode sincronizar com um controlador de

domínio no domínio pai.
Um emulador de PDC pode sincronizar com uma fonte de horário confiável em um

domínio próprio ou em qualquer controlador de domínio no domínio pai.
Se o controlador de domínio não for capaz de sincronizar com o tipo de controlador de
domínio que está consultando, a consulta não será feita. O controlador de domínio sabe
de qual tipo de computador ele pode obter tempo antes de fazer a consulta. Por
exemplo, um emulador de PDC local não tenta consultar os números três ou seis porque
um controlador de domínio não tenta sincronizar-se com ele mesmo.
A tabela a seguir lista as consultas que um controlador de domínio faz para localizar
uma fonte de horário e a ordem na qual as consultas são feitas.
Consultas de fonte de horário do controlador de domínio
Número Controlador Local Confiabilidade da fonte de horário

da de domínio
consulta
1 Controlador No Prefere uma fonte de horário confiável, mas poderá

de domínio local sincronizar com uma fonte de horário não confiável se for o
pai que está disponível.
2 Controlador No Só sincroniza com uma fonte de horário confiável.

de domínio local
local
3 Emulador de No Não se aplica.

PDC local local Um controlador de domínio não tenta sincronizar com ele
mesmo.
4 Controlador Fora Prefere uma fonte de horário confiável, mas poderá

de domínio do sincronizar com uma fonte de horário não confiável se for o
pai site que está disponível.
5 Controlador Fora Só sincroniza com uma fonte de horário confiável.

de domínio do
local site
6 Emulador de Fora Não se aplica.

PDC local do Um controlador de domínio não tenta sincronizar com ele
site mesmo.
Observação
Um computador nunca sincroniza com ele mesmo. Se o computador que está

tentando sincronizar for o emulador de PDC local, ele não tentará as consultas 3
ou 6.
Cada consulta retorna uma lista de controladores de domínio que podem ser usados
como uma fonte de horário. O Horário do Windows atribui a cada controlador de
domínio uma pontuação que é consultada com base na confiabilidade e na localização
do controlador de domínio. A tabela a seguir lista as pontuações atribuídas pelo Horário
do Windows a cada tipo de controlador de domínio.
Determinação da Pontuação
Status do controlador de domínio Pontuação
Controlador de domínio localizado no mesmo site 8
Controlador de domínio marcado como uma fonte de horário confiável 4
Controlador de domínio localizado no domínio pai 2
Controlador de domínio que é um emulador de PDC 1
Quando o Serviço de Horário do Windows determina que identificou o controlador de

domínio com a melhor pontuação possível, ele para de fazer consultas. As pontuações
atribuídas pelo serviço de horário são cumulativas, o que significa que um emulador de
PDC localizado no mesmo site recebe uma pontuação igual a nove.
Se a raiz do serviço de horário não estiver configurada para sincronizar com uma fonte
externa, o relógio de hardware interno do computador controlará o tempo.
Sincronização especificada manualmente

A sincronização especificada manualmente permite designar um par ou uma lista de
pares dos quais um computador obtém o tempo. Se o computador não é membro de
um domínio, ele deve ser configurado manualmente para sincronizar com uma fonte de
horário especificada. Um computador que é membro de um domínio é configurado por
padrão para sincronizar na hierarquia de domínio; a sincronização especificada
manualmente é mais útil para a raiz de floresta do domínio ou para computadores que
não fazem parte de um domínio. A especificação manual de um servidor NTP externo
para sincronizar com o computador oficial do seu domínio fornece um tempo confiável.
No entanto, configurar o computador oficial do seu domínio para sincronizar com um
relógio de hardware é, na verdade, uma solução melhor para fornecer o tempo mais
preciso e seguro para o seu domínio.
As fontes de horários especificadas manualmente não são autenticadas, a menos que

um provedor de horário específico seja gravado para elas e, portanto, seja vulnerável a
invasores. Além disso, se um computador sincronizar com uma fonte especificada
manualmente em vez de seu controlador de domínio de autenticação, os dois
computadores poderão ficar fora de sincronização, causando a falha da autenticação
Kerberos. Isso pode causar falha em outras ações que exigem autenticação de rede,
como impressão ou compartilhamento de arquivos. Se apenas a raiz da floresta estiver
configurada para sincronizar com uma fonte externa, todos os outros computadores da
floresta permanecerão sincronizados entre si, dificultando os ataques de repetição.
Todos os mecanismos de sincronização disponíveis

A opção "todos os mecanismos de sincronização disponíveis" é o método de
sincronização mais valioso para usuários em uma rede. Esse método permite a
sincronização com a hierarquia do domínio e também pode fornecer uma fonte de
horário alternativa, caso a hierarquia do domínio não esteja disponível, dependendo da
configuração. Se o cliente não puder sincronizar a hora com a hierarquia do domínio, a
fonte de horário automaticamente voltará para a fonte de horário especificada pela
configuração NtpServer. Esse método de sincronização tem maior probabilidade de
fornecer um tempo preciso para os clientes.
Parando a sincronização de tempo

Há algumas situações em que você desejará impedir que um computador sincronize seu
tempo. Por exemplo, se um computador tentar sincronizar usando uma fonte de horário
da Internet ou outro site por meio de uma WAN de uma conexão discada, isso poderá
gerar altos encargos de telefone. Ao desabilitar a sincronização nesse computador, você
impedirá que o computador tente acessar uma fonte de horário por meio de uma
conexão discada.
Você também pode desabilitar a sincronização para evitar a geração de erros no log de
eventos. Cada vez que um computador tenta sincronizar com uma fonte de horário que
não está disponível, ele gera um erro no Log de Eventos. Se uma fonte de horário for
retirada da rede para manutenção agendada e você não pretender reconfigurar o
cliente para sincronizar com outra fonte, você poderá desabilitar a sincronização no
cliente para impedi-lo de tentar a sincronização enquanto o servidor de horário não
estiver disponível.
É útil desabilitar a sincronização no computador designado como a raiz da rede de

sincronização. Isso indica que o computador raiz confia em seu relógio local. Se a raiz da
hierarquia de sincronização não estiver definida como NoSync e se não for possível
sincronizar com outra fonte de horário, os clientes não aceitarão o pacote enviado por
esse computador, pois seu tempo não é confiável.
Os únicos servidores de tempo que são confiáveis para os clientes, mesmo que não
tenham sido sincronizados com outra fonte de horário, são aqueles identificados pelo
cliente como servidores de horário confiáveis.
Desabilitando o Serviço de Horário do Windows
O Serviço de Horário do Windows (W32Time) pode ser completamente desabilitado. Se
você optar por implementar um produto de sincronização de tempo de terceiros que
usa o NTP, será necessário desabilitar o Serviço de Horário do Windows. Isso ocorre
porque todos os servidores NTP precisam de acesso à porta 123 do protocolo UDP e,
enquanto o Serviço de Horário do Windows estiver em execução no sistema operacional
Windows Server 2003, a porta 123 permanecerá reservada pelo Horário do Windows.
Portas de rede usadas pelo Serviço de Horário

do Windows
O Serviço de Horário do Windows se comunica em uma rede para identificar fontes de
horário confiáveis, obter informações de tempo e fornecer informações de tempo a
outros computadores. Ele executa essa comunicação conforme definido pelas RFCs de
NTP e SNTP.
Atribuições de porta para o Serviço de Horário do Windows
Nome do serviço UDP TCP
NTP 123 N/D
SNTP 123 N/D
Consulte Também
Windows Time Service Technical ReferenceWindows Time Service Tools and
SettingsWindows Time Service (W32Time)
Ferramentas e configurações do Serviço
de Tempo do Windows
Windows Server 2012 R2, Windows Server 2012, Windows 10, Azure Stack HCI,
versões 21H2 e 20H2
O Serviço de Hora do Windows (W32Time) sincroniza a data e a hora de todos os

computadores gerenciados pelo AD DS (Active Directory Domain Services). Este artigo
aborda as diferentes ferramentas e configurações usadas para gerenciar o Serviço de
Hora do Windows.
Por padrão, um computador ingressado em um domínio sincroniza a hora por meio de

uma hierarquia de domínio de fontes de hora. No entanto, se um computador tiver sido
configurado manualmente para sincronizar de uma fonte de hora específica, talvez por
não estar ingressado em um domínio anteriormente, você poderá reconfigurá-lo para
começar a obter a hora automaticamente da hierarquia de domínio.
A maioria dos computadores conectados ao domínio tem o tipo de cliente de hora

NT5DS, o que significa que sincronizam a hora com base na hierarquia de domínio. Uma
exceção é o controlador de domínio, que funciona como o mestre de operações do
emulador PDC (controlador de domínio primário) do domínio da floresta raiz. O mestre
de operações do emulador PDC, por sua vez, está configurado para sincronizar o tempo
com uma fonte de tempo externa.
Você pode alcançar uma precisão de hora de um milissegundo em seu domínio. Para
saber mais, confira Limite de suporte para hora de alta precisão e Hora precisa para o
Ｕ Cuidado
Não use o comando Net time para configurar nem definir a hora do relógio de um
computador quando o Serviço de Hora do Windows estiver em execução.
Além disso, em computadores mais antigos que executam o Windows XP ou

anterior, o comando Net time /querysntp exibe o nome de um servidor de
protocolo NTP com o qual o computador está configurado para sincronizar, mas
esse servidor NTP é usado somente quando o cliente de hora do computador está
configurado como NTP ou AllSync. Esse comando foi preterido.
Porta de rede
O Serviço de Hora do Windows segue a especificação do protocolo NTP, que requer o
uso da porta UDP 123 para toda a sincronização de hora. Sempre que o computador
sincronizar o relógio ou fornecer a hora a outro computador, isso ocorrerá por meio da
porta UDP 123. Essa porta é reservada exclusivamente pelo Serviço de Hora do
Windows.
７ Observação
Se você tem um computador com vários adaptadores de rede (ou

multihomed), não poderá habilitar o Serviço de Hora do Windows com base
no adaptador de rede.
O cliente NTP do Tempo do Windows usa a porta UDP 123 para solicitações
de sincronização de origem e destino. Ao usar a filtragem de rede, lembre-se
da porta de origem que está sendo usada.
Usando W32tm.exe
Use a ferramenta de linha de comando W32tm.exe para definir as configurações do
Serviço de Hora do Windows e diagnosticar problemas com a hora do computador. O
W32tm.exe é a ferramenta de linha de comando preferencial para configurar, monitorar
e solucionar problemas do Serviço de Hora do Windows. O W32tm.exe é incluído no
Windows XP e posteriores e no Windows Server 2003 e posteriores.
A associação ao grupo Administradores local é necessária para executar o W32tm.exe

localmente, enquanto a associação ao grupo Administradores de Domínio é necessária
para executar o W32tm.exe remotamente.
Executar o W32tm.exe
1. Na barra de pesquisa do Windows, insira cmd.
2. Clique com o botão direito do mouse em Prompt de Comando e selecione
Executar como administrador.
3. No prompt de comando, digite w32tm seguido pelo parâmetro aplicável,
conforme descrito abaixo:
/? Exibe a ajuda da linha de comando do W32tm
/register Registra o Serviço de Hora do Windows para ser executado

como um serviço e adiciona as informações de configuração
padrão ao Registro.
/unregister Cancela o registro do Serviço de Hora do Windows e remove

todas as informações de configuração do Registro.
/monitor [/domain:<domain Monitora o Serviço de Hora do Windows.

name>] [/computers:<name>[, /domain: especifica o domínio a ser monitorado. Se nenhum
<name>[,<name>...]]] nome de domínio for especificado ou se a opção /domain nem
[/threads:<núm>] a opção /computers for especificada, o domínio padrão será
usado. Esta opção pode ser usada mais de uma vez.
/computers: monitora a lista de computadores fornecida. Os

nomes de computador são separados por vírgulas, sem espaços.
Se um nome for prefixado com um * , ele será tratado como um
PDC. Esta opção pode ser usada mais de uma vez.
/threads: especifica o número de computadores a serem

analisados simultaneamente. O valor padrão é 3. O intervalo
permitido é de 1 a 50.
/ntte<Época de tempo NT> Converte uma hora do sistema do Windows NT (medida em

intervalos de 10-7 segundos começando à 0h de 1º de janeiro
de 1601) em um formato legível.
/ntpte<Época de tempo NTP> Converte uma hora do NTP (medida em intervalos de 2-32
segundos começando à 0h de 1º de janeiro de 1900) em um
formato legível.
/resync [/computer: Informa a um computador que ele deve ressincronizar seu

<computer>] [/nowait] relógio assim que possível, descartando todas as estatísticas de
[/rediscover] [/soft] erro acumuladas.
/computer:<computer> : especifica o computador que deve ser
ressincronizado. Se não for especificado, o computador local
será ressincronizado.
/nowait: não aguardar a ressincronização; retornar

imediatamente. Caso contrário, aguardar a ressincronização ser
concluída antes de retornar.
/rediscover: detecta novamente a configuração de rede,

redescobre as fontes de rede e ressincroniza.
/soft: faz a ressincronização usando as estatísticas de erro

existentes. É usado para fins de compatibilidade.
/stripchart /computer: Exibe um gráfico de faixas da diferença entre este e outro

<target> [/period:<refresh>] computador.
[/dataonly] [/samples:<count>] /computer:<target> : o computador em relação ao qual a
[/rdtsc] diferença será medida.
/period:<refresh> : o tempo entre amostras, em segundos. O

padrão é 2 segundos.
/dataonly: exibe somente os dados, sem gráficos.
/samples:<count>: coleta < amostras de contagem> e, em

seguida, para. Se não for especificado, os exemplos serão
coletados até que CTRL+C seja pressionado.
/rdtsc: para cada amostra, essa opção imprime valores

separados por vírgula junto com os cabeçalhos RdtscStart,
RdtscEnd, FileTime, RoundtripDelay e NtpOffset, em vez do
gráfico de texto.
RdtscStart: valor do RDTSC (Contador de Carimbos de

Data/Hora de Leitura) coletado antes da geração da
solicitação NTP.
RdtscEnd: valor do RDTSC coletado logo após o
recebimento e o processamento da resposta NTP.
FileTime: valor de FILETIME local usado na solicitação
NTP.
RoundtripDelay: tempo decorrido em segundos entre a
geração da solicitação NTP e o processamento da
resposta NTP recebida, obtido conforme os cálculos de
viagem de ida e volta do NTP.
NTPOffset: diferença de horário em segundos entre o
computador local e o servidor NTP, obtida conforme os
cálculos da diferença do NTP.
/config [/computer:<target>] /computer:<target>: ajusta a configuração do <destino>. Se

[/update] [/manualpeerlist: não for especificada, o padrão será o computador local.
<peers>] [/syncfromflags:
<source>] /update: notifica o Serviço de Hora do Windows de que a
[/LocalClockDispersion: configuração foi alterada, fazendo com que as alterações
<seconds>] [/reliable:(YES|NO)] entrem em vigor.
[/largephaseoffset:
/manualpeerlist:<peers>: define a lista de pares manual como
<milliseconds>]**
<pares>, que é uma lista delimitada por espaço de endereços
DNS ou IP. Ao especificar vários pares, essa opção deve ser
colocada entre aspas.
/syncfromflags:<source> : define de quais fontes o cliente NTP

deve fazer a sincronização. <Fonte> deve ser uma lista separada
por vírgulas dessas palavras-chave (não diferencia maiúsculas
de minúsculas):
MANUAL: inclui pares da lista de pares manuais.

DOMHIER: faz a sincronização de um DC (controlador de
domínio) na hierarquia de domínio.
/LocalClockDispersion:<seconds> : configura a precisão do

relógio interno que o W32Time presumirá quando não puder
adquirir a hora das fontes configuradas.
/reliable:(YES|NO): defina se este computador é uma fonte de

tempo confiável. Essa configuração só é significativa em
controladores de domínio.
SIM: este computador é um serviço de hora confiável.

NÃO: este computador não é um serviço de hora
confiável.
/largephaseoffset:<milissegundos>: define a diferença de

tempo entre a hora local e a rede que w32Time considerará um
pico.
/tz Exibe as configurações de fuso horário atuais.
/dumpreg [/subkey:<key>] Exibe os valores associados a uma determinada chave do

[/computer:<target>] Registro.
A chave padrão é
HKLM\System\CurrentControlSet\Services\W32Time (a chave
raiz do Serviço de Hora do Windows).
/subkey:<key>: exibe os valores associados à chave> de

subchave <da chave padrão.
/computer:<target> : consulta as configurações do Registro

para o computador <target>
/query [/computer:<target>] Exibe as informações do Serviço de Hora do Windows do

{/source | /configuration | computador. Esse parâmetro foi disponibilizado pela primeira
/peers | /status} [/verbose] vez no cliente de Hora do Windows no Windows Vista e no
/computer:<target>: consulta as informações de <destino>. Se
não for especificado, o valor padrão será o computador local.
/source: exibe a fonte de hora.
/configuration: exibe a configuração da hora de execução e a

origem da configuração. No modo detalhado, exibir a
configuração indefinida ou não usada também.
/peers: exibe uma lista de pares e o respectivo status.
/status: exibe o status do Serviço de Hora do Windows.
/verbose: define o modo detalhado para exibir mais

informações.
/debug {/disable | {/enable habilita ou desabilita o log privado do Serviço de Hora do

/file:<Nome> /size:/<bytes> Windows do computador local. Esse parâmetro foi
/entries:<value> [/truncate]}} disponibilizado pela primeira vez no cliente de Hora do
Windows no Windows Vista e no Windows Server 2008.
/disable: desabilita o log privado.
/enable: habilita o log privado.
file:<name> : especifica o nome de arquivo absoluto.

size:<bytes> : especifica o tamanho máximo para o log
circular.
entries:<value> : contém uma lista de sinalizadores,
especificados por número e separados por vírgulas, que
especificam os tipos de informações que devem ser
registradas em log. Os valores válidos são de 0 a 300.
Uma variedade de números é válida, além de números
únicos, como 0-100.103.106. O valor 0-300 é para
registrar em log todas as informações.
/truncate: trunca o arquivo, se ele existir.
Definir o cliente para usar dois servidores de hora

Para definir um computador cliente para apontar para dois servidores de hora
diferentes, um chamado ntpserver.contoso.com e outro chamado clock.adatum.com ,
digite o seguinte comando no prompt de comando e pressione ENTER:
cmd
w32tm /config /manualpeerlist:"ntpserver.contoso.com clock.adatum.com"

/syncfromflags:manual /update
Definir o cliente para sincronizar a hora automaticamente

de uma origem de domínio
Para configurar um computador cliente que está sincronizando o tempo usando um
computador especificado manualmente para sincronizar o tempo automaticamente da
hierarquia de domínio do AD, execute o seguinte:
cmd
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
Verificar a configuração de hora do cliente

Para verificar a configuração de um cliente em um computador cliente baseado no
Windows que tenha um nome de host contosoW1 , execute o seguinte comando:
cmd
W32tm /query /computer:contosoW1 /configuration
O resultado desse comando exibe uma lista de parâmetros de configuração de W32time

que são definidos para o cliente.
） Importante
O Windows Server 2016 aprimorou os algoritmos de sincronização de tempo

para se alinhar com as especificações de RFC. Portanto, se você quiser definir o
cliente de hora local para apontar para vários pares, é altamente recomendável
preparar três ou mais servidores de hora diferentes.
Se você tiver apenas dois servidores de tempo, deverá especificar o sinalizador

Ntpserver UseAsFallbackOnly (0x2) para despriorizar um deles. Por exemplo, se
você quiser priorizar ntpserver.contoso.com sobre clock.adatum.com , execute o
seguinte comando:
cmd
w32tm /config /manualpeerlist:"ntpserver.contoso.com,0x8

clock.adatum.com,0x2" /syncfromflags:manual /update
Além disso, você pode executar o seguinte comando e ler o valor de NtpServer na
saída:
cmd
reg query HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
Configurar a redefinição do relógio do computador

Para que o W32tm.exe redefina o relógio de um computador, primeiro ele verifica o
deslocamento ( CurrentTimeOffset , também conhecido como Phase Offset ) entre o
horário atual e o horário do relógio do computador para determinar se o deslocamento
é menor que o valor MaxAllowedPhaseOffset .
CurrentTimeOffset MaxAllowedPhaseOffset ≤: ajuste o relógio do computador

gradualmente usando a taxa do relógio.
CurrentTimeOffset > MaxAllowedPhaseOffset : defina o relógio do computador
imediatamente.
Em seguida, para ajustar o relógio do computador usando a taxa do relógio, W32tm.exe

calcula um valor PhaseCorrection . Esse algoritmo varia dependendo da versão do
Windows:
Windows Server 2016 e versões mais recentes:
PhaseCorrection_raw = | CurrentTimeOffset | ÷ (16 × PhaseCorrectRate ×

pollIntervalInSeconds )
MaximumCorrection = | CurrentTimeOffset | ÷ ( UpdateInterval ÷ 100)
PhaseCorrection = min( PhaseCorrection_raw , MaximumCorrection )
Windows Server 2012 R2 e versões anteriores:

Para obter o SystemClockRate valor, você pode usar o seguinte comando e convertê-lo
de segundos em tiques de relógio usando a fórmula de (segundos × 1.000 × 10.000):
PhaseCorrection = | CurrentTimeOffset | ÷ ( PhaseCorrectRate × UpdateInterval )
Todas as versões do Windows usam a mesma equação final para verificar

PhaseCorrection :
PhaseCorrection SystemClockRate ≤ ÷ 2
７ Observação
O Windows Server 2019 e o Windows 10 1809 têm a mesma fórmula que

[Windows Server 2016 e versões posteriores] descritas acima aplicando
atualizações cumulativas de KB5006744 em diante.
Essas equações usam PhaseCorrectRate , UpdateInterval ,

MaxAllowedPhaseOffset e SystemClockRate medidos em unidades de tiques de
relógio. Em sistemas Windows, 1 ms = 10.000 tiques de relógio.
MaxAllowedPhaseOffset é configurável no Registro. No entanto, o parâmetro
de Registro é medido em segundos, em vez de tiques de relógio.
Para ver os valores SystemClockRate e pollIntervalInSeconds (medidos em

segundos), abra uma janela do Prompt de comando e, em seguida, execute
W32tm /query /status /verbose . Esse comando produz uma saída semelhante
ao descrito a seguir.
A saída apresenta o intervalo de sondagem em tiques do relógio e em

segundos. As equações usam o valor medido em segundos (o valor entre
parênteses).
A saída apresenta a taxa do relógio em segundos. Para ver o valor

SystemClockRate em tiques do relógio, use a seguinte fórmula:
( value in seconds ) × 1.000 × 10.000
Por exemplo, se SystemClockRate for 0,0156250 segundos, o valor usado pela

equação será de 156.250 tiques do relógio.
Para obter descrições completas
dos parâmetros configuráveis e os valores padrão deles, confira Entradas de
configuração mais adiante neste artigo.
Os exemplos a seguir mostram como aplicar esses cálculos para o Windows Server 2012
R2 e versões anteriores.
Exemplo: taxa do relógio do sistema deslocada em quatro minutos

A hora do relógio do computador é 11h05 e a hora atual real é 11h09:
PhaseCorrectRate = 1
UpdateInterval = 30.000 tiques do relógio
SystemClockRate = 156.000 tiques do relógio

MaxAllowedPhaseOffset = 10 min = 600 segundos = 600 × 1.000 × 10.000 =
6.000.000.000 tiques de relógio
| CurrentTimeOffset | = 4 min = 4 × 60 × 1.000 × 10.000 = 2.400.000.000 tiques de

relógio
É CurrentTimeOffset ≤ MaxAllowedPhaseOffset ?
2.400.000.000 ≤ 6.000.000.000: TRUE
E atende à equação a seguir?
(| CurrentTimeOffset | ÷ ( PhaseCorrectRate × UpdateInterval ) ≤ SystemClockRate ÷

2)
É 2.400.000.000 / (30.000 × 1) ≤ 156.000 ÷ 2
80.000 ≤ 78.000: FALSO
Portanto, W32tm.exe atrasaria o relógio imediatamente.
７ Observação
Nesse caso, se você quiser atrasar o relógio lentamente, também precisará ajustar
os valores de PhaseCorrectRate ou UpdateInterval no Registro para garantir que o
resultado da equação seja TRUE.
Exemplo: taxa do relógio do sistema deslocada em três minutos

A hora do relógio do computador é 11h05 e a hora atual real é 11h08:
PhaseCorrectRate = 1
UpdateInterval = 30.000 tiques do relógio
SystemClockRate = 156.000 tiques do relógio
MaxAllowedPhaseOffset = 10 min = 600 segundos = 600 × 1.000 × 10.000 =

6.000.000.000 tiques de relógio
| CurrentTimeOffset | = 3 minutos = 3 × 60 × 1.000 × 10.000 = 1.800.000.000 tiques

de relógio
É CurrentTimeOffset ≤ MaxAllowedPhaseOffset ?
1.800.000.000 ≤ 6.000.000.000: TRUE
E atende à equação a seguir?
(| CurrentTimeOffset | ÷ ( PhaseCorrectRate × UpdateInterval ) ≤ SystemClockRate ÷

2)
(1.800.000.000) ÷ (1 × 30.000) ≤ 156.000 ÷ 2
É 60.000 ≤ 78.000: TRUE
Nesse caso, o relógio será atrasado lentamente.
Como usar o Editor de Política de Grupo local

O serviço Tempo do Windows armazena várias propriedades de configuração como
entradas do Registro. Você pode usar GPOs (Objetos de Política de Grupo) no Editor de
Política de Grupo Local para configurar a maioria dessas informações. Por exemplo, use
GPOs para configurar um computador para ser um NTPServer ou um NTPClient,
configurar o mecanismo de sincronização de hora e configurar um computador para ser
uma fonte de hora confiável.
７ Observação
As configurações da Política de Grupo do Serviço de Hora do Windows podem ser

aplicadas nos controladores de domínio do Windows Server 2003, do Windows
Server 2003 R2, do Windows Server 2008 e do Windows Server 2008 R2 e podem
ser aplicadas a computadores que executam o Windows Server 2003, o Windows
Server 2003 R2, o Windows Server 2008 e o Windows Server 2008 R2.
O Windows armazena as informações de política de Serviço de Hora do Windows no

Editor de Política de Grupo Local em Computer Configuration\Administrative
Templates\System\Windows Time Service . Ele armazena as informações de configuração
que as políticas definem no Registro do Windows e usa essas entradas do Registro para
configurar as entradas do Registro específicas para o Serviço de Hora do Windows.
Como resultado, os valores definidos pela Política de Grupo substituem os valores pré-
existentes na seção do Serviço de Hora do Windows do Registro. Algumas das
configurações predefinidas do GPO são diferentes das entradas do Registro do Serviço
de Hora do Windows padrão correspondentes.
Por exemplo, suponha que você edite as configurações de política na política

Provedores de Hora\Configurar o Cliente NTP do Windows. O Windows carrega essas
configurações na área de política do Registro na seguinte subchave:
HKLM\Software\Policies\Microsoft\W32time\TimeProviders\NtpClient
Em seguida, o Windows usa as configurações de política para definir as entradas do

Registro do Serviço de Hora do Windows relacionadas na seguinte subchave:
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NTPClient\
A tabela a seguir lista as políticas que podem ser configuradas para o Serviço de Hora
do Windows e as subchaves do Registro que essas políticas afetam.
７ Observação
Quando você remove uma configuração de Política de Grupo, o Windows remove a

entrada correspondente da área de política do Registro.
Política de Grupo1 Locais do Registro2,3
Configurações Globais W32Time
W32Time\Config
W32Time\Parameters
Time Providers\Configure Windows NTP Client W32Time\TimeProviders\NtpClient
Time Providers\Enable Windows NTP Client W32Time\TimeProviders\NtpClient
Time Providers\Enable Windows NTP Server W32Time\TimeProviders\NtpServer
1
Category path: Computer Configuration\Administrative Templates\System\Windows Time
Service
2 Subchave: HKLM\SOFTWARE\Policies\Microsoft
3 Subchave: HKLM\SYSTEM\CurrentControlSet\Services
Referência do Registro do Windows

２ Aviso
Essas informações são fornecidas como referência para uso na solução de

problemas e validação. As chaves do Registro do Windows são usadas pelo
W32Time para armazenar informações críticas. Não altere esses valores. As
modificações no Registro não são validadas pelo Editor de Registro nem pelo
sistema operacional Windows antes de serem aplicadas. Se o Registro contiver
valores inválidos, o Windows poderá apresentar erros fatais.
O Serviço de Hora do Windows armazena informações no Registro no caminho

HKLM\SYSTEM\CurrentControlSet\Services\W32Time nas seguintes subchaves:
\Config
\Parameters
\TimeProviders\NtpClient
\TimeProviders\NtpServer
Nas tabelas a seguir, "Todas as versões" ao Windows 7, ao Windows 8, ao Windows 10,

ao Windows Server 2008 e ao Windows Server 2008 R2, ao Windows Server 2012 e ao
Windows Server 2012 R2, ao Windows Server 2016 e ao Windows Server 2019.
７ Observação
Alguns dos parâmetros do Registro são medidos em tiques do relógio e outros são
medidos em segundos. Para converter a hora de tiques do relógio em segundos,
use estes fatores de conversão:
1 minuto = 60 s
1 s = 1000 ms
1 ms = 10.000 tiques do relógio em um sistema Windows, conforme descrito
na Propriedade DateTime.Ticks.
Por exemplo, 5 minutos se tornam 5 × 60 × 1000 × 10000 = 3.000.000.000 tiques

de relógio.
Entradas de configuração
As entradas de subchave Config estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config .
Entrada de registro Versões Descrição
AnnounceFlags Todas as Controla se este computador está marcado

versões como um servidor de horário confiável. Um
computador não será marcado como confiável,
a menos que também esteja marcado como
um servidor de horário.
0x00. Não é um servidor de horário
0x01. Sempre um servidor de horário
0x02. Servidor de horário automático
0x04. Servidor de horário sempre
confiável
0x08. Servidor de horário confiável
automático
O valor padrão para membros do domínio é

10. O valor padrão para clientes e servidores
autônomos é 10.
ChainDisable Controla se o mecanismo de encadeamento

está desabilitado. Se o encadeamento estiver
desabilitado (definido como 0), um RODC
(controlador de domínio somente leitura)
poderá ser sincronizado com qualquer
controlador de domínio, mas os hosts que não
tiverem as senhas armazenadas em cache no
RODC não poderão ser sincronizados com o
RODC. Trata-se de uma configuração booliana,
e o valor padrão é 0.
ChainEntryTimeout Especifica o tempo máximo que uma entrada

pode permanecer na tabela de encadeamento
antes de a entrada ser considerada como
expirada. As entradas expiradas poderão ser
removidas quando a próxima solicitação ou
resposta for processada. O valor padrão é 16
(segundos).
ChainLoggingRate Controla a frequência com a qual um evento

que indica o número de tentativas de
encadeamento com e sem êxito é registrado
no log do sistema no Visualizador de Eventos.
O padrão é 30 (minutos).
ChainMaxEntries Controla o número máximo de entradas

permitidas na tabela de encadeamento. Se a
tabela de encadeamento estiver cheia e
nenhuma entrada expirada puder ser
removida, as solicitações de entrada serão
descartadas. O valor padrão é 128 (entradas).
ChainMaxHostEntries Controla o número máximo de entradas

permitidas na tabela de encadeamento para
um host específico. O valor padrão é 4
(entradas).
ClockAdjustmentAuditLimit Windows Especifica os menores ajustes do relógio local

Server 2016 que podem ser registrados no log de eventos
versão do serviço W32time no computador de
1709 e destino. O valor padrão é 800 (PPM – partes
versões por milhão).
posteriores;
Windows
10 versão
1709 e
versões
posteriores
ClockHoldoverPeriod Windows Indica o número máximo de segundos que um

Server 2016 relógio do sistema pode manter nominalmente
versão a precisão sem sincronizar com uma fonte de
1709 e hora. Se esse período passar sem o W32time
versões obter novas amostras de um dos provedores
posteriores; de entrada, o W32time iniciará uma
Windows redescoberta de fontes de hora. Default: 7.800
10 versão segundos.
1709 e
versões
posteriores
EventLogFlags Todas as Controla os eventos que o serviço de hora

versões registra em log.
0x1. Salto de tempo
0x2. Alteração da origem
O valor padrão em membros do domínio é 2.

O valor padrão em clientes e servidores
autônomos é 2.
FrequencyCorrectRate Todas as Controla a velocidade na qual o relógio é

versões corrigido. Se esse valor for muito pequeno, o
relógio ficará instável e realizará uma correção
excessiva. Se o valor for muito grande, o
relógio levará muito tempo para sincronizar. O
valor padrão em membros do domínio é 4. O
valor padrão em clientes e servidores
autônomos é 4.
Observação
Zero não é um valor válido para a entrada do

Registro FrequencyCorrectRate. Nos
computadores Windows Server 2003, Windows
Server 2003 R2, Windows Server 2008 e
Windows Server 2008 R2, se o valor for
definido como 0, o serviço de Horário do
Windows o alterará automaticamente para 1.
HoldPeriod Todas as Controla o período para o qual a detecção de

versões picos é desabilitada, a fim de colocar o relógio
local em sincronização rapidamente. Um pico é
um exemplo de tempo que indica que o tempo
está desativado em vários segundos e é
recebido depois que amostras de tempo boas
são retornadas consistentemente. O valor
padrão em membros do domínio é 5. O valor
padrão em clientes e servidores autônomos é
5.
LargePhaseOffset Todas as Especifica que uma diferença de horário

versões superior ou igual a esse valor em 10-7
segundos é considerada um pico. Uma
interrupção de rede, como uma grande
quantidade de tráfego, pode causar um pico.
Um pico será ignorado, a menos que persista
por um longo período. O valor padrão em
membros do domínio é 50.000.000. O valor
padrão em clientes e servidores autônomos é
50.000.000.
LastClockRate Todas as Mantida pelo W32Time. Contém dados

versões reservados usados pelo sistema operacional
Windows. Qualquer alteração nessa
configuração pode causar resultados
imprevisíveis. O valor padrão em membros do
domínio é 156.250. O valor padrão em clientes
e servidores autônomos é 156.250.
LocalClockDispersion Todas as Controla a dispersão (em segundos) que você

versões precisa supor quando a única fonte de hora é
o relógio CMOS interno. O valor padrão em
membros do domínio é 10. O valor padrão em
clientes e servidores autônomos é 10.
MaxAllowedPhaseOffset Todas as Especifica a diferença máxima (em segundos)

versões para a qual o W32Time tenta ajustar o relógio
do computador usando a velocidade do clock.
Quando a compensação excede essa taxa, o
W32Time define o relógio do computador
diretamente. O valor padrão para membros do
domínio é 300. O valor padrão para clientes e
servidores autônomos é 1.
MaxClockRate Todas as Mantida pelo W32Time. Contém dados

imprevisíveis. O valor padrão para membros do
domínio é 155.860. O valor padrão para
clientes e servidores autônomos é 155.860.
MaxNegPhaseCorrection Todas as Especifica a maior correção de horário

versões negativo, em segundos, feita pelo serviço. Se o
serviço determinar que uma alteração maior
que essa é necessária, ele registrará um evento
em log.
Observação
O valor 0xFFFFFFFF é um caso especial. Esse

valor significa que o serviço sempre corrigirá a
hora.

0xFFFFFFFF (hexadecimal). O valor padrão para
controladores de domínio é 172.800 (48 horas).
O valor padrão para clientes e servidores
autônomos é 54.000 (15 horas).
MaxPollInterval Todas as Especifica o maior intervalo, em log2

versões segundos, permitido para o intervalo de
sondagem do sistema. Um sistema deve
sondar de acordo com o intervalo agendado,
um provedor pode se recusar a produzir
amostras quando solicitado a fazê-lo. O valor
padrão para controladores de domínio é 10. O
valor padrão para membros do domínio é 15.
autônomos é 15.
MaxPosPhaseCorrection Todas as Especifica a maior correção de horário positivo

versões em segundos feita pelo serviço. Se o serviço
determinar que uma alteração maior que essa
é necessária, ele registrará um evento em log.
Observação
O valor 0xFFFFFFFF é um caso especial. Esse

valor significa que o serviço sempre corrigirá a
hora.

0xFFFFFFFF (hexadecimal). O valor padrão para
controladores de domínio é 172.800 (48 horas).
autônomos é 54.000 (15 horas).
MinClockRate Todas as Mantida pelo W32Time. Contém dados

imprevisíveis. O valor padrão para membros do
domínio é 155.860. O valor padrão para
clientes e servidores autônomos é 155.860.
MinPollInterval Todas as Especifica o menor intervalo, em segundos na

versões base de log 2, permitido para o intervalo de
sondagem do sistema. Um sistema não solicita
amostras com mais frequência do que isso, um
provedor pode produzir amostras em
momentos diferentes do intervalo agendado.
O valor padrão para controladores de domínio
é 6. O valor padrão para membros do domínio
é 10. O valor padrão para clientes e servidores
autônomos é 10.
PhaseCorrectRate Todas as Controla a velocidade na qual o erro de fase é

versões corrigido. A especificação de um valor
pequeno corrige o erro de fase rapidamente,
mas pode causar instabilidade do relógio. Se o
valor for muito grande, levará mais tempo para
corrigir o erro da fase.
O valor padrão em membros do domínio é 1. O
autônomos é 7.
Observação

Registro PhaseCorrectRate. Nos computadores
Windows Server 2003, Windows Server 2003
R2, Windows Server 2008 e Windows Server
2008 R2, se o valor for definido como 0, o
serviço de Horário do Windows o alterará
automaticamente para 1.
PollAdjustFactor Todas as Controla a decisão de aumentar ou diminuir o

versões intervalo de sondagem do sistema. Quanto
maior o valor, menor a quantidade de erros
que faz com que o intervalo de sondagem seja
reduzido. O valor padrão em membros do
domínio é 5. O valor padrão em clientes e
RequireSecureTimeSyncRequests Windows 8 Controla se o controlador de domínio

e versões responderá às solicitações de sincronização de
posteriores hora que usam protocolos de autenticação
mais antigos. Se habilitado (definido como 1), o
controlador de domínio não responderá às
solicitações usando esses protocolos. Trata-se
de uma configuração booliana, e o valor
padrão é 0.
SpikeWatchPeriod Todas as Especifica o tempo pelo qual uma diferença

versões suspeita precisa persistir antes de ser aceita
como correta (em segundos). O valor padrão
em membros do domínio é 900. O valor
padrão em clientes e servidores autônomos e
estações de trabalho é 900.
TimeJumpAuditOffset Todas as Um inteiro sem sinal que indica o limite de

versões auditoria de salto de tempo, em segundos. Se
o serviço de horário ajustar o relógio local
definindo diretamente o relógio e a correção
de horário for maior que esse valor, o serviço
de horário registrará um evento de auditoria
em log.
UpdateInterval Todas as Especifica o número de tiques do relógio entre

versões os ajustes de correção de fase. O valor padrão
para controladores de domínio é 100. O valor
padrão para membros do domínio é 30.000. O
valor padrão para clientes e servidores
autônomos é 360.000.
Observação

Registro UpdateInterval. Em computadores
que executam o Windows Server 2003, o
Windows Server 2003 R2, o Windows Server
2008 e o Windows Server 2008 R2, se o valor
for definido como 0, o Serviço de Hora do
Windows vai alterá-lo automaticamente para 1.
UtilizeSslTimeData Versões do Um valor igual a 1 indica que o W32Time usa

Windows vários carimbos de data/hora SSL para
posteriores propagar um relógio grosseiramente
ao impreciso.
Windows
10 build
1511
Entradas de parâmetros
As entradas de subchave Parameters estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters .
AllowNonstandardModeCombinations Todas Indica que as combinações de modo não

as padrão são permitidas na sincronização
versões entre pares. O valor padrão para membros
do domínio é 1. O valor padrão para clientes
e servidores autônomos é 1.
NtpServer Todas Especifica uma lista de pares delimitada por

as espaço da qual um computador obtém
versões carimbos de data/hora, consistindo em um
ou mais nomes DNS ou endereços IP por
linha. Cada nome DNS ou endereço IP
listado deve ser exclusivo. Os computadores
conectados a um domínio devem sincronizar
com uma fonte de horário mais confiável,
como o horário oficial dos EUA.
0x1 SpecialInterval
0x2 UseAsFallbackOnly
0x4 SymmetricActive: para obter mais
informações sobre esse modo,
consulte Servidor de Horário do
Windows .
Cliente 0x8
Não há valor padrão para essa entrada do

Registro em membros do domínio. O valor
padrão em clientes e servidores autônomos
é time.windows.com,0x1 .
ServiceDll Todas Mantida pelo W32Time. Contém dados

as reservados usados pelo sistema operacional
versões Windows. Qualquer alteração nessa
imprevisíveis. A localização padrão para essa
DLL em membros de domínio e clientes
autônomos e servidores é
%windir%\System32\W32Time.dll.
ServiceMain Todas Mantida pelo W32Time. Contém dados

versões Windows. Qualquer alteração nessa
imprevisíveis. O valor padrão em membros
do domínio é SvchostEntry_W32Time. O
autônomos é SvchostEntry_W32Time.
Tipo Todas Indica de quais pares a sincronização será

as aceita:
versões NoSync. O serviço de horário não é
sincronizado com outras fontes.
NTP. O serviço de horário é
sincronizado dos servidores
especificados no NtpServer. entrada
do Registro.
NT5DS. O serviço de horário
sincroniza da hierarquia de domínio.
AllSync. O serviço de horário usa
todos os mecanismos de
sincronização disponíveis.
O valor padrão em membros do domínio é

NT5DS. O valor padrão em clientes e
servidores autônomos é NTP.
Entradas de NtpClient
As entradas de subchave NtpClient estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
Entrada de registro Versão Descrição

as padrão são permitidas na sincronização entre
versões pares. O valor padrão para membros do
domínio é 1. O valor padrão para clientes e
CompatibilityFlags Todas Especifica os seguintes valores e sinalizadores

as de compatibilidade:
versões 0x00000001: DispersionInvalid
0x00000002:
IgnoreFutureRefTimeStamp
0x80000000: AutodetectWin2K
0x40000000: AutodetectWin2KStage2
O valor padrão para membros de domínio é

0x80000000. O valor padrão para clientes e
servidores autônomos é 0x80000000.
CrossSiteSyncFlags Todas Determina se o serviço escolhe os parceiros

as de sincronização fora do domínio do
versões computador. As opções e os valores são:
0 – Nenhum
1 – PdcOnly
2 – Todos
Esse valor será ignorado se o valor de NT5DS

não estiver definido. O valor padrão para
membros do domínio é 2. O valor padrão
para clientes e servidores autônomos é 2.
DllName Todas Especifica a localização da DLL para o

as provedor de horário.
versões A localização padrão dessa DLL em membros
de domínio e clientes e servidores
autônomos é
%windir%\System32\W32Time.dll.
Habilitada Todas Indica se o provedor NtpClient está

as habilitado no Serviço de Hora atual.
versões 1 – Sim
0 – Não
O valor padrão em membros do domínio é 1.

autônomos é 1.
EventLogFlags Todas Especifica os eventos registrados em log pelo

as Serviço de Hora do Windows.
versões 0x1: alterações de acessibilidade
0x2 - Grande distorção de exemplo
(aplicável somente ao Windows Server
2003, Windows Server 2003 R2,
Windows Server 2008 e Windows
Server 2008 R2)
O valor padrão em membros do domínio é

0x1. O valor padrão em clientes e servidores
autônomos é 0x1.
InputProvider Todas Indica se o NtpClient deve ser habilitado

as como um InputProvider, que obtém
versões informações de hora do NtpServer. O
NtpServer é um servidor de horário que
responde às solicitações de tempo do cliente
na rede retornando exemplos de horário que
são úteis para sincronizar o relógio local.
1 – Sim
0 – Não
O valor padrão para membros do domínio e

clientes autônomos é 1.
LargeSampleSkew Todas Especifica a distorção de amostra grande

as para o log, em segundos. Para estar em
versões conformidade com as especificações da SEC
(Security and Exchange Commission), isso
deve ser definido como três segundos. Os
eventos serão registrados em log para essa
configuração somente quando
EventLogFlags estiver explicitamente
configurado para a distorção de amostra
grande 0x2. O valor padrão em membros do
domínio é 3. O valor padrão em clientes e
ResolvePeerBackOffMaxTimes Todas Especifica o número máximo de vezes a

as dobrar o intervalo de espera quando há
versões tentativas repetidas de localizar um par com
o qual foi feita uma sincronização com falha.
Um valor de zero significa que o intervalo de
espera é sempre o mínimo. O valor padrão
em membros do domínio é 7. O valor padrão
em clientes e servidores autônomos é 7.
ResolvePeerBackoffMinutes Todas Especifica o intervalo inicial de espera, em

as minutos, antes da tentativa de localizar um
versões par com o qual será feita a sincronização. O
valor padrão em membros do domínio é 15.
autônomos é 15.
SpecialPollInterval Todas Especifica o intervalo de sondagem especial,

as em segundos, para os pares manuais.
versões Quando o sinalizador SpecialInterval 0x1
está habilitado, o W32Time usa esse intervalo
de sondagem, em vez de um intervalo de
sondagem determinado pelo sistema
operacional. O valor padrão em membros do
domínio é 3.600. O valor padrão em clientes
e servidores autônomos é 604.800.
Uma novidade do build 1703, o

SpecialPollInterval está contido nos valores
do Registro de configuração MinPollInterval
e MaxPollInterval.
SpecialPollTimeRemaining Todas Mantida pelo W32Time. Contém dados

versões Windows. Ele especifica o tempo, em
segundos, antes que o W32Time seja
ressincronizado após a reinicialização do
computador. Qualquer alteração a essa
imprevisíveis. O valor padrão em membros
do domínio e em clientes e servidores
autônomos é deixado em branco.
Entradas de NtpServer
As entradas de subchave NtpServer estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer .
Entrada do Registro Versões Descrição

as padrão são permitidas na sincronização entre
versões clientes e servidores. O valor padrão para
membros do domínio é 1. O valor padrão
para clientes e servidores autônomos é 1.
DllName Todas Especifica a localização da DLL para o

as provedor de horário. A localização padrão
versões dessa DLL em membros de domínio e clientes
e servidores autônomos é
%windir%\System32\W32Time.dll .
Entrada do Registro Versões Descrição
habilitado Todas Indica se o provedor NtpServer está

as habilitado no Serviço de Hora atual.
versões 1 – Sim
0 – Não
O valor padrão em membros de domínio é 0.

autônomos é 0.
InputProvider Todas Indica se o NtpClient deve ser habilitado

as como um InputProvider, que obtém
versões informações de hora do NtpServer. O
NtpServer é um servidor de horário que
responde às solicitações de tempo do cliente
na rede retornando exemplos de horário que
são úteis para sincronizar o relógio local.
1 – Sim
0 – Não = 0
Valor padrão para membros de domínio e

clientes autônomos: 0
Registro em log aprimorado

As entradas de Registro a seguir não fazem parte da configuração padrão do W32Time,
mas podem ser adicionadas ao Registro para obter funcionalidades aprimoradas de
registro em log. As informações registradas no log de Eventos do Sistema podem ser
modificadas pela alteração dos valores da configuração de EventLogFlags no Editor de
Objeto de Política de Grupo. Por padrão, o serviço de Hora do Windows registra um
evento em log toda vez que ele alterna para uma nova fonte de hora.
Para habilitar o log do W32Time, adicione as seguintes entradas do Registro:
Entrada Versões Descrição
FileLogEntries Todas Controla o número de entradas criadas no arquivo de log de Hora do

as Windows. O valor padrão é nenhum, que não registra nenhuma
versões atividade de Horário do Windows. Os valores válidos são de 0 a 300.
Esse valor não afeta as entradas do log de eventos normalmente
criadas pelo Horário do Windows
Entrada Versões Descrição
FileLogName Todas Controla a localização e o nome do arquivo de log de Hora do

as Windows. O valor padrão é em branco e não deve ser alterado, a
versões menos que FileLogEntries seja alterado. Um valor válido é um
caminho completo e o nome do arquivo que o Horário do Windows
usará para criar o arquivo de log. Esse valor não afeta as entradas do
log de eventos normalmente criadas pelo Horário do Windows.
FileLogSize Todas Controla o comportamento de log circular dos arquivos de log de

as Hora do Windows. Quando FileLogEntries e FileLogName são
versões definidos, definem o tamanho, em bytes, que o arquivo de log pode
alcançar antes de substituir as entradas de log mais antigas por
entradas novas. Use 1000000 ou um valor maior para essa
configuração. Esse valor não afeta as entradas do log de eventos
normalmente criadas pelo Horário do Windows.
Configurações do Objeto de Política de Grupo

As configurações de Política de Grupo estão contidas nos GPOs de Definições de
Configuração Global e Configurações do Windows NTP Client.
Configurações Globais
Essas são as configurações de Política de Grupo globais e os valores padrão do serviço
de Hora do Windows. Essas configurações estão contidas no GPO de Definições de
Configuração Global no Editor de Políticas Local.
Configuração da Política de Grupo Valor padrão
AnnounceFlags 10
EventLogFlags 2
FrequencyCorrectRate 4
HoldPeriod 5
LargePhaseOffset 1.280.000
LocalClockDispersion 10
MaxAllowedPhaseOffset 300
MaxNegPhaseCorrection 54.000 (15 horas)
MaxPollInterval 15
Configuração da Política de Grupo Valor padrão
MaxPosPhaseCorrection 54.000 (15 horas)
MinPollInterval 10
PhaseCorrectRate 7
PollAdjustFactor 5
SpikeWatchPeriod 90
UpdateInterval 100
Configurações do Windows NTP Client

Essas são as configurações do Windows NTP Client e os valores padrão do serviço de
Hora do Windows. Essas configurações estão contidas no GPO Configurar o Windows
NTP Client no Editor de Política de Grupo Local.
Configuração da Política de Valor padrão

Grupo
NtpServer time.windows.com , 0x1
Type NT5DS - Usado para computadores ingressados no

domínio
NTP – Usado para computadores não ingressados no

domínio
CrossSiteSyncFlags 2
ResolvePeerBackoffMinutes 15
ResolvePeerBackoffMaxTimes 7
SpecialPollInterval 3.600
EventLogFlags 0
７ Observação
Se você usar Política de Grupo para definir o valor NtpServer como parte da
política Configurar Cliente NTP do Windows e aplicá-lo a um membro de domínio,
o Serviço de Horário do Windows não usará o valor NtpServer Registry. Para exibir
a configuração do NTP, abra um Prompt de Comando e execute w32tm /query
/configuration .
Informações relacionadas
Confira RFC 1305 – Protocolo NTP da IETF (Internet Engineering Task Force).
Configurar opções de protocolo seguro
para WinHTTP
Windows 10 Windows 11
Este guia de instruções mostra como usar a entrada do DefaultSecureProtocols

Registro para escolher quais protocolos para os Serviços HTTP do Windows (WinHTTP).
A DefaultSecureProtocols entrada do Registro permite especificar quais protocolos SSL

devem ser usados quando o WINHTTP_OPTION_SECURE_PROTOCOLS sinalizador é usado. A
configuração permite que os aplicativos criados usem o sinalizador padrão WinHTTP
para poderem usar os protocolos TLS mais recentes ou impedir o SSL mais antigo
nativamente, sem a necessidade de atualizações para o aplicativo.
Pré-requisitos
Calcule o valor de DefaultSecureProtocols com
WINHTTP_OPTION_SECURE_PROTOCOLS.
Confirme se sua conta tem direitos administrativos para o sistema.
Verifique se o PowerShell está instalado.
Configurar DefaultSecureProtocols
Para adicionar e definir a entrada do Registro DefaultSecureProtocols:
x86
1. Abra um prompt do PowerShell elevado.
2. Para criar e definir a chave do DefaultSecureProtocols Registro, execute o

comando a seguir (substitua {value} pelo DefaultSecureProtocols valor
selecionado no Valor calculado).
PowerShell
Get-Item -Path
"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet
Settings\WinHttp" | New-ItemProperty -Name "DefaultSecureProtocols"
-Value "{value}"
3. Reinicialize o computador ou reinicie os serviços que estiverem usando

WinHTTP.
Próximas etapas
Para configurar a entrada do DefaultSecureProtocols Registro para vários
computadores, consulte Configurar um item de serviço.

Documentação de Rede

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Documentação de Rede

Enviado por

Direitos autorais:

Formatos disponíveis

Dê a sua opinião sobre a experiência de download do PDF.

Cenários de rede com suporte do Windows Server

Bibliotecas do Windows Server

Conteúdo desativado do Windows Server 2003/2003 R2

Rede definida pelo software

Rede definida pelo software (SDN)

Balanceamento de carga do software (SLB) para SDN

Gateway de RAS para SDN

Virtualização de função de rede

Visão geral do firewall do datacenter

Implantar uma infraestrutura SDN usando scripts

Guia da Rede Principal

Sistema de nome de domínio (DNS)

Virtualização de Rede Hyper-V

Comutador Virtual Hyper-V

IPAM (Gerenciamento de Endereços IP)

NLB (Balanceamento de Carga de Rede)

Servidor de Políticas de Rede

Shell de Rede (Netsh)

Ajuste do desempenho de subsistemas de rede

Política de QoS (qualidade de serviço)

Serviço de Cadastramento na Internet do Windows (WINS)

Rede de contêineres do Windows

VPN (rede virtual privada)

Proxy de aplicativo Web no Windows Server 2016

Guia de implantação de acesso remoto com a VPN Always On

Rede de Alto Desempenho

Rede de Alto Desempenho

Para todos os cenários de produção, use os drivers de hardware assinados mais

Cenários de rede com suporte

Cenários de SDN (Rede Definida pelo Software)

Cenários de plataforma de rede

Cenários do servidor DNS

IPAM cenários com DHCP e DNS

Cenários de NIC Teaming

Cenários set (switch embedded teaming)

Cenários de SDN (Rede Definida pelo Software)

Implantar uma infraestrutura de rede definida pelo software usando scripts

Cenários do Controlador de Rede

Implante e gerencie uma instância de vários nós do Controlador de Rede. Para

Use o Controlador de Rede para definir programaticamente a política de rede

Para obter mais informações, consulte Controlador de Rede.

Cenários de NFV (Virtualização de Função de Rede)

Os cenários de NFV permitem que você:

Implante e use um balanceador de carga de software para distribuir o tráfego de

Implante e use um balanceador de carga de software para distribuir o tráfego de

Implante e use um balanceador de carga de software NAT para redes virtuais

Implantar e usar um gateway de encaminhamento de Camada 3

Implante e use um gateway GRE (Encapsulamento de Roteamento Genérico).

Implante e configure o roteamento dinâmico e o roteamento de trânsito entre

Configure a redundância M+N para a Camada 3 e gateways site a site e para

Para obter mais informações, consulte Network Function Virtualization.

Cenários de plataforma de rede

Os cenários de plataforma de rede permitem que você:

Crie um caminho de dados de baixa latência usando o Packet Direct, habilitado no

Cenários de com switch virtual do Hyper-V

Os cenários do Com switch virtual do Hyper-V permitem que você:

Criar um comutamento virtual do Hyper-V com uma vNIC de RDMA (Acesso

Criar um comutamento virtual hyper-V com set (comutamento inserido) e vNICs

Criar uma equipe SET no Com switch virtual do Hyper-V

Gerenciar uma equipe SET usando Windows PowerShell comandos

Cenários do servidor DNS

Especificar o Geo-Location de tráfego baseado em dados usando políticas DNS