Contents

Documentação de rede
Cenários de rede com suporte do Windows Server
Novidades na rede
Diretrizes de rede principal para o Windows Server
Componentes da rede principal
Diretrizes complementares de rede principal
Implantar certificados de servidor para implantações com e sem fio do 802.1X
Visão geral da implantação de certificado do servidor
Planejamento da implantação de certificado do servidor
Implantação de certificados do servidor
Instalar o servidor Web WEB1
Criar um registro de alias (CNAME) em DNS para WEB1
Configurar WEB1 para distribuir CRLs (listas de certificados revogados)
Preparar o arquivo CAPolicy.inf
Instalar a autoridade de certificação
Configurar as extensões CPD e AIA em 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 registro de servidor de um certificado do servidor
Implantar acesso sem fio autenticado 802.1X baseado em senha
Visão geral da implantação de acesso sem fio
Processo da implantação de acesso sem fio
Planejamento da implantação de acesso sem fio
Implantação de acesso sem fio
Implantar o modo de cache hospedado do BranchCache
Visão geral da implantação do modo de cache hospedado do BranchCache
 Planejamento da implantação do modo de cache hospedado do BranchCache
Implantação do 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 redimensionar o cache hospedado (opcional)
Realizar hash prévio e pré-carregar conteúdo no servidor de cache hospedado
(opcional)
Configurar descoberta automática de cache hospedado cliente por ponto de
conexão de serviço
Recursos adicionais
BranchCache
Netsh BranchCache e comandos do Windows PowerShell
Guia de implantação do BranchCache
Escolher um design para o BranchCache
Implantar o BranchCache
Instalar e configurar servidores de conteúdo
Instalar servidores de conteúdo que usam o recurso BranchCache
Instalar servidores de conteúdo dos Serviços de Arquivo
Implantar servidores de cache hospedado (opcional)
Realizar o hash prévio e o pré-carregamento de conteúdo em servidores de
cache hospedado (opcionais)
Configurar BranchCache em computadores cliente
Usar política de grupo para configurar computadores cliente do membro do
domínio
Usar o Windows PowerShell para configurar computadores cliente do membro
que não sejam de domínio
Verificar configurações do computador cliente
DirectAccess
Sistema de nome de domínio (DNS)
Novidades no cliente DNS no Windows Server
Novidades no servidor DNS no Windows Server
Cliente DNS seguro via HTTPS (DoH)
DNS Anycast
Diretrizes de cenário de política DNS
 Visão geral das políticas de DNS
Usar a política DNS para gerenciamento de tráfego de localização geográfica com
servidores primários
Usar a política DNS para gerenciamento de tráfego de localização geográfica com
implantações primárias e secundárias
Usar a política DNS para respostas DNS inteligentes com base na hora do dia
Respostas de DNS com base na hora do dia com o Servidor de aplicativos da
nuvem do Azure
Usar a política DNS para a implantação de DNS com partição de rede
Usar a política DNS para a DNS com partição de rede no Active Directory
Usar a política DNS para a aplicação de filtros em consultas DNS
Usar a política DNS para balanceamento de carga do aplicativo
Usar a política DNS para balanceamento de carga de aplicativo com
reconhecimento de localização geográfica
Solução de problemas de DNS
Solução de problemas de clientes DNS
Desabilitar o cache do DNS do lado do cliente em clientes DNS
Solução de problemas de servidores DNS
Protocolo DHCP
Novidades no DHCP
Opções de seleção de sub-rede DHCP
Eventos de registro em log de DHCP para registros de DNS
Implantar o DHCP usando o Windows PowerShell
Solucionar problemas do DHCP
Noções básicas do DHCP (protocolo DHCP)
Diretrizes gerais para solucionar problemas do DHCP
Como usar o endereçamento TCP/IP automático sem um servidor DHCP
Solucionar problemas no cliente DHCP
Solucionar problemas no servidor DHCP
Protocolo EAP (Extensible Authentication Protocol)
HPN (rede de alto desempenho)
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
Insider Preview
RSC (União de Segmentos de Recebimento) no vSwitch
Diretrizes de configuração de NIC convergida
Configuração do adaptador de rede único
Configuração de adaptador de rede do datacenter
Configuração do comutador físico
Solução de problemas de NIC convergente
DCB (Data Center Bridging)
Instalar DCB
Gerenciar DCB
vRSS (Virtual Receive Side Scaling)
Planejar o uso de vRSS
Habilitar vRSS em um adaptador de rede virtual
Gerenciar vRSS
Perguntas frequentes sobre vRSS
Comandos do Windows PowerShell para RSS e vRSS
Resolver problemas de vRSS
API de serviço de HCN (rede de computação de host)
Cenários comuns de HCN
Identificadores de contexto de RPC para HCN
Esquemas de documento JSON de HCN
Exemplo de código gerado por C#
Exemplo de código gerado por Go
Comutador Virtual do Hyper-V
IPAM (Gerenciamento de Endereço IP)
Novidades no IPAM
Gerenciar IPAM
Gerenciamento de registro de recursos de DNS
Adicionar um registro de recursos de DNS
 Excluir registros de recursos de DNS
Filtrar a exibição de registros de recursos de DNS
Exibir registros de recurso de DNS para um endereço IP específico
Gerenciamento de zonas DNS
Criar uma zona DNS
Editar uma zona DNS
Exibir registros de recurso de DNS para uma zona DNS
Exibir zonas DNS
Gerenciar recursos em várias florestas do Active Directory
Limpar dados de utilização
Controle de acesso baseado em função
Gerenciar controle de acesso baseado em função com o Gerenciador do
Servidor
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 recurso DNS
Exibir funções e permissões de função
Gerenciar controle de acesso baseado em função com o Windows PowerShell
Balanceamento de Carga de Rede
NPS (Servidor de Políticas de Rede)
Melhores práticas do NPS
Introdução ao NPS
Processamento de solicitações de conexão
Políticas de solicitação de conexão
Nomes de realm
Grupos de servidores RADIUS remotos
Políticas de rede
Permissão de acesso
Modelos NPS
Clientes RADIUS
Planejar o NPS
Planejar NPS como um servidor RADIUS
 Planejar NPS como um proxy RADIUS
Implantar o NPS
Gerenciar NPS
Gerenciamento de Servidor de Políticas de Rede com Ferramentas de
Administração
Configurar políticas de solicitação de conexão
Configurar firewalls para tráfego RADIUS
Configurar políticas de rede
Configurar a contabilização do NPS
Configurar clientes RADIUS
Configurar grupos de servidores RADIUS remotos
Gerenciar certificados usados com NPS
Configurar modelos de certificado para requisitos de PEAP e EAP
Gerenciar NPSs
Configurar o NPS em um computador multihomed
Configurar informações da porta UDP do NPS
Desabilitar o encaminhamento de notificações do NAS
Exportar uma configuração do NPS para importar em outro servidor
Aumentar autenticações simultâneas processadas pelo NPS
Instalar o 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
Use expressões regulares no NPS
Verificar configuração depois das alterações do NPS
Coleta de dados do NPS
Gerenciar modelos do NPS
Shell de Rede (Netsh)
Sintaxe, contextos e formatação do comando netsh
Arquivo de lote de exemplo de Shell (Netsh) de rede
Comandos Netsh http
Comandos netsh interface portproxy
Comandos netsh mbn
Ajuste de desempenho do subsistema de rede
Como escolher 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
Agrupamento NIC
Gerenciamento e uso do endereço MAC de agrupamento NIC
Criar um agrupamento NIC em uma VM ou computador host
Como solucionar problemas de agrupamento NIC
Monitor de pacote (Pktmon)
Sintaxe e formatação do comando do Pktmon
Extensão de monitoramento de pacotes no Windows Admin Center
Extensão de diagnóstico de caminho de dados SDN no Windows Admin Center
Suporte do Monitor de Rede da Microsoft (Netmon)
Suporte do Wireshark (formato pcapng)
Política de QoS (qualidade de serviço)
Introdução à política de QoS
Como funciona a política de QoS
Arquitetura de política de QoS
Cenários de política de QoS
Gerenciar a política de QoS
Erros e eventos de política de QoS
Perguntas frequentes sobre a política de QoS
SDN (rede definida pelo software)
Visão geral da SDN no Windows Server
Tecnologias da SDN
Virtualização de rede Hyper-V
Visão geral da virtualização de rede Hyper-V
Detalhes técnicos da virtualização de rede Hyper-V
Novidades na virtualização de rede Hyper-V
iDNS (serviço DNS interno) para SDN
 Controlador de rede
Alta disponibilidade do controlador de rede
Instalar a função de servidor do Controlador de Rede usando o Gerenciador do
Servidor
Etapas de pós-implantação para controlador de rede
Virtualização de função de rede
Visão geral do firewall do datacenter
Gateway de RAS para SDN
Arquitetura de implantação do Gateway de RAS
Alta disponibilidade do Gateway de RAS
SLB (balanceamento de carga do software) para SDN
SET (Agrupamento Incorporado de Comutador) para SDN
Rede de contêiner
Planejar SDN
Requisitos para instalação e preparação para implantação do controlador de rede
Implantar SDN
Implantar uma infraestrutura SDN
Implantar uma infraestrutura SDN usando scripts
Implantar tecnologias SDN usando o Windows PowerShell
Implantar controlador de rede usando o Windows PowerShell
Gerenciar SDN
Gerenciar redes virtuais de locatário
Noções básicas sobre o uso de redes virtuais e VLANs
Usar ACLs (listas de controle de acesso) para gerenciar o fluxo de tráfego de
rede do datacenter
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
Configurar a criptografia para uma sub-rede virtual
Medição de saída em uma rede virtual
Gerenciar cargas de trabalho de locatário
Criar uma VM e conectar-se a uma rede virtual de locatário ou VLAN
Configurar a QoS para um adaptador de rede de VMs do locatário
 Configurar ACLs de firewall do datacenter
Configurar o balanceador de carga de software para balanceamento de carga e
NAT (conversão de endereços de rede)
Usar solução de virtualização de rede em uma rede virtual
Clustering convidado em uma rede virtual
Atualizar, fazer backup e restaurar uma infraestrutura SDN
Segurança para SDN
Proteger o controlador de rede
Gerenciar certificados para SDN
Kerberos com SPN (nome da entidade de serviço)
Auditoria de firewall SDN
Emparelhamento de rede virtual
Configurar o emparelhamento de rede virtual
Desempenho de gateway do Windows Server 2019
Alocação de largura de banda de gateway
Solucionar problemas de SDN
Solucionar problemas de pilha de rede definida pelo software do Windows Server
Tecnologias do System Center para SDN
Microsoft Azure e SDN
Contatar a equipe de rede na nuvem e datacenter
VPN (rede virtual privada)
WINS (Serviço de Cadastramento na Internet do Windows)
Serviço de Tempo do Windows
Insider Preview – Serviço de Data/Hora do Windows no Windows Server 2019
Hora precisa do Windows Server 2016
Limite de suporte para hora de alta precisão
Como configurar sistemas de alta precisão
Horário do Windows para rastreamento
Referência técnica do serviço de data/hora do Windows
Como o Serviço de data/hora do Windows Funciona
Ferramentas e configurações do Serviço de data/hora do Windows
 Cenários de rede com suporte do Windows Server
13/08/2021 • 5 minutes to read

aplica-se a: Windows server 2022, Windows server 2019, Windows ( canal semestral do servidor ) Windows
Server 2016

Este tópico fornece informações sobre os cenários com e sem suporte que você pode ou não executar com esta
versão do Windows Server 2016.

IMPORTANT
Para todos os cenários de produção, use os drivers de hardware mais recentes assinados do OEM do fabricante do
equipamento original ( ) ou do IHV do fornecedor de hardware independente ( ) .

Cenários de rede com suporte

esta seção inclui informações sobre os cenários de rede com suporte para o Windows Server 2016 e inclui as
categorias de cenário a seguir.
Cenários de rede definida pelo software (SDN)
Cenários de plataforma de rede
Cenários de servidor DNS
cenários de IPAM com DHCP e DNS
Cenários de agrupamento NIC
Alternar cenários de conjunto de agrupamentos inseridos ( )
Cenários de rede definida pelo software (SDN )
Você pode usar a seguinte documentação 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 rede definida pelo Software (SDN).
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 implantar o controlador de rede usando Windows PowerShell.
Use o controlador de rede para definir de forma programática a política de rede usando a API REST do
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 Northbound e
Southbound.
Implante e use um balanceador de carga de software para distribuir o tráfego Eastbound e Westbound
para redes virtuais criadas com virtualização de rede Hyper-V.
Implante e use um balanceador de carga de software NAT para redes virtuais criadas com 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 de IPsec site a site (IKEv2)
Implante e use um gateway de túnel de roteamento genérico (GRE).
Implante e configure o roteamento de tráfego dinâmico e de trânsito entre sites usando Border Gateway
Protocol (BGP).
Configure a redundância M + N para os gateways de camada 3 e site a site e para roteamento BGP.
Use o controlador de rede para especificar ACLs em redes virtuais e interfaces de rede.
Para obter mais informações, consulte virtualização de função de rede.
Cenários de plataforma de rede
para os cenários nesta seção, a equipe de rede do Windows Server dá suporte ao uso de qualquer driver
certificado Windows Server 2016. Verifique com seu ( fabricante NIC da placa de interface de rede ) 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 pacote direto, habilitado no comutador virtual do
Hyper-V e um único adaptador de rede.
Configure SET para distribuir SMB direto e o tráfego RDMA flui entre até dois adaptadores de rede.
Para obter mais informações, consulte acesso remoto direto à memória (RDMA) e Comutador incorporado
(definir).
Cenários de comutador virtual do Hyper-V
Os cenários do comutador virtual do Hyper-V permitem:
Criar um comutador virtual do Hyper-V com um vNIC de acesso de memória direta remota (RDMA)
Criar um comutador virtual do Hyper-V com o switch Embedded Integration (SET) e o RDMA vNICs
Criar uma equipe de conjunto no comutador virtual do Hyper-V
gerenciar uma equipe de conjunto usando comandos Windows PowerShell
Para obter mais informações, consulte acesso remoto direto à memória (RDMA) e switch Embedded teaming
(SET)
Cenários de servidor DNS
Os cenários de servidor DNS permitem que você:
Especificar o gerenciamento de tráfego baseado em Geo-Location usando políticas de DNS
Configurar o DNS de divisão-Brain usando políticas de DNS
 Aplicar filtros em consultas DNS usando políticas de DNS
Configurar o balanceamento de carga de aplicativo usando políticas DNS
Especificar respostas de DNS inteligentes com base na hora do dia
Configurar políticas de transferência de zona DNS
Configurar políticas de servidor DNS em zonas integradas do Active Directory Domain Services (AD DS)
Configurar limitação da taxa de resposta
Especificar a autenticação baseada em DNS de entidades nomeadas (SUNDANÊS)
Configurar o suporte para registros desconhecidos no DNS
para obter mais informações, consulte os tópicos novidades no cliente dns no Windows Server 2016 e o que há
de novo no servidor dns em Windows Server 2016.
cenários de IPAM com DHCP e DNS
os cenários de IPAM permitem:
Descobrir e administrar servidores DNS e DHCP e endereçamento IP em várias florestas de Active
Directory federada
Use IPAM para o gerenciamento centralizado de propriedades de DNS, incluindo zonas e registros de
recursos.
defina políticas de controle de acesso baseado em função granulares e delegue 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 para automatizar a configuração do controle de acesso
para DHCP e DNS.
Para obter mais informações, consulte gerenciar IPAM.
Cenários de agrupamento NIC
Os cenários de agrupamento NIC permitem:
Criar uma equipe NIC em uma configuração com suporte
Excluir uma equipe NIC
Adicionar adaptadores de rede à equipe NIC em uma configuração com suporte
Remover adaptadores de rede da equipe NIC

NOTE
no Windows Server 2016, você pode usar o agrupamento NIC no Hyper-V, no entanto, em alguns casos, as filas de
máquina Virtual (VMQ) 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 esteja habilitada nos adaptadores membros da equipe NIC:
Set-NetAdapterVmq -Name <NetworkAdapterName> -Enable

Para obter mais informações, consulte agrupamento NIC.

Alternar cenários de conjunto de agrupamentos inseridos ( )
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 mais informações, consulte RDMA (acesso remoto direto à memória) e o comutador inserido de
equipe (Set)

Cenários de rede sem suporte

Os cenários de rede a seguir não têm suporte no Windows Server 2016.
Redes virtuais de locatário baseadas em VLAN.
Não há suporte para IPv6 na underlay nem na sobreposição.
 Novidades na rede
13/08/2021 • 9 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

A seguir estão as tecnologias de rede novas ou aprimoradas Windows Server 2016. Upd Este tópico contém as
seções a seguir.
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 (Software Defined Datacenter) e o Windows Server 2016
fornece tecnologias novas e aprimoradas de SDN (Rede Definida pelo Software) para ajudá-lo a passar para
uma solução SDDC totalmente realizada para sua organização.
Ao gerenciar redes como um recurso definido pelo software, você pode descrever os requisitos de
infraestrutura de um aplicativo uma vez e, em seguida, escolher onde o aplicativo é executado – localmente ou
na nuvem. Essa consistência significa que seus aplicativos agora são mais fáceis de dimensionar e você pode
executar aplicativos perfeitamente, em qualquer lugar, com a mesma confiança 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
A seguir estão as tecnologias de infraestrutura SDN novas ou aprimoradas.
Controlador de rede . Novo 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 virtual e física 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 pelo software usando scripts.
Comu switch vir tual do Hyper-V. O Com switch virtual do Hyper-V é executado em hosts Hyper-V e
permite que você crie com alternamento e roteamento distribuídos e uma camada de imposição de
política alinhada e compatível com Microsoft Azure. Para saber mais, consulte Comutador Virtual do
Hyper-V.
Network Function Vir tualization (NFV) . 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 sendo implantadas como
soluções de virtualização. 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 tecnologias NFV a seguir estão disponíveis
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 ras . Você pode usar o Gateway ras para rotear o 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 VPNs (redes virtuais privadas) da IKEv2 (Chave
de Internet Exchange versão 2), VPN de Camada 3 (L3) e GRE (Encapsulamento de Roteamento
Genérico). Além disso, pools de gateway e redundância M+N de gateways agora têm suporte; E
Border Gateway Protocol (BGP) com recursos de Refletor de Rota fornece 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 Novidades no Gateway ras e gateway RAS para SDN.
SLB (software Load Balancer) e NAT (Conversão de Endereços de Rede). O balanceador
de carga da camada norte-sul e leste-oeste da camada 4 e NAT aprimoram a taxa de transferência
dando suporte ao Retorno do Servidor Direto, com o qual o tráfego de rede de retorno pode
ignorar o multiplexador de balanceamento de carga. Para obter mais informações, consulte
Software Load Balancing (SLB) para SDN.
Para obter mais informações, consulte Network Function Virtualization.
Protocolos padronizados. O Controlador de Rede Transferência de Estado Representacional (REST) em
sua interface de northbound com cargas JSON (JavaScript Object Notation). A interface de southbound
do Controlador de Rede usa o OVSDB (Open vSwitch Database Management Protocol).
Tecnologias de encapsulamento flexíveis . Essas tecnologias operam no plano de dados e suportam
VxLAN (Virtual Extensible LAN) e NVGRE (Encapsulamento de Roteamento Genérico de Virtualização de
Rede). Para obter mais informações, consulte Túnel GRE no Windows Server 2016.
Para obter mais informações sobre o SDN, consulte Rede definida pelo software (SDN).
Conceitos básicos de escala de nuvem
Os conceitos básicos de escala de nuvem a seguir 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 Packet Direct fornece uma alta taxa de transferência de tráfego de rede e infraestrutura
de processamento de pacotes de baixa latência.
Switch Embedded Teaming (SET) . SET é uma solução de NIC Teaming integrada ao Com switch virtual
do Hyper-V. SET permite o uso de até oito NICS físicos em uma única equipe SET, o que melhora a
disponibilidade e fornece failover. No Windows Server 2016, você pode criar equipes SET restritas ao uso
do SMB (Server Message Block) e RDMA. Além disso, você pode usar as equipes SET para distribuir o
tráfego de rede para a Virtualização de Rede Hyper-V. Para obter mais informações, consulte Remote
Direct Memory Access (RDMA) e Switch Embedded Teaming (SET).

Novos recursos para tecnologias de rede adicionais

Esta seção contém informações sobre 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 Novidades no 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.
A seguir estão as informações sobre o cliente DNS e o servidor DNS.
Cliente DNS
A seguir estão as tecnologias de cliente DNS novas ou aprimoradas.
Associação de ser viço cliente DNS . No Windows 10, o serviço cliente DNS oferece suporte aprimorado
para computadores com mais de um interface de rede.
Para obter mais informações, consulte Novidades no cliente DNS no Windows Server 2016
Servidor DNS
A seguir estão as tecnologias de servidor DNS novas ou aprimoradas.
Políticas DNS . Você pode configurar políticas DNS para especificar como um servidor DNS responde às
consultas DNS. As respostas DNS podem ser baseadas no endereço IP do cliente (local), hora do dia e
vários outros parâmetros. As políticas dns permitem DNS com base em localização, gerenciamento de
tráfego, balanceamento de carga, DNS com dupla cabeça e outros cenários.
Supor te do Nano Ser ver para DNS baseado em arquivo. Você pode implantar o servidor DNS
Windows Server 2016 em uma imagem do Nano Server. Essa opção de implantação estará disponível
para você se você estiver usando o 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 a adoção de patch minimizada.

NOTE
Não há suporte para DNS integrado do Active Directory no Nano Server.

RRL (Limitação da Taxa de Resposta). 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 usando 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 (DNS) . Você pode usar registros TLSA
(Autenticação de Segurança de Camada de Transporte) para fornecer informações aos clientes DNS que
informam de qual AC (autoridade de certificação) 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 AC diferente.
Supor te a registros desconhecidos. Você pode adicionar registros que não são explicitamente
suportados pelo servidor DNS Windows usando a funcionalidade de registro desconhecido.
Dicas raiz IPv6 . Você pode usar o suporte nativo de dicas raiz IPV6 para executar a resolução de nomes
da Internet usando os servidores raiz IPV6.
Supor te Windows PowerShell aprimorado. Novos Windows PowerShell cmdlets estão disponíveis
 para o Servidor DNS.
Para obter mais informações, consulte Novidades no servidor DNS no Windows Server 2016

Túnel GRE
O Gateway ras agora dá suporte a túneis GRE (Encapsulamento de Roteamento Genérico) de alta
disponibilidade para conexões site a site e 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 no Windows Server 2016.

Virtualização de Rede Hyper-V

Introduzida no Windows Server 2012, a HNV (Virtualização de Rede Hyper-V) 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, a HNV oferece 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 Microsoft Azure nuvem pública.
Para obter mais informações, consulte Novidades na Virtualização de Rede Hyper-V no Windows Server 2016

IPAM
IPAM fornece recursos administrativos e de monitoramento altamente personalizáveis para o endereço IP e a
infraestrutura DNS em uma rede da organização. Usando IPAM, você pode monitorar, auditar e gerenciar
servidores que executam o protocolo DHCP e o DNS (Sistema de Nomes de Domínio).
Gerenciamento de endereço IP aprimorado. IPAM recursos são aprimorados para cenários como
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ços IP.
Gerenciamento de ser viço DNS aprimorado. IPAM dá suporte ao registro de recursos DNS,
encaminhador condicional e gerenciamento de zona DNS para servidores DNS integrados ao Active
Directory e com suporte a arquivos ingressados no domínio.
Gerenciamento integrado de DNS, DHCP e endereço IP (DDI). Várias novas experiências e
operações integradas de gerenciamento do ciclo de vida estão habilitadas, como 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.
Supor te a várias florestas do Active Director y . 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 de duas
vias entre a floresta em que o IPAM está instalado e cada uma das florestas remotas.
Windows PowerShell supor te para Controle de Acesso Baseado em Função . Você pode usar
Windows PowerShell para definir escopos de acesso em IPAM objetos.
Para obter mais informações, consulte Novidades no IPAM e Gerenciar IPAM.
 Diretrizes de rede principal para o Windows Server
12/08/2021 • 3 minutes to read

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 é um software de protocolo de rede fornecido com os sistemas operacionais
microsoft Windows que implementa e dá suporte ® ® ao conjunto 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 Core Network Guide 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
13/08/2021 • 80 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 de Active Directory em uma nova floresta.

NOTE
este guia está disponível para download no formato Microsoft Word da galeria do TechNet. Para obter mais informações,
consulte Guia de rede de núcleo para Windows Server 2016.

Este guia contém as seções a seguir.

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. o TCP/IP é um software de protocolo de rede fornecido com os sistemas operacionais
Microsoft Windows que implementam e dão 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 pelo 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
 NOTE
os computadores que executam Windows sistemas operacionais cliente 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
o 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 Server 2008 R2
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 a 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.
 NOTE
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.
Ro t eado r

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 um comutador, ele 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.
C o n fi g u r a ç õ e s T C P / I P e st á t i c a s

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.
C a t á l o g o g l o b a l d o s Se r v i ç o s d e D o m í n i o A c t i v e D i r e c t o r y e se r v i d o r D N S D C 1

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.
Se r v i d o r D H C P D H C P 1

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.
Co m pu t ado r es c l i en t e

Os computadores Windows sistemas operacionais cliente 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.

NOTE
Para saber mais sobre como planejar sua implantação, confira também o Apêndice E – Folha 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 de 10.0.0.1 a 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.

IMPORTANT
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.

IMPORTANT
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 o número de local da função do servidor de convenção - de - nomenanal:
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.

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO

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

NOTE
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 estão executando Windows Server 2008 e versões posteriores do sistema operacional Windows
Server.
Windows Server 2008 R2 . Esse nível funcional de floresta dá suporte Windows 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 Windows Server 2012 controladores
de domínio e controladores de domínio que executam versões posteriores do sistema operacional
Windows Server.
Windows Server 2012 R2. Esse nível funcional de floresta dá suporte Windows Server 2012
controladores de domínio 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 Windows Server 2016 controladores
de domínio 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
executarem o Windows Server 2016, é recomendável configurar o AD DS com o nível funcional da floresta
Windows Server 2016 durante AD DS instalação.

IMPORTANT
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ê aumentar 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.

IT EN S DE C O N F IGURA Ç Ã O : VA LO RES DE EXEM P LO :

Nome DNS completo Exemplos:

- corp.contoso.com
- example.com

Nível funcional da floresta - Windows Server 2008

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

Local da pasta do Banco de Dados dos Serviços de Domínio E:\Configuration\

Active Directory Ou aceite o local padrão.
 IT EN S DE C O N F IGURA Ç Ã O : VA LO RES DE EXEM P LO :

Local da pasta dos arquivos de Log dos Serviços de Domínio E:\Configuration\

Active Directory Ou aceite o local padrão.

Local da pasta do SYSVOL dos Serviços de Domínio Active E:\Configuration\

Directory Ou aceite o local padrão.

Senha do Administrador do Modo de Restauração de J * p2leO4$F

Diretório

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:

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO

Tipo de zona Zona primária e Armazenar a zona no Active

Director y estão selecionados

Escopo de Replicação de Zona do Active Directory Para todos os ser vidores DNS neste domínio

Página do assistente de Nome da Primeira Zona de Pesquisa Zona de pesquisa inversa do IPv4
Inversa

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

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.
 NOTE
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.

C L A SSE DE EN DEREÇ O B IT S PA RA M Á SC A RA DE SUB - REDE M Á SC A RA DE SUB - REDE

Classe A 11111111 00000000 00000000 255.0.0.0

00000000

Classe B 11111111 11111111 00000000 255.255.0.0

00000000

Classe C 11111111 11111111 11111111 255.255.255.0

00000000

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.

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO

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.

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO

Ligações de Conexão de Rede Ethernet

 IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO

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. Endereço IP inicial 3. 10.0.0.254
3. Finalizando o endereço IP 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

NOTE
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.
Renomear o computador
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.

NOTE
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

P a ra re n o me a r c o mp u t a d o re s q u e e x e c u t a m W i n d o w s Se rv e r 2016, W i n d o w s Se rv e r 2012 R 2 e W i n d o w s Se rv e r 2012

1. No Gerenciador do Servidor, clique em Ser vidor 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 .

NOTE
Para obter informações sobre como renomear computadores que estão executando outros sistemas operacionais da
Microsoft, consulte Apêndice A – Renomeando computadores.

Configurar um endereço IP estático

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

NOTE
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 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

P a ra c o n f i g u ra r u m e n d e re ç o I P e s t á t i c o e m c o mp u t a d o re s q u e e x e c u t a m W i n d o w s Se rv e r 2016, W i n d o w s Se rv e r 2012 R 2 e W i n d o w s Se rv e r 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 Compar tilhamento .
2. No Central de Rede e Compar tilhamento , clique em Alterar 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.

NOTE
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 Ser vidor 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 Ser vidor 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 OK e então clique em Fechar .

NOTE
Para obter informações sobre como configurar um endereço IP estático em computadores que executam 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
para 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 AD DS e DNS usando Gerenciador do Servidor.

IMPORTANT
Depois de concluir a execução das etapas neste procedimento, o computador será reiniciado automaticamente.

Instalar AD DS e DNS usando Windows PowerShell

Você pode usar os comandos a seguir para instalar e configurar AD DS e DNS. Você deve substituir o nome de
domínio neste exemplo pelo valor que deseja usar para seu domínio.

NOTE
Para obter mais informações sobre esses 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 administrador, digite o seguinte comando e pressione ENTER:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools`

Quando a instalação for concluída com êxito, a mensagem a seguir será exibida Windows PowerShell.
 REIN IC IA L IZ A Ç Ã O
ÊXITO N EC ESSÁ RIA C Ó DIGO DE SA ÍDA RESULTA DO DO REC URSO

True Não Êxito {Active Directory Domain

Services, Grupo P...

No Windows PowerShell, digite o seguinte comando, substituindo o texto corp.contoso.com pelo nome de
domínio e pressione ENTER:

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 quiser, você poderá ler as mensagens de aviso exibidas durante a instalação normal e bem-sucedida
do AD DS DNS. Essas mensagens são normais e não são uma indicação de falha de instalação.
Após a instalação ser bem-sucedida, será exibida uma mensagem informando que você está prestes a ser
desconectado do computador para que o computador possa ser reiniciado. 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 padrão.
Depois que o servidor for reiniciado, você poderá verificar a instalação bem-sucedida Active Directory
Domain Services e DNS. Abra Windows PowerShell, digite o comando a seguir e pressione ENTER.

Get-WindowsFeature

Os resultados desse comando são exibidos 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 AD DS e DNS usando Gerenciador do Ser vidor
1. No DC1, no Gerenciador do Ser vidor , 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 .

NOTE
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 ser vidor de destino , verifique se Selecionar um ser vidor no pool de ser vidores
está marcada. Em Pool de Ser vidores , verifique se o computador local está selecionado. Clique em
Próximo .
5. Em Selecionar funções de ser vidor , em Funções , clique em Ser viços de Domínio Active
Director y . Em Adicionar recursos que são necessários para Ser viços de Domínio Active
Director y , clique em Adicionar Recursos . Clique em Próximo .
6. Em Selecionar recursos , clique em Avançar e, em Ser viços de Domínio Active Director y , 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 ser vidor 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 Ser vidor 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 de AD DS e 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
destacados na imagem abaixo.

C r i a r u m a C o n t a d e U su á r i o e m U su á r i o s e C o m p u t a d o r e s d o A c t i v e D i r e c t o r y

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.
 NOTE
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 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"

P a ra c ri a r u ma c o n t a d e u s u á ri o

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

Active Director y . 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.
Posição?
Active Directory a pasta usuários e computadores/nó do 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 .
A t r i b u i r a a sso c i a ç ã o a o g r u p o

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.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
A t ri b u i r a a s s o c i a ç ã o a o g ru p o

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

Active Director y . 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?
Active Director y usuários e computadores / nó / de domínio pasta que 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.
C o n fi g u r a r u m a z o n a d e p e sq u i sa i n v e r sa d e D N S

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 .

NOTE
Para organizações de médio e grande porte, é recomendável que você configure e use o grupo DNSAdmins em Active
Directory usuários e computadores. 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

P a ra c o n f i g u ra r u ma z o n a d e p e s q u i s a i n v e rs a d e DN S

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 Director y está marcada. Clique em Próximo .
7. Em Escopo de Replicação de Zona do Active Director y , selecione Para todos os ser vidores 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:

NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, 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

p a ra u n i r c o mp u t a d o re s q u e e x e c u t a m o W i n d o w s Se rv e r 2016, o W i n d o w s Se rv e r 2012 R 2 e o W i n d o w s Se rv e r 2012 a o d o mí n i o

1. No Gerenciador do Servidor, clique em Ser vidor 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 .
 NOTE
Para obter informações sobre como unir computadores que estão executando outros sistemas operacionais da Microsoft
ao domínio, consulte o Apêndice C-unindo computadores ao domínio.

P a ra f a z e r l o g o n n o d o mí n i o u s a n d o c o mp u t a d o re s q u e e x e c u t a m o W i n d o w s Se rv e r 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.

NOTE
Para obter informações sobre como fazer logon no domínio usando computadores que executam outros sistemas
operacionais da Microsoft, consulte o 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 Configurando todos os servidores.
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

NOTE
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 10.0.1.254 -SubnetMask

255.255.255.0 -State Active

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

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

DHCP1.corp.contoso.com

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

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

I n st a l a r o p r o t o c o l o D H C P

Você pode usar este procedimento para instalar e configurar a função de Servidor DHCP usando o Assistente
para Adicionar Funções e Recursos.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
P a ra i n s t a l a r o DHC P

1. No DHCP1, 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 .

NOTE
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 ser vidor de destino , verifique se Selecionar um ser vidor no pool de ser vidores
está marcada. Em Pool de Ser vidores , verifique se o computador local está selecionado. Clique em
Próximo .
5. Em selecionar funções de ser vidor , em funções , selecione ser vidor DHCP . Em Adicionar
recursos que são necessários para Ser vidor DHCP , clique em Adicionar Recursos . Clique em
Próximo .
6. Em Selecionar recursos , clique em Avançar e, em Ser vidor DHCP , analise as informações fornecidas
e clique em Avançar .
7. Em Confirmar seleções de instalação , clique em Reiniciar cada ser vidor 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 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 .
C r i a r e a t i v a r u m n o v o e sc o p o d o D H C P

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.
P a ra c ri a r e a t i v a r u m n o v o e s c o p o d o DHC P

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 Inter valo 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 Ser vidor 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 ser vidor , 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 Ser vidores 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çar e em Concluir .

IMPORTANT
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

NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, 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

P a r a i n g r e ssa r c o m p u t a d o r e s e x e c u t a n d o W i n d o w s 1 0 a o d o m í n i o

1. Faça logon no computador com a conta de Administrador local.

2. Em Pesquisar na Web e 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 do , clique em Domínioe 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 .
6. Clique em OK . A caixa de diálogo Segurança do Windows será aberta.
7. 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 .
8. 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 .
9. 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 .
P a r a i n g r e ssa r c o m p u t a d o r e s q u e e x e c u t a m W i n d o w s 8 .1 a o d o m í n i o

1. Faça logon no computador com a conta de Administrador local.

2. Clique com o botão direito do mouse em Iniciar e 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 do , clique em Domínioe 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 .
6. Clique em OK . A caixa de diálogo Segurança do Windows será aberta.
7. 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 .
8. 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 .
9. 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 .
P a r a fa z e r l o g o ff n o d o m í n i o u sa n d o c o m p u t a d o r e s q u e e x e c u t a m W i n d o w s 1 0

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 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 .
5. Em Senha , digite sua senha do domínio e clique na seta ou pressione ENTER.
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.

NOTE
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 Windows Server Core Network 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 diretivas de rede) permite que você configure e gerencie centralmente as políticas de rede
com os seguintes recursos: serviço RADIUS (RADIUS) servidor 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 que são 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 Área de Trabalho Remota gateway.
Você planeja implantar a autenticação 802.1 X para acesso com ou sem fio.
Antes de implantar esse serviço de função, você deve executar as etapas a seguir no computador que está
configurando como um NPS.
Siga as etapas na seção Configurando todos os servidores.
Siga as etapas na seção Ingressando computadores servidores no domínio e 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

NOTE
Este guia fornece instruções para implantar o NPS em um servidor autônomo ou VM chamada NPS1. Outro modelo de
implantação recomendado é a instalação do NPS em um controlador de domínio. Se preferir instalar o NPS em um
controlador de domínio em vez de em um servidor autônomo, instale o NPS no DC1.

P l a n e j a n d o a i m p l a n t a ç ã o d o N P S1

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.
I n st a l a r o N P S (Se r v i d o r d e P o l í t i c a s d e R e d e )

Você pode usar este procedimento para instalar o NPS (servidor de diretivas 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.

NOTE
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 e IPv4
do protocolo ip versão 6 ) . se os servidores de acesso à rede estiverem configurados para enviar tráfego RADIUS por
portas diferentes desses padrões, remova as exceções criadas em Windows Firewall 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 .

NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite o texto a seguir e pressione
ENTER.
Install-WindowsFeature NPAS -IncludeManagementTools
P a ra i n s t a l a r o N P S

1. No NPS1, 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 .

NOTE
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 ser vidor de destino , verifique se Selecionar um ser vidor no pool de ser vidores
está marcada. Em Pool de Ser vidores , verifique se o computador local está selecionado. Clique em
Próximo .
5. em selecionar funções de ser vidor , em funções , selecione política de rede e Ser viços do
Access . uma caixa de diálogo será aberta perguntando se ele deve adicionar recursos necessários para a
política de rede e Serviços do Access. Clique em Adicionar Recursos e depois em Avançar .
6. Em Selecionar recursos , clique em Avançar e, em Ser viços de Acesso e Política de Rede , analise
as informações fornecidas e clique em Avançar .
7. Em Selecionar ser viços de função , clique em Ser vidor de Políticas de Rede . Em Adicionar
recursos que são necessários para Ser vidor de Políticas de Rede , clique em Adicionar
Recursos . Clique em Próximo .
8. Em Confirmar seleções de instalação , clique em Reiniciar cada ser vidor 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 "a instalação foi bem-sucedida em ComputerName" será exibida,
em que ComputerName é o nome do computador no qual você instalou o servidor de políticas de rede.
Clique em Fechar .
R e g i st r a r o N P S n o d o m í n i o p a d r ã o

Você pode usar este procedimento para registrar um NPS no domínio em que o servidor é membro do
domínio.
NPSs deve ser registrado em Active Directory para que eles tenham permissão para ler as propriedades de
discagem de contas de usuário durante o processo de autorização. O registro de um NPS adiciona o servidor ao
grupo de Ser vidores RAS e ias em Active Directory.
Credenciais administrativas
Para concluir este procedimento, você deve ser um membro do grupo Administradores de Domínio .

NOTE
para executar esse procedimento usando comandos do shell de rede (Netsh) no 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

P a ra re g i s t ra r u m N P S e m s e u d o mí n i o p a d rã o

1. No NPS1, no Gerenciador do Servidor, clique em Ferramentas e em Ser vidor 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 ser vidor no Active
Director y . A caixa de diálogo Ser vidor de Políticas de Rede é aberta.
3. Em Ser vidor de Políticas de Rede , clique em OK e em OK novamente.
Para obter mais informações sobre o servidor de políticas de rede, consulte servidor de diretivas de rede (NPS).
Implantando o WEB1
a função do 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 Serviços de Informações
da Internet (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).
Além de permitir que você publique uma CRL para acesso por computadores membros do domínio, a função de
servidor servidor Web (IIS) permite que você configure e gerencie vários sites da Web, 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:
Siga as etapas na seção Configurando todos os servidores.
Siga as etapas na seção Ingressando computadores servidores no domínio e fazendo logon.
Instalar a função de servidor do Servidor Web (IIS)
I n st a l a r a fu n ç ã o d e se r v i d o r d o Se r v i d o r W e b (I I S)

Para concluir este procedimento, é preciso ser um membro do grupo Administradores .

NOTE
Para executar este procedimento usando o Windows PowerShell, abra o PowerShell, digite o texto a seguir e pressione
ENTER.
Install-WindowsFeature Web-Server -IncludeManagementTools

1. No Gerenciador do Ser vidor , clique em Gerenciar e depois 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 .

NOTE
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. Na página Selecionar tipo de instalação , clique em Avançar .
4. Na página selecionar ser vidor de destino , verifique se o computador local está selecionado e clique
em Avançar .
5. Na página selecionar funções de ser vidor , role para e selecione ser vidor Web (IIS) . A caixa de
diálogo Adicionar recursos necessários para o ser vidor Web (IIS) é aberta. Clique em Adicionar
Recursos e 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:
recursos de biblioteca técnica do Windows Server 2016, do Windows Server 2012 R2 e do Windows Server
2012
O que há de novo no Active Directory Domain Services (AD DS) 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
https://technet.microsoft.com/library/hh831667.aspx .
Implementando a função Administradores de DNS
Visão geral do protocolo DHCP em https://technet.microsoft.com/library/hh831825.aspx .
visão geral de política de rede e Serviços do Access em
https://technet.microsoft.com/library/hh831683.aspx .
Visão geral do servidor Web (IIS) em https://technet.microsoft.com/library/hh831725.aspx .

Apêndices A a E
as seções a seguir contêm informações de configuração adicionais para computadores que executam 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 com sua implantação.
1. Apêndice A – Renomeando computadores
2. Apêndice B – Configurando endereços IP estáticos
3. Apêndice C – unindo computadores ao 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
Windows Server 2008 R2 e Windows 7
A associação a Administradores ou equivalente é o requisito mínimo para a execução destes procedimentos.
P a r a r e n o m e a r o s c o m p u t a d o r e s q u e e x e c u t a m o W i n d o w s Se r v e r 2 0 0 8 R 2 e o W i n d o w s 7

1. Clique em Iniciar , clique com botão direito do computador e 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.

NOTE
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 é 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.
Windows Server 2008 e Windows Vista
A associação a Administradores ou equivalente é o requisito mínimo para a execução destes procedimentos.
P a r a r e n o m e a r o s c o m p u t a d o r e s e x e c u t a n d o o W i n d o w s Se r v e r 2 0 0 8 e o W i n d o w s Vi st a

1. Clique em Iniciar , clique com botão direito do computador e 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.

NOTE
em computadores que executam o Windows Vista, antes da caixa de diálogo propriedades do sistema ser
aberta, a caixa de diálogo controle de conta de usuário é 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.

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 R2
Windows Server 2008
Windows Server 2008 R2
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
 P a r a c o n fi g u r a r u m e n d e r e ç o I P e st á t i c o e m u m c o m p u t a d o r e x e c u t a n d o o W i n d o w s Se r v e r 2 0 0 8 R 2

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 Compar tilhamento . A Central de Rede e
Compar tilhamento será aberta.
3. Na Central de Rede e Compar tilhamento , 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.
6. 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.
7. 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.
8. No Gateway padrão , digite o endereço IP do seu gateway padrão.
9. Em Ser vidor 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.
10. Em Ser vidor 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.
11. Clique em OK e então clique em Fechar .
Windows Server 2008
A associação a Administradores ou equivalente é o requisito mínimo para a execução destes procedimentos.
P a r a c o n fi g u r a r u m e n d e r e ç o I P e st á t i c o e m u m c o m p u t a d o r e x e c u t a n d o o W i n d o w s Se r v e r 2 0 0 8

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 Compar tilhamento .
3. Na Central de Rede e Compar tilhamento , 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.
6. 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.
7. 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.
 8. No Gateway padrão , digite o endereço IP do seu gateway padrão.
9. Em Ser vidor 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.
10. Em Ser vidor 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.
11. Clique em OK e então clique em Fechar .

Apêndice C – Ingressar computadores no domínio

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

IMPORTANT
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).

Windows Server 2008 R2 e Windows 7

O requisito mínimo para executar este procedimento é a associação ao grupo Usuários do Domínio ou
equivalente.
P a r a i n g r e ssa r c o m p u t a d o r e s q u e e x e c u t a m o W i n d o w s Se r v e r 2 0 0 8 R 2 e o W i n d o w s 7 n o d o m í n i o

1. Faça logon no computador com a conta de Administrador local.

2. Clique em Iniciar , clique com botão direito do computador e clique em Propriedades . Será exibida a
caixa de diálogo Sistema .
3. 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.

NOTE
Em computadores que executam 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.

4. Clique em Alterar . A caixa de diálogo Alterações de Nome/Domínio do Computador será aberta.

5. No Nome do Computador , em Membro de , selecione 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 .
6. Clique em OK . A caixa de diálogo Segurança do Windows será aberta.
7. 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 .
8. 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 .
9. 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 .
Windows Server 2008 e Windows Vista
O requisito mínimo para executar este procedimento é a associação ao grupo Usuários do Domínio ou
equivalente.
P a r a i n g r e ssa r c o m p u t a d o r e s q u e e x e c u t a m o W i n d o w s Se r v e r 2 0 0 8 e o W i n d o w s Vi st a n o d o m í n i o

1. Faça logon no computador com a conta de Administrador local.

2. Clique em Iniciar , clique com botão direito do computador e clique em Propriedades . Será exibida a
caixa de diálogo Sistema .
3. 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.
4. Clique em Alterar . A caixa de diálogo Alterações de Nome/Domínio do Computador será aberta.
5. No Nome do Computador , em Membro de , selecione 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 .
6. Clique em OK . A caixa de diálogo Segurança do Windows será aberta.
7. 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 .
8. 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 .
9. 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 .

Apêndice D – Fazer logoff no domínio

Você pode usar esses procedimentos para fazer logoff no domínio usando computadores que executam o
Windows Server 2008 R2, Windows 7, Windows Server 2008 e Windows Vista.
Windows Server 2008 R2 e Windows 7
Windows Server 2008 e Windows Vista
Windows Server 2008 R2 e Windows 7
O requisito mínimo para executar este procedimento é a associação ao grupo Usuários do Domínio ou
equivalente.
F a z e r l o g o n n o d o m í n i o u sa n d o c o m p u t a d o r e s q u e e x e c u t a m o W i n d o w s Se r v e r 2 0 0 8 R 2 e o W i n d o w s 7

1. Faça logoff do computador ou o reinicie.

2. Pressione CTRL + ALT + DELETE. A tela de logon é exibida.
3. Clique em Trocar de Usuário e 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 .
5. Em Senha , digite sua senha do domínio e clique na seta ou pressione ENTER.
Windows Server 2008 e Windows Vista
O requisito mínimo para executar este procedimento é a associação ao grupo Usuários do Domínio ou
equivalente.
F a z e r l o g o n n o d o m í n i o u sa n d o c o m p u t a d o r e s q u e e x e c u t a m o W i n d o w s Se r v e r 2 0 0 8 e o W i n d o w s Vi st a

1. Faça logoff do computador ou o reinicie.

2. Pressione CTRL + ALT + DELETE. A tela de logon é exibida.
3. Clique em Trocar de Usuário e 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 .
5. Em Senha , digite sua senha do domínio e clique na seta ou pressione ENTER.

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.
I t e n s d e c o n fi g u r a ç ã o d e p r é - i n st a l a ç ã o p a r a o A D D S e o D N S

As seguintes tabelas listam os itens de configuração de pré-instalação descritos em Configurando todos os

servidores:
Configurar um endereço IP estático
 IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Endereço IP 10.0.0.2

Máscara de sub-rede 255.255.255.0

Gateway padrão 10.0.0.1

Servidor DNS preferencial 127.0.0.1

Servidor DNS alternativo 10.0.0.15

Renomear o computador

IT EM DE C O N F IGURA Ç Ã O VA LO R DE EXEM P LO VA LO R

Nome do computador DC1

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

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:

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Nome DNS completo corp.contoso.com

Nível funcional da floresta Windows Server 2003

Local da pasta do banco de dados dos E:\Configuration\

Serviços de Domínio Active Directory Ou aceite o local padrão.

Local da pasta dos arquivos de log dos E:\Configuration\

Serviços de Domínio Active Directory Ou aceite o local padrão.

Local da pasta do SYSVOL dos E:\Configuration\

Serviços de Domínio Active Directory Ou aceite o local padrão.

Senha do Administrador do Modo de J*p2leO4$F

Restauração de Diretório

Nome de arquivo de resposta AD DS_AnswerFile

(opcional)

Configurando uma zona de pesquisa inversa de DNS

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Tipo de zona: -Zona primária

-Zona secundária
-Zona de stub
 IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Tipo de zona -Selecionado

Armazenar a zona no Active -Não selecionado
Director y

Escopo de replicação de zona do -Para todos os servidores DNS nesta

Active Directory floresta
-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 inversa -Zona de pesquisa inversa de IPv4

(tipo de IP) -Zona de pesquisa inversa do IPv6

Nome da zona de pesquisa inversa 10.0.0

(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.
I t e n s d e c o n fi g u r a ç ã o d e p r é - i n st a l a ç ã o d o D H C P

As seguintes tabelas listam os itens de configuração de pré-instalação descritos em Configurando todos os

servidores:
Configurar um endereço IP estático

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Endereço IP 10.0.0.3

Máscara de sub-rede 255.255.255.0

Gateway padrão 10.0.0.1

Servidor DNS preferencial 10.0.0.2

Servidor DNS alternativo 10.0.0.15

Renomear o computador

IT EM DE C O N F IGURA Ç Ã O VA LO R DE EXEM P LO VA LO R

Nome do computador DHCP1

I t e n s d e c o n fi g u r a ç ã o d e i n st a l a ç ã o d o D H C P

Os itens de configuração do procedimento de implantação da Rede Principal do Windows Server Instalar o

protocolo DHCP:
 IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Ligações de conexão de rede Ethernet

Configurações do servidor DNS DC1

Endereço IP do servidor DNS 10.0.0.2

preferencial

Endereço IP do servidor DNS 10.0.0.15

alternativo

Nome do escopo Corp1

Endereço IP inicial 10.0.0.1

Endereço IP final 10.0.0.254

Máscara de sub-rede 255.255.255.0

Gateway padrão (opcional) 10.0.0.1

Duração da concessão 8 dias

Modo de operação do servidor DHCP não ativado

IPv6

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.

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Nome do escopo Corp1

Descrição do escopo Sub-rede do escritório principal 1

Endereço IP inicial do intervalo de 10.0.0.1

exclusão

Endereço IP final do intervalo de 10.0.0.15

exclusão

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:

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Novo nome do escopo Corp2

Descrição do escopo Sub-rede principal 2

 IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

(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

Máscara de sub-rede 255.255.255.0

Endereço IP Inicial (intervalo de 10.0.1.1

exclusão)

Endereço IP final do intervalo de 10.0.1.15

exclusão

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.
I t e n s d e c o n fi g u r a ç ã o d e p r é - i n st a l a ç ã o

As seguintes três tabelas listam os itens de configuração de pré-instalação descritos em Configurando todos os
servidores:
Configurar um endereço IP estático

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Endereço IP 10.0.0.4

Máscara de sub-rede 255.255.255.0

Gateway padrão 10.0.0.1

Servidor DNS preferencial 10.0.0.2

 IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO VA LO RES

Servidor DNS alternativo 10.0.0.15

Renomear o computador

IT EM DE C O N F IGURA Ç Ã O VA LO R DE EXEM P LO VA LO R

Nome do computador NPS1

I t e n s d e c o n fi g u r a ç ã o d e i n st a l a ç ã o d o Se r v i d o r d e P o l í t i c a s d e R e d e

Itens de configuração para os Windows implantação nps de rede do server core instalam o NPS (Servidor de
Políticas 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
10/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

embora o guia de rede do 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
complementares 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 complementar de rede de núcleo: implantar certificados de

servidor para implantações com e sem fio 802.1 X
Este guia complementar explica como criar a rede principal implantando certificados de servidor para
computadores que estão executando o NPS do servidor de políticas de rede ( ) , RAS do serviço de acesso
remoto ( ) ou ambos.
Certificados de servidor são necessários quando você implanta métodos de autenticação com base em
certificado com EAP de protocolo de autenticação extensível ( ) e EAP protegido ( ) para autenticação de acesso à
rede. A implantação de certificados de servidor com Active Directory serviços ( de certificados AD CS ) para EAP
e métodos de autenticação com base em certificado PEAP oferece os seguintes benefícios:
Associando a identidade do servidor NPS ou RAS a uma chave privada
Um método seguro e econômico para registrar automaticamente certificados em servidores de 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 e sem fio 802.1 x.

Guia complementar de rede de núcleo: implantar Password-Based

acesso sem fio autenticado 802.1 X
Este guia complementar explica como criar a rede principal fornecendo instruções sobre como implantar o
Institute of Electrical and Electronics Engineers ( IEEE ) 802.1 x - autenticado com acesso sem fio IEEE 802,11
usando 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
servidor de políticas de rede ( NPS ) apresentem clientes sem fio com um certificado de servidor para provar a
identidade do NPS para o cliente, mas a autenticação do usuário não é executada usando um certificado-em vez
disso, os usuários fornecem seu nome de usuário e senha de domínio.
Como - o PEAP MS - CHAP v2 requer 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 dispendioso 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á ter as
tecnologias apresentadas nesse guia implantadas em sua rede.
2. Siga as instruções no guia complementar de rede principal implantar certificados de servidor para
implantações 802.1 X com e sem fio, ou já ter as tecnologias apresentadas nesse guia implantadas em sua
rede.
Para obter instruções sobre como implantar o acesso sem fio com o PEAP - MS - CHAP v2, consulte implantar
Password-Based acesso sem fio autenticado 802.1 x.

Guia complementar de rede de núcleo: implantar o modo de cache

hospedado do BranchCache
Este guia complementar 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 longa distância) 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 que o cliente que originalmente solicitou e armazene os dados em cache esteja 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 que os clientes estejam
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
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este guia para implantar certificados de servidor em seus servidores de infraestrutura do NPS
(Servidor de Políticas de Rede e Acesso Remoto).
Este guia contém as seções a seguir.
Pré-requisitos para usar este guia
O que este guia não contém
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 Serviços de Certificados do Active Directory (AD CS) para registrar
automaticamente certificados em servidores de infraestrutura nps e acesso remoto. AD CS permite que você
crie uma PKI (infraestrutura de chave pública) e forneça criptografia de chave pública, certificados digitais e
funcionalidades 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 da 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 computador.
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 DirectAccess ou VPN (rede virtual
privada) padrão e 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
Ser vidores RAS e IAS.
Vantagens do registro automático de certificado
O registro automático de certificados de servidor, também chamado de registro automático, oferece as
seguintes vantagens.
A AC (autoridade de certificação) AD CS aplicativo registra automaticamente um certificado do servidor em
todos os seus servidores NPS e Acesso Remoto.
Todos os computadores no domínio recebem automaticamente seu certificado de autoridade de certificação,
 que é instalado no armazenamento autoridades de certificação raiz confiáveis em cada computador membro
do domínio. Por isso, todos os computadores no domínio confiam nos certificados emitidos pela ac. Essa
confiança permite que os servidores de autenticação provem suas identidades entre si e se envolvam em
comunicações seguras.
Além de atualizar Política de Grupo, a reconfiguração manual de cada servidor não é necessária.
Cada certificado do servidor inclui a finalidade da Autenticação do Servidor e a finalidade da Autenticação do
Cliente em extensões de EKU (Uso Aprimorado de Chave).
Escalabilidade. Depois de implantar sua AC Enterprise raiz com este guia, você pode expandir sua PKI
(infraestrutura de chave pública) adicionando Enterprise AC subordinadas.
Capacidade de gerenciamento. Você pode gerenciar AD CS usando o console AD CS ou usando Windows
PowerShell e scripts.
Simplicidade. Especifique os servidores que registram certificados de servidor usando contas de grupo do
Active Directory e 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 diferentes modelos de
certificado para tipos de servidor específicos ou pode usar o mesmo modelo para todos os certificados de
servidor que deseja emitir.

Pré-requisitos para usar este guia

Este guia fornece instruções sobre como implantar certificados de servidor usando AD CS função de servidor
Web (IIS) no Windows Server 2016. A seguir estão os pré-requisitos para executar os procedimentos neste guia.
Você deve implantar uma rede principal usando o Windows Server 2016 Core Network Guide ou já deve
ter as tecnologias fornecidas no Guia de Rede Principal instaladas e funcionando corretamente em sua
rede. Essas tecnologias incluem TCP/IP v4, DHCP, Active Directory Domain Services (AD DS), DNS e NPS.

NOTE
O Windows Server 2016 De rede principal está disponível na biblioteca Windows Server 2016 técnica. Para obter
mais informações, consulte Guia de rede principal.

Você deve ler a seção de planejamento deste guia para garantir que esteja 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 AC sem executar as etapas que levam à implantação do servidor ou 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 AC raiz do Enterprise e um servidor no qual você instalará o Servidor Web
(IIS) para que sua AC possa publicar a CRL (lista de certificados revogados) no servidor Web.

NOTE
Você está preparado para atribuir um endereço IP estático aos servidores Web e AD CS que você implantar com este
guia, bem como nomear os computadores de acordo com as convenções de nomenur de sua organização. Além disso,
você deve unir os computadores ao seu domínio.

O que este guia não contém

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

Visões gerais da tecnologia

A seguir estão as visão geral de tecnologia para AD CS e Servidor Web (IIS).
Serviços de Certificados do Active Directory
AD CS no Windows Server 2016 fornece serviços personalizáveis para criar e gerenciar os certificados X.509
usados em sistemas de segurança de software que empregam tecnologias de chave pública. As organizações
podem AD CS para aprimorar a segurança vinculando a identidade de uma pessoa, dispositivo ou serviço a uma
chave pública correspondente. AD CS também inclui recursos que permitem gerenciar o registro e a revogação
de certificados em uma variedade de ambientes escalonáveis.
Para obter mais informações, consulte Visão Serviços de Certificados do Active Directory visão geral 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 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 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
12/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico inclui as seções a seguir.

Componentes de implantação de certificado do servidor
Visão geral do processo de implantação de certificado do servidor

Componentes de implantação de certificado do servidor

você pode usar este guia para instalar Active Directory serviços de certificados (AD CS) como uma autoridade
de certificação raiz Enterprise (CA) e registrar certificados de servidor em servidores que executam o nps
(servidor de diretivas de rede), o serviço de roteamento e acesso remoto (RRAS) ou nps e RRAS.
Se você implantar o SDN com a autenticação baseada em certificado, os servidores serão obrigados a usar um
certificado do servidor para provar suas identidades para outros servidores para que eles obtenham
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.

NOTE
Na ilustração acima, vários servidores são representados: 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á
tenha instalado em sua rede. Se você ainda não tiver instalado seu domínio de Active Directory, poderá fazer isso usando
o Guia de rede principal para Windows Server 2016.

Para obter mais informações sobre cada item representado na ilustração acima, consulte o seguinte:
CA1
WEB1
DC1
 NPS1
CA1 executando a função de servidor AD CS
nesse cenário, a autoridade de certificação raiz Enterprise (ca) também é uma ca emissora. A AC emite
certificados para computadores de servidor que têm as permissões de segurança corretas para registrar um
certificado. Os serviços de certificado Active Directory (AD CS) são instalados em CA1.
Para redes maiores ou em que as questões de segurança fornecem justificativa, você pode separar as funções da
CA raiz e da CA emissora e implantar CAs subordinadas que estão emitindo CAs.
nas implantações mais seguras, o Enterprise ac raiz é colocado offline e fisicamente protegido.
Arquivo de CAPolicy. inf
Antes de instalar o AD CS, você configura 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 Ser vidores 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 Ser vidores RAS e ias para que a
autoridade de certificação possa criar certificados de servidor que ele emite para os grupos em Active Directory
usuários e computadores que você especificar.
Configuração de CA1 adicional
A CA publica uma CRL (lista de certificados revogados) 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 autoridade de certificação 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 de 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 Windows Explorer para uso como o local para a CRL e o 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 do 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 a 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 Diretiva de domínio padrão
Depois de configurar o modelo de certificado na autoridade de certificação, você pode configurar a política de
domínio padrão no Política de Grupo para que os certificados sejam registrados automaticamente nos
servidores NPS e RAS. O Política de Grupo está configurado em AD DS no servidor DC1.
Registro de recurso de alias DNS (CNAME)
Você deve criar um registro de recurso de alias (CNAME) 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 fornece 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 do servidor de políticas de rede da diretiva de rede e da função de
servidor Serviços do Access
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 nos 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 do CA1.
Visão geral do processo de implantação de certificado do servidor

NOTE
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 nestes estágios:

1. No WEB1, instale a função do 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 autoridade de certificação e, em seguida, publique a crl
e copie o Enterprise certificado de autoridade de certificação raiz para o novo diretório virtual.
4. no computador em que você está planejando instalar o AD CS, atribua ao computador um endereço IP
estático, renomeie o computador, ingresse o computador no domínio e, em seguida, faça logon no
computador com uma conta de usuário que seja membro dos grupos admins. do domínio e
administradores de Enterprise.
5. No computador em que você pretende instalar o AD CS, configure o arquivo CAPolicy. inf com
configurações específicas à sua implantação.
6. Instale a função de servidor do AD CS e execute a configuração adicional da autoridade de certificação.
7. Copie a CRL e o certificado de autoridade de certificação de CA1 para o compartilhamento no servidor
Web WEB1.
8. Na AC, configure uma cópia do modelo de certificado de servidores RAS e IAS. A CA emite certificados
com base em um modelo de certificado, portanto, você deve configurar o modelo para o certificado do
servidor antes que a autoridade de certificação possa emitir um certificado.
9. Configure o registro automático do certificado do servidor no Política de Grupo. Quando você configura
o registro automático, todos os servidores que você especificou com Active Directory associações de
grupo 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. Atualizar Política de Grupo em servidores. Quando Política de Grupo é atualizado, os servidores recebem
o certificado do servidor, que é baseado 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.

NOTE
todos os computadores membros do domínio recebem automaticamente o certificado da autoridade de
certificação 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 autoridade de
certificação é instalado automaticamente no repositório de certificados das autoridades de certificação raiz
confiáveis para todos os computadores membros do domínio para que eles confiem nos certificados emitidos por
essa autoridade de certificação.
11. Verifique se todos os servidores registraram um certificado de servidor válido.
 Planejamento da implantação de certificado do
servidor
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 no servidor Web
Planejar um registro de alias DNS (CNAME) para seu servidor Web
Configuração de plano do CAPolicy. inf
Planejar a configuração das extensões CDP e AIA no 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 autoridade de certificação

Planejar a configuração básica do servidor

depois de instalar o 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 de rede Windows Server 2016 Core.

Planejar o acesso ao 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. além disso, a maioria dos procedimentos neste guia exige
que a conta de usuário seja membro dos grupos administradores de Enterprise ou administradores de domínio
em Active Directory usuários e computadores, 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 de rede Windows Server 2016 Core.

Planejar o local e o nome do diretório virtual no servidor Web

Para fornecer acesso à CRL e ao certificado de autoridade de certificação a 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 seu
diretório virtual no servidor Web em qualquer local de pasta que seja apropriado para sua implantação.

Planejar um registro de alias DNS (CNAME) para seu servidor Web

Os registros de recurso de alias (CNAME) às vezes também são chamados de registros de recursos de nome
canônico. Com esses registros, você pode usar mais de um nome para apontar para um único host, facilitando a
realização de coisas como hospedar um servidor de 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 mapeiam 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 autoridade de certificação (CA). Como você também pode querer usar seu servidor Web
para outras finalidades, como para 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 que seja apropriado para sua implantação.

Configuração de plano do CAPolicy. inf

Antes de instalar o AD CS, você deve configurar o CAPolicy. inf na AC com informações que estão 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 ocorre porque o servidor Web neste guia é
denominado WEB1 e tem um registro de recurso DNS CNAME de PKI. O servidor Web também é
ingressado no domínio corp.contoso.com. Além disso, há um diretório virtual no servidor Web chamado
"PKI", no qual a lista de certificados revogados é armazenada. Verifique se o valor que você fornece para
a URL em seu arquivo CAPolicy. inf aponta para um diretório virtual no seu servidor Web em seu
domínio.
RenewalKeyLength . o comprimento de chave de renovação padrão para o AD CS no Windows Server
2012 é 2048. O comprimento da chave que você selecionar deve ser o mais longo possível e, ao mesmo
tempo, fornecer compatibilidade com os aplicativos que você pretende usar.
RenewalValidityPeriodUnits . O arquivo CAPolicy. inf de exemplo tem um valor de
RenewalValidityPeriodUnits de 5 anos. Isso ocorre porque o ciclo de vida esperado da autoridade de
certificação é de cerca de dez anos. O valor de RenewalValidityPeriodUnits deve refletir o período de
validade geral da autoridade de certificação ou o número mais alto de anos para o qual você deseja
fornecer o registro.
CRLPeriodUnits . O arquivo CAPolicy. inf de exemplo tem um valor de CRLPeriodUnits de 1. Isso ocorre
porque o intervalo de atualização de exemplo para a lista de certificados revogados neste guia é de 1
semana. No valor de intervalo que você especificar com essa configuração, você deve publicar a CRL na
autoridade de certificação 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 arquivo 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 clientes Windows XP que exigem certificados dessa autoridade de
certificação.
Se você não planeja adicionar qualquer CAs subordinada à sua infraestrutura de chave pública posteriormente
e, se desejar evitar a adição de qualquer CAs subordinada, poderá adicionar a chave PathLength ao arquivo
cafiler. inf com um valor de 0. Para adicionar essa chave, copie e cole o código a seguir em seu arquivo:

[BasicConstraintsExtension]
PathLength=0
Critical=Yes

IMPORTANT
Não é recomendável alterar qualquer outra configuração 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 no CA1

Ao configurar o ponto de distribuição da CRL (lista de certificados revogados) e as configurações de AIA (acesso
a informações de autoridade) em CA1, você precisará do nome do seu servidor Web e do seu nome de domínio.
Você também precisa do nome do diretório virtual que você cria no servidor Web onde a CRL (lista de
certificados revogados) e o certificado de autoridade de certificação são armazenados.
O local de 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 seu servidor Web for denominado WEB1 e o registro CNAME do alias DNS para o servidor
Web for "PKI", seu domínio for corp.contoso.com e seu diretório virtual for chamado PKI, o local de 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 seu servidor Web for denominado WEB1 e o registro CNAME do alias DNS para o servidor
Web for "PKI", seu domínio for corp.contoso.com e seu diretório virtual for chamado PKI, o local 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 a CRL e o certificado de autoridade de certificação da CA para o diretório virtual do servidor Web,
você pode executar o comando certutil-crl depois de configurar os locais de CDP e AIA na autoridade de
certificação. Verifique se você configurou os caminhos corretos na guia extensões de propriedades de CA antes
de executar esse comando usando as instruções neste guia. além disso, para copiar o certificado de autoridade
de certificação Enterprise 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
autoridade de certificação
Para implantar certificados de servidor autoinscritos, você deve copiar o modelo de certificado chamado RAS e
ser vidor IAS . Por padrão, essa cópia é denominada cópia do ser vidor RAS e ias . Se você quiser renomear
essa cópia de modelo, planeje o nome que deseja usar durante essa etapa de implantação.

NOTE
As três últimas seções de implantação deste guia, que permitem configurar o registro automático do certificado do
servidor, atualizar Política de Grupo em servidores e verificar se os servidores receberam um certificado de servidor válido
da CA-não exigem etapas de planejamento adicionais.
 Implantação de certificados de servidor
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Siga estas etapas para instalar uma AC (autoridade de certificação) raiz corporativa e implantar certificados de
servidor para uso com PEAP e EAP.

IMPORTANT
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

NOTE
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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 o IIS, ASP.NET, serviços FTP, PHP e Windows Communication Foundation
(WCF).
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)

Para concluir este procedimento, é preciso ser um membro do grupo Administradores .

NOTE
Para executar esse procedimento usando o Windows PowerShell, abra o PowerShell, digite o comando 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.
2. Em Antes de Começar , clique em Avançar .
Obser vação 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 ser vidor, clique em Próximo.
5. Na página Funções de ser vidor, selecione Ser vidor 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 CNAME ) de alias no DNS para
WEB1
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para adicionar um ( registro de recurso CNAME ) de nome canônico de alias
para seu servidor Web a uma zona no DNS em seu controlador de domínio. Com os 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 FTP ) e um servidor Web no mesmo computador.
Por isso, você é livre para usar o servidor Web para hospedar a CRL da lista de certificados revogados ( ) para
sua autoridade de certificação ( CA ) , 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 que são apropriados
para sua implantação.
Para executar esse procedimento, você deve ser membro de Admins . do domínio.

Para adicionar um ( registro de ) recurso CNAME de alias a uma zona

NOTE
para executar esse procedimento usando Windows PowerShell, consulte Add-DnsServerResourceRecordCName.

1. No DC1, no Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em DNS . O MMC

(console de gerenciamento Microsoft) do Gerenciador de DNS é aberto.
2. Na árvore de console, clique duas vezes em zonas de pesquisa direta , clique com o botão direito do
mouse na zona de pesquisa direta na qual você deseja adicionar o registro de recurso de alias e clique
em novo alias ( CNAME ) . A caixa de diálogo novo registro de recurso é aberta.
3. Em nome do alias , digite o nome do alias PKI .
4. Quando você digita um valor para nome de alias , o ( FQDN ) automático do nome de domínio
totalmente qualificado é preenchido automaticamente na caixa de diálogo. Por exemplo, se o nome do
alias for "PKI" e seu domínio for corp.contoso.com, o valor PKI.Corp.contoso.com será preenchido
automaticamente para você.
5. Em FQDN do nome de domínio totalmente qualificado ( para o host de ) destino , digite o
FQDN do seu servidor Web. Por exemplo, se o seu servidor Web for denominado WEB1 e seu domínio
for 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)
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

NOTE
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.
Windows O Explorer é aberto para a unidade C.
2. Crie uma nova pasta chamada PKI na unidade C:. Para fazer isso, clique em início e, 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 compar tilhar com e clique em pessoas específicas . A caixa de diálogo
Compar tilhamento de Arquivos será aberta.
4. Em compar tilhamento de arquivos , digite editores de cer tificado e 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 cer tificado e, em seguida, clique em leitura/gravação . Clique em compar tilhar e, 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 Ser viç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 Vir tual .
9. Em alias , digite PKI . Em caminho físico , digite C:\pki e 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 ser viç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 ser viç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
13/08/2021 • 9 minutes to read

Aplica-se a: Windows Server 2016

O CAPolicy.inf é um arquivo de configuração que define as extensões, restrições e outras definições de

configuração que são aplicadas a um certificado de AC raiz e todos os certificados emitidos pela AC raiz. O
arquivo CAPolicy.inf deve ser instalado em um servidor host antes do início da rotina de instalação da AC raiz.
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 do início do processo de renovação.
O CAPolicy.inf é:
Criado e definido manualmente por um administrador
Utilizado durante a criação de certificados de AC raiz e subordinados
Definido na AC de assinatura em que você assina e em emitida 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 AC.
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 criar um arquivo .inf adaptado às suas necessidades específicas.

Estrutura de arquivos CAPolicy.inf

Os termos a seguir são usados para descrever a estrutura do arquivo .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 ao aparecerem entre colchetes. Muitas seções, mas não todas, 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 a seguir, [Version] é a seção , Assinatura é a chave e " Windows NT " $ $ é o valor.
Exemplo:

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

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 para essa política específica. Para
cada política, você precisa fornecer um OID (identificador de objeto) definido pelo usuário e o texto que deseja
exibir 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 terão a seguinte
aparência:

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

Se você for usar uma URL para hospedar a instrução de política de AC, as próximas três linhas serão como:

[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.
As URLs com espaços ou texto com espaços devem estar entre 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 como:

[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 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 do 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

IMPORTANT
Não dá suporte a URLs HTTPS.
 As aspas devem cercar URLs com espaços.
Se nenhuma URLs for especificada , ou seja, se a seção [CRLDistributionPoint] existir no arquivo, mas
estiver vazia, a extensão do Ponto de Distribuição de CRL será omitida do certificado de AC raiz. Isso
geralmente é preferível ao configurar uma AC raiz. Windows não executa a verificação de revogação em
um certificado de AC raiz, portanto, a extensão CDP é supérflua em um certificado de AC raiz.
A AC pode publicar no ARQUIVO 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 AC raiz.
A AC determina as extensões DE CDP subordinadas da AC.
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 observações adicionais sobre a seção de acesso a informações de 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 AC raiz.
As extensões AIA da AC subordinada são determinadas pela AC que emitiu o certificado da AC
subordinada.
As URLs com espaços devem estar entre aspas.
Se nenhuma URLs for especificada , ou seja, se a seção [AuthorityInformationAccess] existir no
arquivo, mas estiver vazia, a extensão acesso a informações de autoridade será omitida do certificado de
AUTORIDADE raiz. Novamente, essa seria a configuração preferencial no caso de um certificado de
AUTORIDADE de Certificação raiz, pois não há autoridade maior do que 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 da renovação e o período de validade da CRL (lista de certificados
revogados) 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 ser
simplesmente omitidas do arquivo CAPolicy.inf. Como alternativa, muitas dessas configurações podem ser
alteradas depois que a AC tiver sido instalada.
Um exemplo seria parecido com:
 [certsrv_server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=Days
CRLPeriodUnits=2
CRLDeltaPeriod=Hours
CRLDeltaPeriodUnits=4
ClockSkewMinutes=20
LoadDefaultTemplates=True
AlternateSignatureAlgorithm=0
ForceUTF8=0
EnableKeyCounting=0

RenewalKeyLength define o tamanho da chave apenas para renovação. Isso só é usado quando um novo par
de chaves é gerado durante a renovação do certificado de AC. O tamanho da chave para o certificado de AC
inicial é definido quando a AC é instalada.
Ao renovar um certificado de AC com um novo par de chaves, o comprimento da chave pode ser aumentado ou
reduzido. Por exemplo, se você tiver definido um tamanho de chave de AC raiz 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á emitir 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 se aplica somente 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. 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 Serviços de Certificados do Active Directory para que as alterações entre em vigor.
LoadDefaultTemplates só se aplica durante a instalação de uma AC Enterprise aplicativo. 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 AD CS for
iniciado depois que a função tiver sido instalada, um usuário ou computador com permissões suficientes poderá
se registrar imediatamente para um certificado.
Talvez você não queira emitir nenhum certificado imediatamente após a instalação de uma AC, portanto, você
pode usar a configuração LoadDefaultTemplates para impedir que os modelos padrão são adicionados à AC
Enterprise. Se não houver modelos configurados na AC, ele não poderá emitir nenhum certificado.
AlternateSignatureAlgorithm configura a AC para dar suporte ao formato de assinatura PKCS 1 V2.1 para o
certificado de AC e solicitações # de certificado. Quando definido como 1 em uma AC raiz, o certificado de AC
incluirá o formato de assinatura PKCS # 1 V2.1. Quando definido em uma AC subordinada, a autoridade de
certificação subordinada criará uma solicitação de certificado que inclui o # formato de assinatura PKCS 1 v 2.1.
ForceUTF8 altera a codificação padrão de nomes diferenciados relativos (RDNS) em nomes diferenciados de
assunto e emissor para UTF-8. Somente os RDNs que dão suporte a UTF-8, como os que são definidos como
tipos de cadeia de caracteres de diretório por uma RFC, são afetados. Por exemplo, o RDN para o controlador de
domínio (DC) dá suporte à codificação como IA5 ou UTF-8, enquanto o RDN de país (C) dá suporte apenas à
codificação como uma cadeia de caracteres imprimível. Portanto, a diretiva ForceUTF8 afetará um RDN DC, mas
não afetará um RDN C.
EnableKeyCounting configura a autoridade de certificação para incrementar um contador sempre que a chave
de assinatura da autoridade de certificação é 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ços de criptografia) associado que
ofereça suporte à contagem de chaves. nem o CSP forte da microsoft nem o KSP (microsoft Software Key
Armazenamento Provider) oferece suporte à contagem de chaves.

Criar o arquivo CAPolicy. inf

Antes de instalar o AD CS, você configura o arquivo CAPolicy. inf com configurações específicas para sua
implantação.
Pré-requisito: Você deve ser um membro do grupo Administradores.
1. no computador em que você está planejando instalar o AD CS, abra Windows PowerShell, digite
notepad 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]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID=1.2.3.4.1455.67.89.5
Notice="Legal Policy Statement"
URL=https://pki.corp.contoso.com/pki/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
CRLPeriod=weeks
CRLPeriodUnits=1
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1
[CRLDistributionPoint]
[AuthorityInformationAccess]

4. Clique em arquivo e, em seguida, 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 .

Cau t i on

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.

IMPORTANT
No arquivo 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 é instruído a criar a declaração de prática de
certificado (CPS).
 Instalar a autoridade de certificação
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para instalar o Serviços de Certificados do Active Directory (AD CS) para que
você possa registrar um certificado do servidor em servidores que executam o NPS (Servidor de Políticas de
Rede), RRAS (Serviço de Roteamento e Acesso Remoto) ou ambos.

IMPORTANT
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. Para obter mais informações sobre
como realizar essas tarefas, consulte o Windows Server 2016 Core Network Guide.
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.

NOTE
Para executar esse procedimento usando Windows PowerShell, abra Windows PowerShell digite o comando a seguir e
pressione ENTER.
Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Depois AD CS instalado, digite o comando a seguir e pressione ENTER.

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA

Para instalar os Serviços de Certificados do Active Directory

TIP
Se você quiser usar o Windows PowerShell para instalar Serviços de Certificados do Active Directory, consulte Install-
AdcsCertificationAuthority para 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.
2. No Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções e Recursos . O
Assistente para Adicionar Funções e Recursos é aberto.
3. Em Antes de Começar , clique em Avançar .

NOTE
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.
 4. Em Selecionar Tipo de Instalação , verifique se Instalação baseada em função ou recurso está
marcada e clique em Avançar .
5. Em Selecionar ser vidor de destino , verifique se Selecionar um ser vidor no pool de ser vidores
está marcada. Em Pool de Ser vidores , verifique se o computador local está selecionado. Clique em
Próximo .
6. Em Selecionar Funções de Ser vidor , em Funções , selecione Ser viços de Cer tificados do Active
Director y . Quando você for solicitado a adicionar os recursos necessários, clique em Adicionar
Recursos e, em seguida, clique em Próximo.
7. Em Selecionar recursos, clique em Próximo.
8. No Ser viços de Cer tificados do Active Director y , leia as informações fornecidas e clique em
Próximo.
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 Ser viços de Cer tificados do
Active Director y no ser vidor de destino . O assistente AD CS configuração do aplicativo é aberto.
Leia as informações de credenciais e, se necessário, forneça as credenciais para uma conta que seja
membro do grupo Enterprise Administradores. Clique em Próximo .
10. Em Ser viços de Função, clique em Autoridade de Cer tificação e clique em Próximo.
11. Na página Tipo de Instalação, verifique se Enterprise CA está selecionada e clique em Próximo.
12. Na página Especificar o tipo da AC, verifique se a AC raiz está selecionada e clique em Próximo.
13. Na página Especificar o tipo da chave privada, verifique se a opção Criar uma nova chave privada
está selecionada e clique em Próximo.
14. Na página Criptografia para AC, mantenha as configurações padrão para CSP (RSA#Microsoft
Software Key Armazenamento Provider ) e algoritmo de hash (SHA2 ) e determine o melhor
comprimento de caracteres de chave para sua implantação. Comprimentos grandes de caracteres de
chave fornecem segurança ideal; No entanto, eles podem afetar o desempenho do servidor e podem não
ser compatíveis com aplicativos herdados. É recomendável que você mantenha a configuração padrão de
2048. Clique em Próximo .
15. Na página Nome da AC, mantenha o nome comum sugerido para a AC ou altere o nome de acordo com
suas necessidades. Verifique se você tem certeza de que o nome da AC é compatível com suas
convenções e finalidades de nomen por não poder alterar o nome da AC depois de instalar o AD CS.
Clique em Próximo .
16. Na página Período de Validade, em Especificar o período de validade , digite o número e selecione um
valor de tempo (Anos, Meses, Semanas ou Dias). A configuração padrão de cinco anos é recomendada.
Clique em Próximo .
17. Na página Banco de Dados da AC, em Especificar os locais do banco de dados , especifique o local
da pasta para o banco de dados de certificado e o log do banco de dados de 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 Próximo .
18. Em Confirmação , clique em Configurar para aplicar suas seleções e clique em Fechar .
 Configurar as extensões CDP e AIA em CA1
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para definir as configurações de CDP (Ponto de Distribuição da CRL) e AIA
(Acesso às Informações da Autoridade) na CA1.
Para executar esse 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 Cer tificaçã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 .

NOTE
O nome da ac é diferente se você não nomeou o computador CA1 e seu nome de domínio é diferente do deste
exemplo. O nome da AC está no formato domínio - CAComputerName-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
Remover . Em Confirmar remoção, clique em Sim.
b. Selecione a entrada
http://<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl e clique em
Remover . 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 Remover . Em
Confirmar remoção, clique em Sim.
4. Em Especificar locais dos quais os usuários podem obter uma CRL (lista de cer tificados revogados),
clique em Adicionar . A caixa de diálogo Adicionar Local é aberta.
5. Em Adicionar Local , em Local , digite e clique em
http://pki.corp.contoso.com/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl 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 em CRLs. Os clientes usam isso para encontrar os locais de CRL Delta
Incluir na extensão CDP de cer tificados emitidos
7. Em Especificar locais dos quais os usuários podem obter uma CRL (lista de cer tificados revogados),
clique em Adicionar . A caixa de diálogo Adicionar Local é aberta.
8. Em Adicionar Local , em Local , digite e clique em
 file://\\pki.corp.contoso.com\pki\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl OK. Isso retorna você
para a caixa de diálogo Propriedades da AC.
9. Na guia Extensões, marque as seguintes caixas de seleção:
Publicar CRLs neste local
Publicar CRLs Delta nesse local
10. Alterar Selecione extensão para AIA (Acesso de Informações da Autoridade) 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 Remover . Em
Confirmar remoção, clique em Sim.
b. Selecione a entrada
http://<ServerDNSName>/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt e clique em
Remover . Em Confirmar remoção, clique em Sim.
c. Selecione a entrada
file://\\<ServerDNSName>\CertEnroll\<ServerDNSName><CaName><CertificateName>.crt e clique em
Remover . Em Confirmar remoção, clique em Sim.
11. Em Especificar locais dos quais os usuários podem obter o cer tificado para essa AC, clique em
Adicionar . A caixa de diálogo Adicionar Local é aberta.
12. Em Adicionar Local , em Local , digite e clique em
http://pki.corp.contoso.com/pki/<ServerDNSName>_<CaName><CertificateName>.crt OK. Isso retorna você
para a caixa de diálogo Propriedades da AC.
13. Na guia Extensões, selecione Incluir no AIA de cer tificados 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
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este procedimento para copiar a lista de certificados revogados e Enterprise certificado de
autoridade de certificação raiz de sua autoridade de certificado para um diretório virtual no servidor Web e
para garantir que o AD CS esteja configurado corretamente. Antes de executar os comandos a seguir, certifique-
se de substituir os nomes de diretório e servidor pelos que são apropriados para sua implantação.
Para executar este procedimento, você deve ser membro de Admins . do domínio.
Para copiar a lista de certificados revogados 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 seu servidor Web, digite
copy C:\Windows\system32\certsrv\certenroll\*.crt \\WEB1\pki e pressione Enter.

Para copiar as listas de certificados revogados 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 de 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 autoridade de certificação.
Por exemplo, se o nome da sua autoridade de certificação 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 :
Cer tificado de autoridade de cer tificação
Local de AIA #1
Local de CDP #1

TIP
Se o status de qualquer item não estiver OK , faça o seguinte:
Abra o compartilhamento no servidor Web para verificar se os arquivos de lista de revogação de certificado e
certificado foram copiados com êxito para o compartilhamento. Se eles não foram copiados com êxito para o
compartilhamento, modifique os comandos de cópia com a fonte de arquivo correta e o destino de compartilhamento
e execute os comandos novamente.
Verifique se você inseriu os locais corretos para CDP e AIA na guia extensões de CA. Verifique se não há espaços extras
ou outros caracteres nos locais que você forneceu.
Verifique se você copiou a CRL e o certificado de autoridade de certificação para o local correto no servidor Web e se o
local corresponde ao local fornecido para os locais de CDP e AIA na autoridade de certificação.
Verifique se você configurou corretamente as permissões para a pasta virtual na qual o certificado de autoridade de
certificação e a CRL estão armazenados.
 Configurar o modelo de certificado do servidor
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para configurar o modelo de certificado que Active Directory ® serviços de
certificados (AD CS) usa como base para certificados de servidor registrados em servidores na sua rede.
Ao configurar esse modelo, você pode especificar os servidores por Active Directory grupo que deve receber
automaticamente um certificado de servidor do 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 de RAS, que são
membros do grupo de Ser vidores RAS e ias .
Servidores que executam o serviço de servidor de diretivas de rede (NPS) que são membros do grupo de
Ser vidores RAS e ias .
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.
Para configurar o modelo de certificado
1. Em CA1, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em autoridade de
cer tificação . O MMC (console de gerenciamento Microsoft) da autoridade de certificação é aberto.
2. No MMC, clique duas vezes no nome da autoridade de certificação, clique com o botão direito do mouse
em modelos de cer tificado 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 de ser vidor RAS e ias .
5. Clique no menu ação e, em seguida, 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 Ser vidores RAS e ias .
8. Em permissões para ser vidores RAS e ias , em permitir , verifique se o registro está selecionado e
marque a caixa de seleção registro automático . Clique em OK e feche o MMC modelos de certificado.
9. No MMC da autoridade de certificação, clique em modelos de cer tificado . No menu ação , aponte
para novo e clique em modelo de cer tificado a ser emitido . A caixa de diálogo Ativar Modelos de
Cer tificado é aberta.
10. Em habilitar modelos de cer tificado , clique no nome do modelo de certificado que você acabou de
configurar e, em seguida, clique em OK . Por exemplo, se você não alterou o nome do modelo de
certificado padrão, clique em cópia do ser vidor RAS e ias e, em seguida, clique em OK .
 Configurar o registro automático do certificado
12/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

NOTE
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 domínio raiz é o mínimo exigido
para executar este procedimento.

Configurar o registro automático do certificado do servidor

1. no computador em que o 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 em Editor de gerenciamento de
política de grupo . A caixa de diálogo selecionar política de grupo objeto é aberta.

IMPORTANT
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á registrado automaticamente em seu 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 , Configurações de segurança
e, em seguida, políticas de chave pública .
8. Clique em Diretivas de Chave Pública . No painel de detalhes, clique duas vezes em Cliente dos
Ser viços de Cer tificados - 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 cer tificados expirados, atualizar cer tificados pendentes e
remover cer tificados revogados .
c. Marque a caixa de seleção Atualizar cer tificados que usam modelos de cer tificados .
9. Clique em OK .
Configurar registro automático de certificado de usuário
1. no computador em que o 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 em Editor de gerenciamento de
política de grupo . A caixa de diálogo selecionar política de grupo objeto é aberta.

IMPORTANT
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á registrado automaticamente em seu 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 , Configurações de segurança .
8. Clique em Diretivas de Chave Pública . No painel de detalhes, clique duas vezes em Cliente dos
Ser viços de Cer tificados - 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 cer tificados expirados, atualizar cer tificados pendentes e
remover cer tificados revogados .
c. Marque a caixa de seleção Atualizar cer tificados que usam modelos de cer tificados .
9. Clique em OK .

Próximas etapas
Atualizar Política de Grupo
 Atualizar Diretiva de Grupo
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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).

NOTE
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 em Administradores , ou equivalente, é o requisito mínimo necessário para concluir este

procedimento.
Para atualizar a Diretiva de Grupo no computador local
1. no computador em que o ser vidor de diretivas de rede (NPS) está instalado, abra Windows
PowerShell ® usando o ícone na barra de tarefas.
2. no prompt de Windows PowerShell, digite gpupdate e pressione ENTER.
 Verificar registro de servidor de um certificado do
servidor
13/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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).

NOTE
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 Ferramentas e, em seguida, clique em Ser vidor 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 rede e 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 ser vidor de acesso à rede tem o valor não especificado e clique
em Avançar .
4. Em especificar condições , clique em Adicionar . em selecionar condição , clique em Windows
grupos e, em seguida, clique em adicionar .
5. Em grupos , clique em Adicionar grupos . Em selecionar grupo , digite usuários do domínio e
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 cer tificado 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.

IMPORTANT
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.

NOTE
Como você não está concluindo o assistente, a política de rede de teste não é criada no NPS.
 Implantar o - acesso sem fio autenticado 802.1 x
baseado em senha
11/08/2021 • 25 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

este é um guia complementar para o guia de rede do Windows Server ® 2016 Core. O guia de rede principal
fornece instruções para planejar e implantar os componentes necessários para uma rede totalmente funcional e
um novo Active Directory® domínio em uma nova floresta.
Este guia explica como criar uma rede principal fornecendo instruções sobre como implantar o Instituto de
engenheiros elétricos e eletrônicos do ( IEEE ) 802.1 x - acesso sem fio autenticado IEEE 802,11 usando
protocolo de autenticação extensível protegida – protocolo de autenticação de handshake de desafio da
Microsoft versão 2 ( PEAP - MS - CHAP v2 ) .
Como - o PEAP MS - CHAP v2 requer 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 dispendioso implantar do
que EAP - TLS ou PEAP - TLS.

NOTE
Neste guia, o acesso sem fio autenticado IEEE 802.1 X com PEAP - MS - CHAP v2 é abreviado como "acesso sem fio" e
"acesso WiFi".

Sobre este guia

Este guia, em combinação com os guias de pré-requisitos descritos abaixo, fornece instruções sobre como
implantar a infraestrutura de acesso WiFi a seguir.
Um ou mais pontos de - acesso sem fio 802,11 com capacidade 802.1 x compatíveis ( ) .
Active Directory Domain Services ( AD DS ) usuários e computadores.
Gerenciamento de Política de Grupo.
Um ou mais servidores NPS do servidor de políticas 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 com êxito o sem fio autenticado com este guia, você deve ter um ambiente de rede e de domínio
com todas as tecnologias necessárias implantadas. Você também deve ter certificados de servidor implantados
em seu NPSs de autenticação.
As seções a seguir fornecem links para a documentação do que mostra como implantar essas tecnologias.
Dependências de ambiente de rede e domínio
este guia foi projetado para administradores de rede e de sistema que seguiram as instruções no guia de rede
Windows Ser ver 2016 Core para implantar uma rede principal, ou para aqueles que implantaram
anteriormente as tecnologias principais incluídas na rede principal, incluindo AD DS, DNS do sistema de nomes
de domínio ( ) , protocolo ( DHCP ) , TCP / IP, NPS e Windows serviço de nome da Internet ( WINS ) .
O guia de rede principal está disponível nos seguintes locais:
o guia de rede de Windows Server 2016 Core está disponível na biblioteca técnica Windows Server
2016.
O Guia de rede principal também está disponível no formato Word na galeria do TechNet, em
https://gallery.technet.microsoft.com/Core-Network-Guide-for-9da2e683 .
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 a autenticação 802.1 X – implante sua própria infraestrutura de chave pública usando Active Directory
serviços de certificados ( AD CS ) ou use certificados de servidor registrados por uma AC de autoridade de
certificação ( pública ) .
CS DO A D

os administradores de rede e de sistema que implantam o sem fio autenticado devem seguir as instruções no
guia complementar de rede Windows Server 2016 Core, implantar cer tificados de ser vidor para
implantações 802.1 x com e sem fio . 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 do Windows Server 2016 Core implanta certificados de servidor para
implantações com e sem fio 802.1 x em formato HTML na biblioteca técnica.
CA Pública

Você pode comprar certificados de servidor de uma CA pública, como a VeriSign, 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 de autoridades de certificação raiz confiáveis. por padrão, os computadores que
executam o Windows têm vários certificados de ac pública instalados em seu repositório de certificados de
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 adquirir pontos de - acesso sem fio compatíveis com
802.1 x para fornecer cobertura sem fio nos locais desejados no seu site. A seção de planejamento deste
guia ajuda a determinar os recursos aos quais seu APs deve 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 no NPSs. Esses certificados são
necessários quando você implanta o - método de - autenticação baseado em certificado do MS CHAP v2
de PEAP - que é usado neste guia.
Um membro da sua organização está familiarizado com os padrões IEEE 802,11 que são suportados por
seus APs sem fio e os adaptadores de rede sem fio instalados nos computadores cliente e dispositivos na
sua rede. Por exemplo, alguém em sua organização está familiarizado com tipos de frequência de rádio,
802,11 autenticação sem fio ( WPA2 ou WPA ) e codificações ( AES ou TKIP ) .
O que este guia não contém
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.1 x
Como existem muitas diferenças entre marcas e modelos de - APS sem fio compatíveis com 802.1 x, este guia
não fornece informações detalhadas sobre:
Determinar qual marca ou modelo de AP sem fio é mais adequada para 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 de redes locais virtuais sem fio ( ) .
Instruções sobre como configurar - atributos específicos de 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érica que são 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 do NPS
Há duas alternativas para a implantação de 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 opções
que você enfrenta são:
comprar certificados de uma CA pública, como a VeriSign, que já são confiáveis por - clientes baseados
em Windows. Essa opção geralmente é recomendada para redes menores.
Implantar uma PKI de infraestrutura de chave pública ( ) em sua rede usando o AD CS. Isso é
recomendado para a maioria das redes, e as instruções sobre como implantar certificados de servidor
com o AD CS estão disponíveis no guia de implantação mencionado anteriormente.
Políticas de rede do NPS e outras configurações de NPS
Exceto para as definições de configuração feitas quando você executa o assistente para Configurar 802.1 x ,
conforme documentado neste guia, este guia não fornece informações detalhadas para configurar
manualmente as condições do NPS, as 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.

Visões gerais da tecnologia

Veja a seguir as visões gerais de tecnologia para a implantação de acesso sem fio:
IEEE 802.1X
O padrão IEEE 802.1 X define o - controle de acesso à rede baseado em porta usado para fornecer acesso de
rede autenticado a redes Ethernet. Esse - controle de acesso à rede baseado em porta usa as características
físicas da infraestrutura de LAN comutada para autenticar dispositivos conectados a uma porta de 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 compatíveis com 802.1 x ()
Esse cenário requer a implantação de um ou mais - APS sem fio com capacidade 802.1 x que são compatíveis
com o protocolo RADIUS de autenticação remota - no serviço do usuário ( ) .
-os APS em conformidade com 802.1 x e 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.1 x para -
usuários membros do domínio que se conectam à rede com computadores cliente sem fio que executam
Windows 10, Windows 8.1 e Windows 8. Os computadores devem ser ingressados no domínio para estabelecer
o acesso autenticado com êxito.

NOTE
você também pode usar computadores que executam o Windows Server 2016, o Windows Server 2012 R2 e o Windows
Server 2012 como clientes sem fio.

Suporte para padrões IEEE 802,11

os sistemas operacionais de servidor Windows e Windows com suporte oferecem - suporte interno para a 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 a rede sem fio 802,11, os componentes sem fio de 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 que você precisa. Por exemplo, se o adaptador de rede
sem fio não der suporte ao WPA Wi- - Fi Protected Access ( ) , você não poderá habilitar ou configurar as
opções de segurança WPA.
Os recursos do driver do adaptador de rede sem fio. Para permitir que você configure opções de rede
sem fio, o driver para o adaptador de rede sem fio deve oferecer suporte ao relatório de todos os seus
recursos para Windows. Verifique se o driver do adaptador de rede sem fio foi escrito para os recursos
do seu sistema operacional. Além disso, verifique se o driver é a versão mais atual, verificando Microsoft
Update ou o site do fornecedor do adaptador de rede sem fio.
A tabela a seguir mostra as taxas e as frequências de transmissão para os padrões sem fio IEEE 802,11 comuns.

TA XA S DE T RA N SM ISSÃ O
PA DRÕ ES F REQ UÊN C IA S DE B IT S USO

802.11 Intervalo de frequências de 2 megabits por segundo ( Obsoleto. Não comumente

ISM industrial, científico e Mbps) usado.
médico de - ( banda de ) (
2,4 a 2,5 GHz)

802.11b -ISM de Banda S 11 Mbps Normalmente usado.

802.11a ISM da Banda C - ( de 54 Mbps Normalmente, não é usado

5,725 a 5,875 GHz) devido a despesas e ao
intervalo limitado.

802.11g -ISM de Banda S 54 Mbps Amplamente usado. Os

dispositivos 802.11g são
compatíveis com
dispositivos de 802,11b.
 TA XA S DE T RA N SM ISSÃ O
PA DRÕ ES F REQ UÊN C IA S DE B IT S USO

802,11n \2.4 e 5,0 GHz
ISM da Banda C - - e da 250 Mbps Dispositivos baseados no -
Banda S padrão IEEE 802.11n pré-
2007 foram disponibilizados
em agosto de 2007. Muitos
dispositivos de 802,11n são
compatíveis com
dispositivos 802.11a, b e g.

802.11ac 5 GHz 6,93 Gbps 802.11ac, aprovado pelo

IEEE em 2014, é mais
escalonável e mais rápido
do que 802,11n e é
implantado onde os APs e
clientes sem fio são
suportados.

Métodos de segurança de rede sem fio

Os métodos de segurança de rede sem fio são um grupo informal de autenticação sem fio às vezes
chamado de segurança sem fio e criptografia de segurança sem ( ) fio. A autenticação sem fio e a criptografia
são usadas em pares para impedir que usuários não autorizados acessem a rede sem fio e protejam
transmissões sem fio.
Ao definir as 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 Abrir com 802.1X têm suporte para implantações sem fio autenticadas - 802.1X.

NOTE
Ao configurar políticas de rede sem fio, você deve selecionar WPA2 - Enterprise , WPA - Enterprise ou Abrir 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.
Wi-Fi - Acesso Protegido por Fi – Enterprise ( WPA - Enterprise ) 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 várias falhas graves que foram descobertas no protocolo WEP de Privacidade
Equivalente com ( ) Fio anterior.
O WPA - Enterprise fornece segurança aprimorada em relação ao WEP:
1. Exigir autenticação que usa a estrutura 802.1X EAP como parte da infraestrutura que garante a
autenticação mútua centralizada e o gerenciamento dinâmico de chaves
2. Aprimorando o ICV do valor de verificação de integridade com um MIC de verificação de integridade da
mensagem para proteger o ( ) ( ) header e o payload
3. Implementando um contador de quadros para desencorajar ataques de reprodução
Wi-Fi - Acesso Protegido por Fi 2 – Enterprise ( WPA2 - Enterprise ) Como o padrão WPA Enterprise, o
WPA2 Enterprise usa a estrutura - - 802.1X e EAP. O WPA2 - Enterprise fornece proteção de dados mais forte
para vários usuários e grandes redes gerenciadas. O 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 suporte a dois padrões de criptografia:
1. Protocolo de integridade da chave temporal ( A TKIP é um protocolo de criptografia mais antigo
que foi originalmente projetado para fornecer uma criptografia sem fio mais segura do que a fornecida
pelo protocolo WEP de Privacidade Equivalente com Fio ) ( ) inerentemente fraco. A TKIP foi projetada
pelo grupo de tarefas IEEE 802.11i e pela Wi Fi Alliance para substituir o WEP sem exigir a substituição do
- hardware herdado. A TKIP é um conjunto de algoritmos que encapsula o payload do WEP e permite que
os usuários de equipamentos WiFi herdado atualizem para a TKIP sem substituir o hardware. Assim
como o WEP, a 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 aquelas pelo WEP. Embora a TKIP seja útil para atualizar a segurança em
dispositivos mais antigos que foram projetados para usar apenas o WEP, ela não aborda todos os
problemas de segurança enfrentados por LANs sem fio e, na maioria dos casos, não é suficientemente
robusta para proteger transmissões confidenciais de dados corporativos ou governamentais.
2. criptografia AES ( AES ) é 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 de TKIP e WEP, o AES requer hardware sem fio que dá suporte ao padrão
AES. AES é um padrão de criptografia de chave simétrica que usa três codificações de - bloco, AES - 128,
AES - 192 e AES - 256.
No 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 - de
WPA2 Enterprise, o que é - recomendado.
1. AES - CCMP . O protocolo CCMP de protocolo Message Authentication Code de criptografia do modo de
contador implementa o padrão ( 802.11i e foi projetado para uma criptografia de segurança maior do que a
fornecida pelo WEP e usa chaves de criptografia AES de ) 128 bits.
2. AES - GCMP . O GCMP do Protocolo de Modo de Contador do AES é suportado pelo ( ) 802.11ac, é mais
eficiente do que o CCMP do AES e fornece melhor desempenho para clientes - sem fio. O GCMP usa chaves
de criptografia AES de 256 bits.

IMPORTANT
A WEP de Privacidade de Equivalência com Fio era o padrão de segurança sem fio ( ) original 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 )

AD DS fornece um banco de dados distribuído que armazena e gerencia informações sobre recursos de rede e
dados específicos do aplicativo de aplicativos - - habilitados para 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 contenção 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 AD DS é chamado de controlador de domínio.
AD DS contém as contas de usuário, contas de computador e propriedades de conta exigidas pelo IEEE 802.1X e
PEAP MS CHAP v2 para autenticar credenciais de 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 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 Gerenciamento permite o gerenciamento de configurações e alterações baseadas em diretório
de configurações de usuário e - 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 pasta, serviços de instalação remota e Internet Explorer manutenção. As Política de Grupo
configurações que você cria estão contidas em um gpo Política de Grupo objeto ( ) . 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 Editor de Gerenciamento de Política de Grupo
Console de Gerenciamento Microsoft ( ) MMC.
Este guia fornece instruções detalhadas sobre como especificar configurações na extensão Políticas de Rede
Sem Fio ( IEEE 802.11 ) do Política de Grupo Management. As Políticas de Rede Sem Fio IEEE 802.11 configuram
computadores cliente sem fio membro 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 do 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 de autoridade de certificação é uma entidade responsável por estabelecer e garantir a autenticidade de
chaves públicas que pertencem a assuntos 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.
Serviços de Certificados do Active Directory AD CS ( é uma ) função de servidor que emite certificados como
uma AC de rede. Uma AD CS de certificado, também conhecida como ( PKI ) de 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
A EAP do Protocolo de Autenticação Extensível estende a PPP do Protocolo Ponto a Ponto, permitindo métodos
de autenticação adicionais que usam trocas de credenciais e 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 a capacidade de passar mensagens EAP para NPSs. Usando o EAP, você
pode dar suporte a esquemas de autenticação adicionais, conhecidos como tipos de EAP. Os tipos de EAP com
suporte do Windows Server 2016 são:
TLS de segurança ( da camada de transporte)
Microsoft Challenge Handshake Authentication Protocol versão 2 ( MS - CHAP v2)
 IMPORTANT
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 de 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 de servidores de ( acesso à ) rede:
Pontos de acesso sem fio com capacidade para 802,1X -
Comutadores de autenticação com capacidade para 802.1X -
Computadores que Windows Server 2016 e o RAS do Serviço de Acesso Remoto configurados como
servidores VPN de rede virtual privada, servidores ( ) ( ) DirectAccess ou ambos
Computadores que executam Windows Server 2016 e Serviços de Área de Trabalho Remota
O PEAP MS CHAP v2 é mais fácil de implantar do que o TLS do EAP porque a autenticação de usuário é
executada usando o nome de usuário e a senha de credenciais baseadas em senha, em vez de certificados ou - -
cartões - - ( ) inteligentes. Somente NPS ou outros servidores RADIUS devem 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 s para usar o PEAP MS CHAP v2
para acesso ( ) - - autenticado 802.1X.
Servidor de Políticas de Rede
O NPS do Servidor de Políticas de Rede permite que você configure e gerencie centralmente políticas de rede
usando o servidor RADIUS do Serviço de Usuário discado na 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
autenticação e 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 permitirá ou negará a conexão. Isso é explicado mais detalhadamente da seguinte forma:
Autenticação
A autenticação PEAP - MS - CHAP v2 bem-sucedida tem duas partes principais:
1. O cliente autentica o NPS. Durante essa fase de autenticação mútua, o NPS envia seu certificado do
servidor para o computador cliente para que o cliente possa verificar a identidade do NPS com o
certificado. Para autenticar com êxito o NPS, 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 armazenamento
de certificados autoridades de certificação raiz confiáveis no computador cliente.
Se você implantar sua própria AC privada, o certificado de autoridade de certificação será instalado
automaticamente no armazenamento de certificados de Autoridades de Certificação 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 armazenamento de certificados autoridades
de certificação confiáveis.
2. O NPS autentica o usuário. Depois que o cliente autentica com êxito o NPS, 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 - Active Directory Domain Services ( AD DS ) .
Se as credenciais são válidas e a autenticação é bem-sucedida, o NPS inicia a fase de autorização do
processamento da solicitação de conexão. Se as credenciais não são válidas e a autenticação falha, o NPS envia
uma mensagem de Rejeição de Acesso e a solicitação de conexão é negada.
Autorização
O servidor que executa o NPS executa a autorização da seguinte forma:
1. O NPS verifica se há restrições na conta de usuário ou computador - discadas nas propriedades AD DS.
Cada conta de usuário e computador Usuários e Computadores do Active Directory inclui várias
propriedades, incluindo as encontradas na guia - Discar. Nessa guia, em Permissão de Acesso à Rede
, se o valor for Permitir acesso, o usuário ou o computador está autorizado a se conectar à rede. Se o
valor for Negar acesso , o usuário ou o computador não está autorizado a se conectar à rede. Se o valor
for Controlar o acesso por meio da Política de Rede 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. O NPS processa suas políticas de rede para encontrar uma política que corresponde à solicitação de
conexão. Se uma política de correspondência 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 são bem-sucedidas e se a política de rede correspondente concede acesso, o
NPS concede acesso à rede e o usuário e o computador podem se conectar aos recursos de rede para os quais
eles têm permissões.

NOTE
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 802.1X, os clientes sem fio devem fornecer credenciais de segurança
autenticadas por um servidor RADIUS para se conectar - à rede. Para o Protocolo de Autenticação de Handshake
do EAP PEAP Protegido da Microsoft versão [ ] - 2 [ MS - CHAP v2 , as credenciais de ] segurança são um nome
de usuário e uma senha. Para TLS de Segurança de Camada de Transporte de EAP ou - [ ] TLS PEAP, 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 é normalmente chamado de certificado do servidor.
Conforme mencionado anteriormente, você pode emitir o certificado do servidor de seus servidores RADIUS de
uma das duas maneiras: de uma AC comercial como ( VeriSign, Inc., ou de uma AC privada implantada 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 armazenamento de certificados de Autoridades de Certificação Confiáveis do
cliente, o cliente sem fio poderá validar o certificado do 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.
 NOTE
O comportamento que exige que o cliente valide o certificado do servidor pode ser desabilitado, mas desabilitar a
validação de certificado do servidor não é recomendado em ambientes de produção.

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 qual problema é encontrado ao tentar ingressar um computador sem fio
no domínio ou para que um usuário use um computador sem fio ingressado no domínio pela primeira vez para
fazer logoff - no domínio.
Para implantações nas quais o usuário ou administrador de TI não pode 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 de emissão necessário instalado em seu armazenamento 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 perfil de inicialização, para se conectar à rede sem fio.
Um perfil de inicialização remove o requisito para validar o certificado do computador do servidor RADIUS. Essa
configuração temporária permite ao usuário sem fio ingressar o computador no domínio, momento em que as
Políticas ( IEEE 802.11 de Rede Sem Fio são aplicadas e o certificado de AC 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 logoff no domínio.
Para ter 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
11/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

A ilustração a seguir mostra os componentes necessários para implantar o acesso sem fio autenticado 802.1 X
com o PEAP - MS - CHAP v2.

Componentes de implantação de acesso sem fio

A infraestrutura a seguir é necessária para esta implantação de acesso sem fio:
pontos de - acesso sem fio compatíveis com 802.1 x
Depois que os serviços de infraestrutura de rede necessários para dar suporte à sua 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, não se
esqueça de identificar se deseja fornecer o serviço sem fio fora do prédio e, nesse caso, determinar
especificamente onde estão essas áreas externas.
Determine quantos APs sem fio implantar para garantir a cobertura adequada.
Determine onde posicionar APs sem fio.
 Selecione as frequências de canal para APs sem fio.
Active Directory Domain Services
Os seguintes elementos de AD DS são necessários para a implantação de acesso sem fio.
Usuários e computadores
Use o snap Active Directory usuários e computadores - para criar e gerenciar contas de usuário e para criar um
grupo de segurança sem fio que inclua cada membro do domínio ao qual você deseja conceder acesso sem fio.
(Políticas IEEE 802,11 de rede sem fio )
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 que são aplicadas a computadores sem fio quando tentam acessar a rede.
No Editor de Gerenciamento de Política de Grupo, ao clicar com o botão direito do mouse - em ( ) políticas
IEEE 802,11 de rede sem fio , você terá as duas opções a seguir para o tipo de política sem fio que você criar.
criar uma nova política de rede sem fio para o Windows Vista e versões posteriores
criar uma nova política do Windows XP

TIP
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 de detalhes de 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ê renomear suas
políticas, a nova política sem fio do XP será sempre listada em Editor de Gerenciamento de Política de Grupo com o tipo
exibindo o XP . Outras políticas são listadas com o tipo mostrando o Vista e versões posteriores .

a diretiva de rede sem fio para Windows Vista e versões posteriores 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 que você cria na diretiva de rede sem fio são adicionados
automaticamente à configuração em seus computadores cliente sem fio aos quais a diretiva de rede sem fio se
aplica.
P e r m i t i n d o c o n e x õ e s c o m v á r i a s r e d e s se m fi o

Se você tiver clientes sem fio que são movidos entre locais físicos em sua organização, como entre um escritório
principal e uma filial, talvez você queira que os computadores se conectem a mais de uma rede sem fio. Nessa
situação, você pode configurar um perfil sem fio que contenha as configurações específicas de conectividade e
segurança 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 no escritório corporativo e na filial podem se conectar a qualquer uma das redes sem fio quando
estiverem fisicamente no alcance da área de cobertura de uma rede.
- R e d e s se m fi o d e m o d o m i st o

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ó possam usar - Enterprise WPA, enquanto dispositivos mais novos podem usar o padrão WPA2
Enterprise mais forte - .
Você pode criar dois perfis diferentes que usam o mesmo SSID e configurações de segurança e conectividade
quase idênticas.
em um perfil, você pode definir a autenticação sem fio para WPA2 - Enterprise com AES e, no outro perfil, você
pode especificar o 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 do servidor de políticas de rede ()
O NPS permite que você crie e aplique 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 os 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 o propósito deste guia, os 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 de cliente ou servidor Windows.
Computadores de servidor como clientes sem fio
por padrão, a funcionalidade de 802,11 sem fio é desabilitada em computadores que executam o 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 WLAN de LAN sem fio ( ) usando o Windows PowerShell ou o
assistente adicionar funções e recursos no Gerenciador do Servidor.
Quando você instala o recurso ser viço de L AN sem fio , o novo serviço configuração automática de
WL AN é instalado nos Ser viç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 de WLAN ao clicar em
iniciar , Windows ferramentas administrativas e ser viços .
Após a instalação e a reinicialização do servidor, o serviço de configuração automática de WLAN está em um
estado parado com um tipo de inicialização automático . Para iniciar o serviço, clique duas vezes em
configuração automática de WL AN . Na guia geral , clique em Iniciar e em OK .
O serviço de configuração automática de WLAN enumera os adaptadores sem fio e gerencia as conexões sem
fio e os perfis sem fio que contêm configurações que são 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 processo de implantação de acesso sem
fio.
 Processo da implantação de acesso sem fio
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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é-definir 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.

NOTE
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 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 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 solicitações de conexão.
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 ( IEEE 802.11 de Rede Sem Fio para se conectar automaticamente
quando o computador estiver dentro do intervalo de difusão da rede sem fio, os computadores sem fio e
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
12/08/2021 • 17 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Antes de implantar o acesso sem fio, você deve planejar os seguintes itens:
Instalação de pontos de acesso sem fio ( APS ) em sua rede
Configuração e acesso de 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 onde você deseja fornecer o serviço sem fio
3. Determinar onde você deseja localizar os APs sem fio
Além disso, você deve planejar um esquema de endereço IP para seus clientes sem fio e AP sem fio. Consulte a
seção planejar a configuração do AP sem fio no NPS abaixo para obter informações relacionadas.
Verificar o suporte a AP sem fio para padrões
Para fins de consistência e facilidade de implantação e gerenciamento de AP, é recomendável que você implante
APs sem fio da mesma marca e modelo.
Os APs sem fio que você implantar devem oferecer suporte ao seguinte:
IEEE 802.1X
Autenticação RADIUS
Autenticação e codificação sem fio. Listado na ordem mais para a menos preferível:
1. WPA2 - Enterprise com AES
2. WPA2 - Enterprise com TKIP
3. -Enterprise WPA com AES
4. -Enterprise WPA com TKIP

NOTE
Para implantar o WPA2, você deve usar adaptadores de rede sem fio e APs sem fio que também dão suporte a WPA2.
Caso contrário, use o 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. O AP sem fio deve filtrar as portas IP para evitar a transmissão de mensagens de
difusão DHCP nesses casos em que o cliente sem fio está configurado como um servidor DHCP. O AP
 sem fio deve impedir que o cliente envie pacotes IP da porta UDP 68 para a rede.
Filtragem de DNS. O AP sem fio deve filtrar as portas IP para impedir que um cliente execute como um
servidor DNS. O AP sem fio deve impedir que o cliente envie pacotes IP da porta TCP ou UDP 53 para a
rede.
Isolamento de cliente Se o ponto de acesso sem fio fornece recursos de isolamento de cliente, você
deve habilitar o recurso para impedir possíveis ( explorações de falsificação ARP do protocolo de
resolução de endereço ) .
Identificar áreas de cobertura para usuários sem fio
Use desenhos arquitetônicos de cada andar para identificar as áreas em que você deseja fornecer cobertura sem
fio. Por exemplo, identifique os escritórios apropriados, as salas de conferências, lobbies, lanchonetes ou
Courtyards.
nos desenhos, indique quaisquer dispositivos que interfiram com os sinais sem fio, como equipamentos
médicos, câmeras de vídeo sem fio, telefones sem fio que operam no 2,4 a 2,5 GHz, o alcance do ISM Industrial,
científico e médico e ( ) Bluetooth - dispositivos habilitados.
No desenho, marque aspectos da construção que podem interferir com sinais sem fio; os objetos metálicos
usados na construção de um edifício podem afetar o sinal sem fio. Por exemplo, os objetos comuns a seguir
podem interferir na propagação de sinal: Elevadors, dutos de calefação e ar- - condicionado e suporte concreto
girders.
Consulte o fabricante do seu AP para obter informações sobre fontes que podem causar atenuação de
radiofrequência 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 erros e a taxa de transferência de dados.
Determinar onde instalar APs sem fio
Nos desenhos arquitetônicos, localize seus APs sem fio perto o suficiente para fornecer uma ampla cobertura
sem fio, mas muito distante que eles não interferem uns com os outros.
A distância necessária entre os APs depende do tipo de antena AP e PA, aspectos da construção que bloqueia
sinais sem fio e outras fontes de interferência. Você pode marcar lugares de ponto de acesso sem fio para que
cada AP sem fio não tenha mais de 300 pés de qualquer AP sem fio adjacente. Consulte a documentação do
fabricante do AP sem fio para obter as especificações e diretrizes de AP para posicionamento.
Instale temporariamente os APs sem fio nos locais especificados em seus desenhos arquitetônicos. Em seguida,
usando um laptop equipado com um adaptador sem fio 802,11 e o software de pesquisa de site que
normalmente é fornecido com adaptadores sem fio, determine a intensidade do sinal dentro de cada área de
cobertura.
Em áreas de cobertura em que a intensidade do sinal é baixa, posicione o 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 arquitetônicos para indicar o posicionamento final de todos os APs sem fio. Ter um
mapa de colocação de ponto de acesso preciso ajudará mais tarde durante operações de solução de problemas
ou quando você quiser atualizar ou substituir APs.
Planejar a configuração de cliente do AP sem fio e do NPS RADIUS
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 o
APs em grupos. Para adicionar os APs como grupos de clientes RADIUS no NPS, você deve configurar o APs
com essas propriedades.
Os APs sem fio são configurados com endereços IP do mesmo intervalo de endereços IP.
 Os APs sem fio são todos configurados com o mesmo segredo compartilhado.
Planejar o uso da reconexão rápida de PEAP
Em uma infraestrutura 802.1 X, os pontos de acesso sem fio são configurados como clientes RADIUS para
servidores RADIUS. Quando o PEAP reconnect Fast é implantado, um cliente sem fio que faz roaming 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, pois a
solicitação de autenticação é encaminhada do novo ponto de acesso para o NPS que originalmente realizou a
autenticação e autorização para a solicitação de conexão do cliente.
Como o cliente PEAP e o NPS usam as propriedades de conexão TLS de segurança da camada de transporte em
cache ( ) ( , a coleção da qual é chamada de identificador TLS ) , o NPS pode determinar rapidamente que o
cliente está autorizado para uma reconexão.

IMPORTANT
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 compatíveis com 802.1 x:

NOTE
Os nomes de item podem variar de acordo com a marca e o modelo e podem ser diferentes daqueles na lista a seguir.
Consulte a documentação do AP sem fio para obter - detalhes específicos de configuração.

Identificador do conjunto de ( ser viç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ê escolher anunciar não deve corresponder ao SSID que é transmitido por qualquer rede sem fio que
esteja dentro do intervalo de recepção da sua rede sem fio.
Em 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. Em 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ê tem a necessidade de implantar diferentes redes sem fio para atender às
necessidades de negócios específicas, o AP sem fio em uma rede deve transmitir um SSID diferente do
SSID de outras redes ( ) . Por exemplo, se precisar de uma rede sem fio separada para seus funcionários e
convidados, você poderá configurar seus APs sem fio para a rede de negócios com o SSID definido como
Broadcast ExampleWL AN . Para sua rede de convidados, você pode definir cada SSID de AP sem fio para
difundir GuestWL AN . Dessa forma, seus funcionários e convidados podem se conectar à rede
pretendida sem confusão desnecessária.
 TIP
Alguns pontos de acesso sem fio têm a capacidade de difundir vários SSIDs para acomodar várias - implantações
de rede. Os pontos de acesso sem fio que podem difundir 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 que é usada quando o cliente sem fio se associa a
um ponto de acesso sem fio.
A criptografia sem fio é a codificação de criptografia de segurança usada com a autenticação sem fio para
proteger as comunicações que são enviadas entre o AP sem fio e o cliente sem fio.
Endereço IP do AP sem fio ( estático ) . Em cada AP sem fio, configure um endereço IP estático
exclusivo. Se a sub-rede for atendida por um servidor DHCP, verifique se todos os endereços IP de AP se
enquadram em 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 de 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 uma compilação
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.
Ser viço DHCP do AP . Se o AP sem fio tiver um - serviço DHCP interno, desabilite-o.
Segredo compar tilhado RADIUS . Use um segredo compartilhado RADIUS exclusivo para cada AP
sem fio, a menos que você esteja planejando configurar clientes RADIUS do NPS 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 de
comprimento, 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ório para criar seus segredos
compartilhados. É recomendável que você registre o segredo compartilhado para cada AP sem fio e
armazene-o em um local seguro, como um escritório seguro. 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
ponto de acesso virtual no NPS deve corresponder ao segredo compartilhado no AP físico real.
Endereço IP do ser vidor RADIUS . Digite o endereço IP do NPS que você deseja usar para autenticar e
autorizar solicitações de conexão a este ponto de acesso.
Por ta ( s ) UDP . Por padrão, o NPS usa as portas UDP 1812 e 1645 para mensagens de autenticação
RADIUS e portas UDP 1813 e 1646 para mensagens de contabilização RADIUS. É recomendável que você
não altere as configurações padrão de portas UDP RADIUS.
VSAs . Alguns APs sem fio exigem - atributos específicos do fornecedor ( VSAs ) para fornecer
funcionalidade completa de AP sem fio.
Filtragem de DHCP . Configure os APs sem fio para impedir que clientes sem fio enviem pacotes IP da
porta UDP 68 para a rede. Consulte a documentação do AP sem fio para configurar a filtragem de DHCP.
Filtragem de DNS . Configure os 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.1 x, você deve considerar vários - fatores
específicos do cliente:
Planejando o supor te para vários padrões .
Determine se os computadores sem fio estão usando a mesma versão do Windows ou se eles são uma
mistura de computadores que executam sistemas operacionais diferentes. Se eles forem diferentes,
verifique se você entendeu quaisquer diferenças em padrões com suporte nos sistemas operacionais.
Determine se todos os adaptadores de rede sem fio em todos os computadores cliente sem fio oferecem
suporte aos mesmos padrões sem fio ou se você precisa dar suporte a padrões variados. por exemplo,
determine se alguns drivers de hardware de adaptador de rede dão suporte a WPA2 - Enterprise e AES,
enquanto outros dão suporte apenas a WPA - Enterprise e TKIP.
Planejando o modo de autenticação do cliente . os modos de autenticação definem como Windows
clientes processam as 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. Re- - autenticaçã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 estiver conectado ao computador, a autenticação será executada usando as credenciais do
computador. Quando um usuário faz logon no 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 . Modo de autenticação de usuário especifica que a autenticação é
executada somente quando o usuário faz logon no 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 seus usuários sem fio o
mesmo nível de acesso à sua rede sem fio ou se deseja restringir o acesso para alguns dos 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 para os quais certos grupos têm permissão de acesso à rede
sem fio.
Métodos de planejamento para adicionar novos computadores sem fio . Para - computadores
com capacidade 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.1 x, as
definições de configuração sem fio serão aplicadas automaticamente depois que você configurar ( as
políticas de rede sem fio IEEE 802,11 ) no controlador de domínio e depois que política de grupo for
atualizada 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.1 x. Por exemplo,
determine se você deseja ingressar o computador no domínio usando um dos métodos a seguir.
1. Conexão o computador a um segmento da rede com fio que não está protegida pelo 802.1 x,
ingresse o computador no domínio.
2. Forneça aos seus usuários sem fio as etapas e configurações necessárias para adicionar seu
 próprio perfil de Bootstrap sem fio, o que permite que eles ingressem o computador no domínio.
3. Atribua à equipe de ti para ingressar clientes sem fio no domínio.
Planejando o suporte 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 gama 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 que você deseja dar suporte e, em seguida,
configurar vários perfis sem fio em políticas IEEE 802,11 de rede sem fio ( ) , com cada perfil especificando um
conjunto de padrões que você precisa.
por exemplo, se sua rede tiver computadores sem fio que dão suporte a WPA2 - Enterprise e aes, outros
computadores que dão suporte - a wpa Enterprise e aes e outros computadores que dão suporte somente a
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 ao qual todos os seus computadores dão suporte. nesse caso, o WPA - Enterprise e
TKIP.
Configure dois perfis para fornecer a melhor segurança possível que seja suportada por cada computador
sem fio. nessa instância, você configuraria um perfil que especifica a criptografia mais forte ( WPA2 -
Enterprise e AES ) , e um perfil que usa o WPA mais fraco - Enterprise e a criptografia TKIP. neste exemplo, é
essencial que você coloque o perfil que usa o WPA2 - Enterprise e o AES mais alto na ordem de preferência.
computadores que não são capazes de usar o WPA2 - Enterprise e AES irão pular automaticamente para o
próximo perfil na ordem de preferência e processar o perfil que especifica o WPA - Enterprise e TKIP.

IMPORTANT
Você deve posicionar o perfil com os padrões mais seguros mais altos na lista ordenada de perfis, pois a conexão de
computadores usa 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 vários níveis de acesso à rede sem fio. Por
exemplo, talvez você queira permitir que alguns usuários tenham acesso irrestrito, qualquer hora do dia, todos
os dias da semana. Para outros usuários, talvez você queira apenas permitir o acesso durante as horas
principais, de segunda-feira a sexta-feira, e negar acesso no sábado e no domingo.
Este guia fornece instruções para criar um ambiente de acesso que coloca todos os seus 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
Active Directory usuários e computadores e - faz com que todos os usuários para quem você deseja conceder
acesso sem fio a um membro desse grupo.
Ao configurar as políticas de rede do NPS, você especifica o grupo de segurança 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 vários 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 em Active Directory usuários e computadores. Por exemplo, você pode criar um grupo que
contém usuários que têm acesso completo, um grupo para aqueles que têm acesso somente durante o
horário de trabalho normal e outros grupos que se ajustam a outros critérios que correspondem às suas
necessidades.
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 que você precisa para cada grupo.
Métodos de planejamento para adicionar novos computadores sem fio
O método preferencial para unir novos computadores sem fio ao domínio e, em seguida, fazer logon no
domínio é usando uma conexão com fio a um segmento da LAN que tem acesso aos controladores de domínio
e não é protegido por um comutador Ethernet de autenticação 802.1 X.
Em alguns casos, no entanto, talvez não seja 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 o primeiro logon na tentativa 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çam logon
no domínio na 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 ti une um computador sem fio ao domínio e, em seguida,
configura um perfil sem fio de Bootstrap de logon único. Com esse método, um administrador de
ti 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 ao usuário. Quando o usuário inicia o computador,
as credenciais de domínio que eles especificam 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 Bootstrap
e, em seguida, une o domínio. Com esse método, os usuários configuram manualmente seus
computadores sem fio com um perfil sem fio de Bootstrap com base nas instruções de um administrador
de ti. O perfil sem fio de Bootstrap permite que os usuários estabeleçam uma conexão sem fio e, em
seguida, ingressem o computador no domínio. Depois de ingressar o computador no domínio e reiniciar
o computador, o usuário poderá fazer logon 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
12/08/2021 • 41 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 o 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

NOTE
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 .

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 diretrizes a seguir para ajudá-lo a escolher as frequências de canal que não entram em
conflito com outras redes sem fio na localização geográfica da sua rede sem fio.
Se houver outras organizações que têm escritórios em proximidade ou na mesma compilação de sua
organização, identifique se há alguma rede sem fio pertencente a essas organizações. Descubra as
frequências de posicionamento e de canal atribuídas de seus pontos de acesso sem fio, pois você precisa
atribuir frequências de canal diferentes ao seu AP e você precisa determinar o melhor local para instalar
o AP.
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 quaisquer dois APs sem fio com cobertura sobreposta sejam
atribuídos a frequências de canal diferentes.
Configurar APs sem fio
Use as informações a seguir junto com a documentação do produto fornecida pelo fabricante do AP sem fio
para configurar seus APs sem fio.
Este procedimento enumera os itens normalmente configurados em um AP sem fio. Os nomes de item podem
variar de acordo com a marca e o modelo e podem ser diferentes daqueles na lista a seguir. Para obter detalhes
específicos, consulte a documentação do AP sem fio.
Para configurar seus APs sem fio
SSID . Especifique o nome da rede sem fio ( s ) ( , por exemplo, ExampleWLAN ) . Esse é o nome
anunciado para clientes sem fio.
Criptografia . especifique WPA2 - Enterprise ( ) Enterprise preferencial ou WPA - e codificação de ( )
criptografia TKIP ou preferencial AES, dependendo de quais versões são suportadas pelos adaptadores de
rede do computador cliente sem fio.
Endereço IP do AP sem fio ( estático ) . Em cada ponto de acesso, configure um endereço IP estático
exclusivo que esteja dentro do intervalo de exclusão do escopo do DHCP para a sub-rede. O uso de um
endereço excluído da atribuição por 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 o 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 que dê suporte a esse recurso, insira
um nome exclusivo para a resolução DNS.
Ser viço DHCP . Se o AP sem fio tiver um - serviço DHCP interno, desabilite-o.
Segredo compar tilhado 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 o APs por grupo no NPS, o segredo compartilhado deve ser o mesmo para todos
os membros do grupo. Além disso, cada segredo compartilhado que você usa deve ser uma sequência
aleatória de pelo menos 22 caracteres que combina 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órios encontrado no Assistente para Configurar o 802.1 x do NPS, para
criar os segredos compartilhados.

TIP
Registre o segredo compartilhado para cada AP sem fio e armazene-o em um local seguro, como um escritório seguro.
Você deve saber o segredo compartilhado para cada AP sem fio ao configurar clientes RADIUS no NPS.

Endereço IP do ser vidor RADIUS . Digite o endereço IP do servidor que executa o NPS.
Por ta ( 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 de contabilidade. É 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 o NPSs não estiverem
configurados com as mesmas portas UDP, o NPS não poderá receber ou processar solicitações de
conexão do APs, e todas as tentativas de conexão sem fio na rede falharão.
VSAs . Alguns APs sem fio exigem - atributos específicos do fornecedor ( VSAs ) para fornecer
funcionalidade completa de AP sem fio. Os VSAs são adicionados à política de rede do NPS.
Filtragem de DHCP . Configure APs sem fio para impedir que clientes sem fio enviem pacotes IP da
porta UDP 68 para a rede, conforme documentado pelo fabricante do AP sem fio.
Filtragem de 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 do 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, em seguida, adicione
usuários ao grupo de segurança usuários sem fio apropriados:
Criar um grupo de segurança de usuários sem fio
Adicionar usuários ao grupo de segurança sem fio
Criar um grupo de segurança de usuários sem fio
Você pode usar este procedimento para criar um grupo de segurança sem fio no snap-in Active Directory
usuários e computadores ( MMC do console de gerenciamento Microsoft ) - .
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
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
Director y . O snap-in Active Directory usuários e computadores - é 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 a eles permissões de acesso e regras de
conectividade diferentes.
Adicionar usuários ao grupo de segurança usuários sem fio
Você pode usar este procedimento para adicionar um usuário, computador ou grupo ao seu grupo de
segurança sem fio no snap-in Active Directory usuários e computadores console de gerenciamento Microsoft (
MMC ) - .
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
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
Director y . 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 o 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, em seguida, conclua um dos procedimentos a seguir para
adicionar um computador ou adicionar um usuário ou grupo.
P a r a a d i c i o n a r u m u su á r i o o u g r u p o

1. Em Inserir 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 adic ion ar u m c om pu t ador

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. Em Inserir 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 a rede sem fio ( IEEE 802,11 ) políticas política de grupo extensão:
Abrir ou adicionar e abrir um objeto Política de Grupo
Ativar as 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 de gerenciamento de Política de Grupo é instalado em computadores que executam o
Windows Server 2016 quando a função de servidor do Active Directory Domain Services ( AD DS ) está
instalada e o servidor é configurado como um controlador de domínio. O procedimento a seguir descreve como
abrir o Console de Gerenciamento de Política de Grupo ( GPMC ) no controlador de domínio. Em seguida, o
procedimento descreve como abrir um - nível de domínio existente política de grupo ( GPO ) de objeto para
edição ou criar um novo GPO de domínio e abri-lo para edição.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
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,
em seguida, clique em gerenciamento de Política de Grupo . O Console de Gerenciamento de Política
de Grupo é aberto.
2. No painel esquerdo, clique duas vezes - em sua 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 de 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 . Editor de gerenciamento de política de grupo é aberto.
Para criar um novo objeto de 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 de política de grupo e,
em seguida, clique em criar um GPO nesse 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 .
Editor de gerenciamento de política de grupo é aberto.
Na próxima seção, você usará Editor de Gerenciamento de Política de Grupo para criar a política sem fio.
Ativar as políticas padrão de rede sem fio ( IEEE 802,11 )
Este procedimento descreve como ativar as políticas IEEE 802,11 de rede sem fio padrão ( ) usando o editor de
gerenciamento de política de grupo ( GPME ) .

NOTE
depois de ativar a versão Windows Vista e versões posteriores das políticas IEEE 802,11 da rede sem fio ( ) ou da
versão Windows XP , a opção versão será automaticamente removida da lista de opções quando você clicar com o
botão direito do mouse - em rede sem fio ( ) políticas IEEE 802,11 . Isso ocorre porque depois de selecionar uma
versão de 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, quando a versão da
política sem fio retorna ao menu de clique com o botão direito do mouse em - ( ) políticas IEEE 802,11 de rede sem
fio no GPME. Além disso, as políticas sem fio são listadas apenas no painel detalhes do GPME quando o nó ( ) políticas
IEEE 802,11 de rede sem fio está selecionado.

A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste

procedimento.
Para ativar as políticas padrão de rede sem fio ( IEEE 802,11 )
1. Siga o procedimento anterior para abrir ou adicionar e abrir um política de grupo objeto para
abrir o GPME.
2. no GPME, no painel esquerdo, clique duas vezes - em configuração do computador , clique duas vezes
em - políticas , clique duas vezes - em Windows Configurações e, em seguida, clique duas vezes - em
segurança Configurações .
3. em Configurações de segurança , clique com o botão direito do mouse - em rede sem fio ( ) políticas
IEEE 802,11 e clique em criar uma nova política sem fio para o Windows Vista e versões
posteriores .

4. A caixa de diálogo Propriedades da nova diretiva de rede sem fio é aberta. Em 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 a configuração de política, a ordem de preferência de processamento de
política e as 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 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.
P a r a c o n fi g u r a r u m p e r fi l d e c o n e x ã o se m fi o p a r a P E A P - M S - C H A P v 2

1. No GPME, na caixa de diálogo Propriedades da rede sem fio para a política que você acabou de criar, na
guia geral e em Descrição , digite uma breve descrição para a política.
2. para especificar que a configuração automática de wlan é usada para definir as configurações do
adaptador de rede sem fio, verifique se usar Windows ser viço de configuração automática de
wlan para clientes está selecionado.
3. em Conexão às 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 perfil de WL AN example.com para Windows
 10 .
5. Em nome da rede ( s ) ( SSID ) , 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 aps sem fio configurado para usar
WPA2 - Enterprise e AES e outro grupo de aps sem fio para usar WPA - Enterprise e TKIP, configure um
perfil para cada grupo de aps 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 .

NOTE
Habilitar essa opção pode criar um risco de segurança, pois 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 do 802.1 X são impostas, os valores padrão para as -
mensagens de início EAPOL máximas , o período de retenção , o período de início e o
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 o AP sem fio estiver configurado para pré-autenticação - , selecione esta
rede usa pré- - autenticação .
9. Para especificar que as comunicações sem fio atendam aos padrões FIPS 140 - 2, selecione executar
criptografia no - modo cer tificado do FIPS 140 2 .
10. Clique em OK para retornar à guia segurança . em selecionar os métodos de segurança para esta
rede , em autenticação , selecione WPA2 - Enterprise se ele tiver suporte do AP sem fio e adaptadores
de rede de cliente sem fio. Caso contrário, selecione WPA - Enterprise .
11. Em criptografia , se houver suporte para o AP sem fio e adaptadores de rede de cliente sem fio,
selecione AES-CCMP . Se você estiver usando pontos de acesso e adaptadores de rede sem fio que dão
suporte a AC 802.11, selecione AES-GCMP . Caso contrário, selecione TKIP .
 NOTE
As configurações para autenticação e criptografia devem corresponder às configurações definidas em seus APS
sem fio. As configurações padrão para o modo de autenticação , as falhas de autenticação máxima e as
informações de usuário de cache para conexões subsequentes com essa rede são suficientes para
implantações sem fio típicas.

12. Em selecionar um método de autenticação de rede , selecione EAP ( PEAP ) protegido e clique
em Propriedades . A caixa de diálogo Propriedades EAP protegidas é aberta.
13. Em Propriedades EAP protegidas , confirme que Verifique se a identidade do ser vidor
Validando o cer tificado está selecionada.
14. Em autoridades de cer tificação raiz confiáveis , selecione a AC da autoridade de certificação raiz
confiável ( ) que emitiu o certificado do servidor para o NPS.

NOTE
Essa configuração limita as ACs raiz que os clientes confiam para as ACs selecionadas. Se nenhuma AC raiz
confiável for selecionada, os clientes confiarão em todas as CAs raiz listadas em seu repositório de certificados de
autoridades de certificação raiz confiáveis.

15. Na lista selecionar método de autenticação , selecione EAP de senha segura ( - MS - CHAP ) v2 .
16. Clique em Configurar . na caixa de diálogo propriedades EAP MSCHAPv2 , verifique se usar
automaticamente meu nome de logon do Windows e senha ( e ) domínio, se houver algum
selecionado, e clique em OK .
17. Para habilitar a reconexão rápida de PEAP, verifique se habilitar reconexão rápida está selecionado.
18. Para exigir TLV de cryptobinding de servidor em tentativas de conexão, selecione desconectar se o
ser vidor não apresentar TLV de cr yptobinding .
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.

[! REGISTRA
A política do NPS para 802.1 X sem fio deve ser criada usando a política de solicitação de
conexão do NPS. Se a política de NPS for criada usando a política de rede do 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 de cliente. A identidade real — usada para autenticação — é enviada
durante a segunda fase da autenticação, dentro do túnel seguro que é estabelecido na primeira
fase. Se a caixa de seleção Habilitar Privacidade de identidade estiver marcada, o nome de
usuário será substituído pela entrada especificada na caixa de texto. Por exemplo, suponha que
Habilitar Privacidade de identidade esteja selecionado e que o alias de privacidade de
identidade anônimo seja especificado na caixa de texto. Para um usuário com um alias de
identidade real jdoe@example.com , a identidade enviada na primeira fase de autenticação será
alterada para anonymous@example.com . A parte do 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
diferentes escolhas para personalizar cada perfil para os clientes sem fio e a rede para a qual você deseja
aplicar o perfil. Quando terminar de adicionar perfis, clique em OK para fechar a caixa de diálogo
Propriedades da diretiva de rede sem fio.
Na próxima seção, você pode ordenar os perfis de política para garantir a segurança ideal.
Definir a ordem de preferência para perfis de conexão sem fio
Você pode usar este procedimento se tiver criado vários perfis sem fio em sua política de rede sem fio e desejar
solicitar os perfis para obter a eficácia e a segurança ideais.
Para garantir que os clientes sem fio se conectem com o nível mais alto de segurança que eles podem dar
suporte, coloque suas políticas mais restritivas na parte superior da lista.
Por exemplo, se você tiver dois perfis, um para clientes que dão suporte a WPA2 e outro para clientes que dão
suporte a WPA, coloque o perfil WPA2 mais alto na lista. Isso garante que os clientes que dão suporte a WPA2
usarão 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.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
P a r a d e fi n i r a o r d e m d e p r e fe r ê n c i a p a r a p e r fi s d e c o n e x ã o se m fi o

1. No GPME, na caixa de diálogo Propriedades da rede sem fio para a política que você acabou de
configurar, clique na guia geral .
2. na guia geral , em Conexão às 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 no botão "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 as configurações na guia permissões de rede para os membros do domínio aos quais ( as
diretivas IEEE 802,11 de rede sem fio ) se aplicam.
Você só pode aplicar as seguintes configurações para redes sem fio que não estão configuradas na guia geral
da 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
identificador de conjunto de serviços ( SSID)
Permitir ou negar conexões a redes ad hoc
Permitir ou negar conexões a redes de infraestrutura
Permitir ou negar que os usuários exibam tipos de rede ( ad hoc ou infraestrutura ) à qual o acesso foi
negado
Permitir ou negar que os usuários criem um perfil que se aplica a todos os usuários
Os usuários só podem se conectar a redes permitidas usando perfis de Política de Grupo
A associação em Admins . do domínio, ou equivalente, é o mínimo necessário para concluir esses
procedimentos.
P a r a p e r m i t i r o u n e g a r c o n e x õ e s a r e d e s se m fi o e sp e c í fi c a s

1. No GPME, na caixa de diálogo Propriedades da 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 nome da rede ( SSID ) , digite o SSID
da rede para o qual você deseja definir permissões.
4. Em tipo de rede , selecione infraestrutura ou ad hoc .

NOTE
Se você não tiver certeza se a rede de difusão é uma infraestrutura ou rede ad hoc, você pode 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 .
P a r a e sp e c i fi c a r p e r m i ssõ e s d e r e d e a d i c i o n a i s ( o p c i o n a i s)

1. Na guia permissões de rede , configure um ou todos os itens a seguir:

Para negar acesso de membros de domínio a redes ad hoc, selecione impedir conexões com -
redes ad hoc .
Para negar o acesso de membros de domínio a redes de infraestrutura, selecione impedir
conexões a redes de infraestrutura .
Para permitir que os membros do domínio exibam tipos de rede ( ad hoc ou infraestrutura ) às
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 de Política
de Grupo, selecione usar somente perfis de política de grupo para redes permitidas .

Configurar seu NPSs

Siga estas etapas para configurar o NPSs para executar a autenticação 802.1 X para acesso sem fio:
Registrar o NPS no Active Directory Domain Services
Configurar um AP sem fio como um cliente RADIUS NPS
Criar políticas de NPS para 802.1 X sem fio usando um assistente
Registrar o NPS no Active Directory Domain Services
Você pode usar este procedimento para registrar um servidor que esteja executando ( o NPS do servidor de
políticas de rede ) no Active Directory Domain Services ( AD DS ) no domínio em que o NPS é membro. Para
que o NPSs receba permissão para ler as - Propriedades de discagem de contas de usuário durante o processo
de autorização, cada NPS deve ser registrado em AD DS. O registro de um NPS adiciona o servidor ao grupo de
segurança Ser vidores RAS e ias em AD DS.
 NOTE
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, caso ainda não tenha feito isso:

Install-WindowsFeature NPAS -IncludeManagementTools

A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para registrar um NPS em seu domínio padrão
1. No seu NPS, em Gerenciador do ser vidor , clique em ferramentas e em ser vidor de políticas de
rede . O snap- - in do NPS é aberto.
2. Clique com o botão direito do mouse - em NPS ( local ) e clique em registrar ser vidor em Active
Director y . A caixa de diálogo Ser vidor de Políticas de Rede é aberta.
3. Em Ser vidor de Políticas de Rede , clique em OK e em OK novamente.
Configurar um AP sem fio como um cliente RADIUS NPS
Você pode usar este procedimento para configurar um AP, também conhecido como um servidor de acesso à
rede ( nas ), como um cliente RADIUS de autenticação remota - no serviço ( do usuário ) usando o snap-in do
NPS - .

IMPORTANT
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, - switches compatíveis com 802.1 x, servidores VPN de rede privada virtual ( ) e servidores de dial - -up
— porque usam o protocolo RADIUS para se comunicar com servidores RADIUS, como o NPSs.

A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para adicionar um servidor de acesso à rede como um cliente RADIUS no NPS
1. No seu NPS, em Gerenciador do ser vidor , clique em ferramentas e em ser vidor de políticas de
rede . O snap- - in do NPS é aberto.
2. No snap-in do NPS - , - clique duas vezes em clientes e ser vidores RADIUS . 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 este cliente RADIUS está
marcada.
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 de 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 do nome de domínio totalmente
qualificado ( ) para o nas.
Se você inserir o FQDN, para verificar se o nome está correto e é mapeado 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 esse host não é conhecido. Se isso ocorrer, verifique se você tem o nome do AP correto e
se o AP está ligado e conectado à rede.
Clique em OK para fechar verificar endereço .
6. Em novo cliente RADIUS , em segredo compar tilhado , siga um destes procedimentos:
Para configurar manualmente um segredo compartilhado RADIUS, selecione manual e, em
segredo compar tilhado , digite a senha forte que também é inserida no nas. Digite novamente o
segredo compartilhado em confirmar segredo compar tilhado .
Para gerar automaticamente um segredo compartilhado, marque a caixa de seleção Gerar e clique
no botão Gerar. Salve o segredo compartilhado gerado e, em seguida, use esse valor para
configurar o NAS para que ele possa se comunicar com o NPS.

IMPORTANT
O segredo compartilhado RADIUS que você inscreva para suas AP virtuais no NPS deve corresponder
exatamente ao segredo compartilhado RADIUS configurado nas AP's 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, em Nome do fornecedor, especifique o nome do

fabricante do NAS. Se você não tiver certeza do nome do fabricante do NAS, selecione PADRÃO
RADIUS.
8. 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 Message - Authenticator .
9. Clique em OK . O 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 este 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 com capacidade 802.1X como clientes RADIUS do Serviço
de Usuário de Autenticação Remota no servidor RADIUS que executam o NPS do Servidor de Políticas 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

NOTE
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 autenticado 802.1X.

A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Criar políticas para 802.1X sem fio autenticado 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. No Ponto de Par tida , em Configuração Padrão , selecione Servidor RADIUS para 802.1X Conexões
sem fio ou com fio. O texto e os links abaixo do texto mudam para refletir sua seleção.
3. Clique em Configurar 802.1X. O assistente Configurar 802.1X é aberto.
4. Na página do 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 Próximo .
5. Na página do assistente Especificar comutadores 802.1X, em clientes RADIUS, todas as opções
802.1X e os 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, em Novo cliente RADIUS, insira as informações ( ) para: Nome
amigável, IP de endereço ou ( DNS ) e Segredo Compartilhado .
Para modificar as configurações de qualquer NAS, em clientes RADIUS, selecione o AP para o
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 .

WARNING
A remoção de 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 feitas no assistente Configurar 802.1X
para clientes RADIUS são refletidas no snap-in NPS, no nó Clientes RADIUS em Clientes - NPS RADIUS e /
Ser vidores . Por exemplo, se você usar o assistente para remover uma opção 802.1X, a opção também
será removida do snap-in do - NPS.

6. Clique em Próximo . 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 , selecione Microsoft: EAP ( PEAP ) protegido e
clique em Configurar .

TIP
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 tiver configurado o 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 NPS no Active Directory Domain Services e, em seguida, use as seguintes etapas para atualizar o Política
de Grupo: Clique em Iniciar , clique em Windows System , clique em Executar e em Abrir , digite gpupdate e
pressione ENTER. Quando o comando retornar resultados indicando que o usuário e o computador Política de
Grupo foram atualizados com êxito, selecione Microsoft: EAP ( ) PEAP protegido novamente e clique em
Configurar .
Se, depois de atualizar o 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 atenderá aos requisitos mínimos de certificado do servidor, conforme documentado no Guia
principal do Companion Network: Deploy Server Certificates for 802.1X Wiredand Wireless Deployments . Se isso
acontecer, você deverá descontinuar a configuração do NPS, revogar o certificado emitido para o NPS e, em
seguida, seguir as instruções para configurar um novo certificado usando o guia de implantação de ( ) certificados
do servidor.

7. Na página editar propriedades de EAP protegidas do assistente, em Certificado emitido, verifique se

o certificado NPS correto está selecionado e, em seguida, faça o seguinte:
 NOTE
Verifique se o valor em Emissor está correto para o certificado selecionado em Cer tificado emitido. Por
exemplo, o emissor esperado para um certificado emitido por uma AC que executa Serviços de Certificados do
Active Directory ( AD CS ) chamado corp\DC1, no domínio contoso.com, é corp - DC1 - CA .

Para permitir que os usuários percorrem o roam com seus computadores sem fio entre pontos de
acesso sem exigir que eles se autenticem novamente 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 cryptobinding Type - - Length Value ( TLV ) , selecione
Desconectar Clientes sem Criptografia .
Para modificar as configurações de política para o tipo de EAP, em Tipos de EAP, clique em Editar ,
em Propriedades de EAP MSCHAPv2 , modifique as configurações conforme necessário e clique
em OK.
8. Clique em OK . A caixa de diálogo Editar Propriedades de EAP Protegidas é fechado, retornando você para
o assistente Configurar 802.1X. Clique em Próximo .
9. Em Especificar Grupos de Usuários , clique em Adicionar e digite o nome do grupo de segurança que
você configurou para seus clientes sem fio no Usuários e Computadores do Active Directory - snap-in.
Por exemplo, se você nomeou o grupo de segurança sem fio Grupo Sem Fio, digite Grupo Sem Fio .
Clique em Próximo .
10. Clique em Configurar para configurar atributos padrão RADIUS e atributos específicos do fornecedor
para a VLAN da LAN virtual conforme necessário e, conforme especificado pela documentação fornecida
pelo fornecedor de hardware de AP sem - ( ) fio. Clique em Próximo .
11. Revise os detalhes do resumo da configuração e clique em Concluir .
Suas políticas NPS agora são criadas e você pode passar para a junção de computadores sem fio ao domínio.

Ingressar novos computadores sem fio no 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 computação ( 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ê tiver implantado sua própria PKI, o computador receberá o
certificado de autoridade de certificação e o colocará no armazenamento de certificados autoridades de
certificação 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 é ingressado no domínio, o método preferencial
para os usuários fazer logoff no domínio é executar logoff 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 IT. Um membro da equipe de IT insinuou um computador
sem fio no domínio e configura um perfil sem fio de inicialização de login único. Com esse método, o
administrador de IT 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 logoff usando o método de
configuração de computador da equipe de IT
Inicializar configuração de perfil sem fio por usuários. O usuário configura manualmente o
computador sem fio com um perfil sem fio de inicialização e entra no domínio, com base nas instruções
adquiridas de um administrador de IT. O perfil sem fio de inicialização permite que o usuário estabeleça uma
conexão sem fio e, em seguida, insinue no 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 obter mais informações, consulte a seção Ingressar no domínio e fazer logon usando a configuraçãode
perfil sem fio de inicialização por usuários.
Ingressar no domínio e fazer logoff usando o método de configuração do computador da equipe de IT
Os 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 - 802.1X sem se conectar primeiro à
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 do domínio e não valide o certificado do servidor RADIUS do Serviço de Usuário discado na
autenticação remota executando o NPS do 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 de conta de usuário e
computador 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 login ú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 v2e use as seguintes configurações:
Autenticação PEAP - MS - CHAP v2
Validar certificado do servidor RADIUS desabilitado
Single Sign On enabled
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, unidade flash USB ou outro local facilmente acessível. O perfil é salvo como
um arquivo *.xml no local especificado.
3. Adicione o novo computador sem fio ao domínio, por exemplo, por meio de uma conexão Ethernet que
não exige autenticação IEEE 802.1X e adicione o perfil sem fio de inicialização ao computador usando o
comando ( ) netsh wlan add profile.
 NOTE
Para obter mais informações, consulte Comandos Netsh para WLAN de rede local sem fio em ( ) http: / /
technet.microsoft.com biblioteca / / dd744890.aspx.

4. Distribua o novo computador sem fio para o usuário com o procedimento para "Fazer logoff no domínio
usando computadores que executam Windows 10".
Quando o usuário inicia o computador, Windows solicita que o usuário insira seu nome de conta de usuário de
domínio e senha. Como o Logom Único está habilitado, o computador usa as credenciais da conta de usuário do
domínio para estabelecer primeiro uma conexão com a rede sem fio e, em seguida, fazer logoff no domínio.
Faça logoff no domínio usando computadores que executam Windows 10
1. Faça logoff do computador ou o reinicie.
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 logoff com
a conta de usuário local.
3. No canto inferior esquerdo da tela, clique em Outro Usuário. A tela Outro Usuário faz logoff 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
example.com, o texto lerá Entrar em: EXEMPLO.
4. Em Nome de usuário, digite o nome de usuário do domínio.
5. Em Senha , digite sua senha do domínio e clique na seta ou pressione ENTER.

NOTE
Se a tela Outro Usuário não incluir o texto Entrar em: e seu nome de domínio, insira seu nome de usuário no formato
usuário do \ domínio. Por exemplo, para fazer logoff no domínio example.com com uma conta chamada Usuário - 01 ,
digite o exemplo De usuário \ - 01 .

Ingressar no domínio e fazer logon usando a configuração de perfil sem fio de inicialização por usuários
Com esse método, você conclui as etapas na seção Etapas gerais e, em seguida, 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, insinue no domínio. Depois que o computador for ingressado no domínio e reiniciado, o usuário
poderá fazer logoff no domínio por meio de uma conexão sem fio.
Etapas gerais
1. Configure uma conta de administrador de computador local, Painel de Controle , para o usuário.

IMPORTANT
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 ingressar o computador no
domínio, o usuário será solicitado a solicitar o nome de usuário e a senha das credenciais da conta ( de ) domínio.

2. Forneça aos usuários do 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 o nome de usuário e a senha das credenciais do computador local e o
nome da conta de usuário do domínio e a senha do domínio no formato ( ) ( ) \ 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 profissionais de suporte de IT para fazer
logoff 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 Central
de Rede e Compar tilhamento . A Central de Rede e Compar tilhamento 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 em Conectar-se manualmente a uma rede sem fio e clique em Próximo.
4. Em Conectar-se manualmente a uma rede sem fio , em Nome da rede , digite o nome SSID do AP.
5. Em Tipo de segurança, selecione a configuração fornecida pelo administrador.
6. Em Tipo de criptografia e Chave de Segurança, selecione ou digite as configurações fornecidas pelo
administrador.
7. Selecione Iniciar essa conexão automaticamente e clique em Próximo.
8. Em Adicionado com êxito o SSID de Rede, clique em Alterar configurações de conexão .
9. Clique em Alterar configurações de conexão . A caixa de diálogo Sua propriedade rede sem fio SSID
de rede é aberta.
10. Clique na guia Segurança e, em Escolher um método de autenticação de rede, selecione PEAP de
EAP ( protegido. )
11. Clique em Configurações . A página Propriedades peap de EAP ( ) protegida é aberta.
12. Na página Propriedades ( peap ) de EAP protegidas, verifique se Validar certificado do servidor 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 forma: Nome de Usuário do Nome de
Domínio , Senha de Domínio. \
P a r a i n g r e ssa r u m c o m p u t a d o r n o d o m í n i o

1. Faça logon no computador com a conta de Administrador local.

2. Na caixa de texto de pesquisa, digite PowerShell . Nos resultados da pesquisa, clique com o botão
direito Windows PowerShell e clique em Executar como administrador. Windows PowerShell abre
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 seu nome de usuário de domínio e senha e clique em OK.
5. Reinicie o computador.
6. Siga as instruções na seção anterior Fazer logoff no domínio usando computadores que executam
Windows 10.
 Implantar o modo Cache Hospedado do
BranchCache
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

o guia de rede Windows Server 2016 Core fornece instruções para planejar e implantar os componentes
principais necessários para uma rede totalmente funcional e um novo ® domínio de Active Directory em uma
nova floresta.
este guia explica como criar a 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 somente leitura em que os
computadores cliente estão executando o Windows ® 10, Windows 8.1 ou Windows 8 e ingressaram no
domínio.

IMPORTANT
não use este guia se você estiver planejando implantar ou já tiver implantado um servidor de cache hospedado do
BranchCache que esteja 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.

Este guia contém as seções a seguir.

Pré-requisitos para usar este guia
Sobre este guia
O que este guia não contém
Visões gerais da tecnologia
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

Pré-requisitos para usar este guia

este é um guia complementar para o guia de rede Windows Server 2016 Core. 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.
 NOTE
o guia de rede de Windows Server 2016 Core está disponível na biblioteca técnica Windows Server 2016.

implante os 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 data center
de nuvem. Para obter informações sobre como implantar servidores de conteúdo do BranchCache,
consulte recursos adicionais.
Estabeleça conexões WAN de rede de longa distância ( ) entre sua filial, seu escritório principal e, se
apropriado, seus recursos de nuvem, usando uma VPN de rede virtual privada ( , o ) DirectAccess ou
outro método de conexão.
Implante computadores cliente em sua filial que executam um dos sistemas operacionais a seguir, que
fornecem ao BranchCache suporte para Serviço de Transferência Inteligente em Segundo Plano (BITS),
protocolo HTTP e SMB (bloco de mensagens de servidor).
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
O Windows 8 Enterprise

NOTE
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 - Windows 8 Pro, somente suporte a BITS

Sobre este guia

este guia foi projetado para administradores de rede e de sistema que seguiram as instruções no guia de rede
Windows Server 2016 core ou no guia de rede Windows Server 2012 core 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 do serviço ( de nome de domínio ) , DHCP do protocolo de
configuração de Host dinâmico ( ) 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.

O que este guia não contém

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 executam o
Windows 7. se tiver computadores cliente que executam o Windows 7 em suas filiais, você deverá configurá-los
usando procedimentos diferentes daqueles fornecidos neste guia para computadores cliente que estão
executando o 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 que os computadores
cliente confiam. (se todos os seus computadores cliente estiverem executando Windows 10, Windows 8.1 ou
Windows 8, você não precisará configurar o servidor de cache hospedado com um certificado de servidor.)

IMPORTANT
se seus servidores de cache hospedados estiverem 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 configurações de Política de Grupo descritas nesse guia a todos os clientes do BranchCache que
estão executando versões do Windows de Windows 7 a Windows 10. computadores que executam o Windows Server
2008 R2 não podem ser configurados usando as etapas deste guia.

Visões gerais da tecnologia

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 o AD DS no Windows Server 2016, Windows Server 2012 R2
ou Windows Server 2012.
BranchCache
o BranchCache é uma tecnologia de otimização de largura de banda de WAN (rede de longa distância) 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 WAN quando os usuários acessam o conteúdo em servidores remotos, o
BranchCache baixa o conteúdo solicitado pelo cliente do seu escritório principal ou de seus servidores de
conteúdo de nuvem hospedado e armazena em cache o conteúdo em locais de filiais, permitindo que outros
computadores cliente em filiais acessem o mesmo conteúdo localmente, e não pela 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 de hash e pré-
carregado de seus - servidores de conteúdo baseados em servidor de arquivos e Web.
Política de Grupo
Política de Grupo no Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012 é uma
infraestrutura usada para fornecer e aplicar uma ou mais configurações ou definições de política desejadas a
um conjunto de usuários e computadores de destino em um ambiente de Active Directory.
Essa infraestrutura consiste em um mecanismo de Política de Grupo e várias - extensões do lado do cliente (
CSEs ) que são responsáveis por ler as configurações de política nos 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
10/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

Você pode usar este guia para implantar um servidor de cache hospedado do BranchCache em uma filial em
que 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.
Esta visão geral inclui a infraestrutura do BranchCache de que você precisa, bem como uma visão geral passo a
passo simples de implantação.

Infraestrutura de implantação do servidor de cache hospedado

nessa implantação, o servidor de cache hospedado é implantado usando pontos de conexão de serviço no
Active Directory Domain Services ( AD DS ) , e você tem a opção com o BranchCache no Windows Server 2016,
Windows Server 2012 R2 e Windows Server 2012, para prearmazenar o conteúdo compartilhado em
servidores de conteúdo baseados na Web e em arquivos e, em seguida, 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.

IMPORTANT
Embora essa implantação descreva os servidores de conteúdo em uma nuvem data center, você pode usar este guia para
implantar um servidor de cache hospedado do BranchCache, independentemente de onde você implanta seus servidores
de conteúdo – em seu escritório principal ou em um local de nuvem.

HCS1 na filial
Você deve configurar este computador como um servidor de cache hospedado. Se você optar por fazer o hash
de dados do servidor de conteúdo para poder pré-carregar o conteúdo em seus servidores de cache
hospedados, poderá importar pacotes de dados que contêm o conteúdo de seus servidores Web e de arquivos.
WEB1 na nuvem data center
WEB1 é um - servidor de conteúdo habilitado para BranchCache. Se você optar por prefazer o hash de dados do
servidor de conteúdo para poder pré-carregar o conteúdo em seus servidores de cache hospedados, você
poderá prearmazenar o conteúdo compartilhado em WEB1 e, em seguida, criar um pacote de dados que você
copia para o HCS1.
FILE1 na nuvem data center
FILE1 é um - servidor de conteúdo habilitado para BranchCache. Se você optar por prefazer o hash de dados do
servidor de conteúdo para poder pré-carregar o conteúdo em seus servidores de cache hospedados, você
poderá prefazer o hash do conteúdo compartilhado no ARQUIVO1 e, em seguida, criar um pacote de dados que
você copia para 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 tiverem Política de Grupo atualizados e essa configuração de
política for aplicada, ele automaticamente localiza e começa 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 de Política de
Grupo do BranchCache e para 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
NOTE
Os detalhes de como executar essas etapas são fornecidos na seção implantação do modo de cache hospedado do
BranchCache.

O processo de implantação de um servidor de cache hospedado do BranchCache ocorre nestes estágios:

NOTE
Algumas das etapas a seguir são opcionais, como as etapas que demonstram como prehash e pré-carregamento de
conteúdo em servidores de cache hospedados. Quando você implanta o BranchCache no modo de cache hospedado, não
é necessário colocar o conteúdo de pré-hash em seus servidores de conteúdo da Web e de arquivo, criar um pacote de
dados e importar o pacote de dados para pré-carregar seus servidores de cache hospedados com o 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 ) em HCS1, se os valores padrão do BranchCache não corresponderem aos seus objetivos 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. ()Conteúdo de prehash opcional em servidores de conteúdo, criar pacotes de dados e pré-carregar
conteúdo no servidor de cache hospedado.

NOTE
O pré-hash e o pré-carregamento de conteúdo em seu servidor de cache hospedado são opcionais. no entanto,
se você optar por prehash e Preload, deverá executar todas as etapas abaixo aplicáveis à sua implantação. (Por
exemplo, se você não tiver servidores Web, não precisará executar qualquer uma das etapas relacionadas ao
prehash e ao pré-carregamento do conteúdo do servidor Web.)

a. Em WEB1, o conteúdo do servidor Web de prehash e criar um pacote de dados.

b. Em ARQUIVO1, conteúdo de servidor de arquivos prehash e criar um pacote de dados.
c. Em WEB1 e ARQUIVO1, 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 ingressada 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 planejamento de implantação do modo de cache hospedado do
BranchCache.
 Planejamento da implantação do modo de cache
hospedado BranchCache
10/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

Você pode usar este tópico para planejar a implantação do BranchCache no modo de cache hospedado.

IMPORTANT
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 a configuração básica do servidor
Planejar o acesso ao domínio
Planejar o local e o tamanho do cache hospedado
Planejar o compartilhamento no qual os pacotes do servidor de conteúdo devem ser copiados
Planejar a criação de pacotes de dados e de hash em servidores de conteúdo

Planejar a configuração básica do servidor

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á está nomeado e tem uma
configuração de endereço IP.
depois de instalar Windows Server 2016 em seu servidor de cache hospedado, você deve renomear o
computador e atribuir e configurar um endereço IP estático para o computador local.

NOTE
Neste guia, o servidor de cache hospedado é denominado HCS1, mas você deve usar um nome de servidor apropriado
para sua implantação.

Planejar o acesso ao domínio

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 atualmente ingressado
no 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. 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
Em HCS1, determine onde o 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 no 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 seu 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 de hash em servidores de

conteúdo
Antes de fazer o hash de conteúdo em seus servidores de conteúdo, você deve identificar as pastas e os
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
10/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

Você pode usar este tópico para obter links para tópicos de procedimentos 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 pelo ponto de conexão de
serviço
Mover e redimensionar o cache hospedado ()opcional
Pré-hash e pré-carregamento de conteúdo no servidor de cache hospedado ()opcional
Configurar descoberta automática de cache hospedado pelo cliente por ponto de conexão de serviço

NOTE
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 .

Para continuar com este guia, consulte instalar o recurso do 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
10/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

Você pode usar este procedimento para instalar o recurso do BranchCache em seu servidor de cache
hospedado, HCS1, e para configurar o servidor para registrar um SCP de 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 para descobrir automaticamente os servidores de cache
hospedados consultando AD DS para o SCP. As instruções sobre como configurar computadores cliente para
executar essa ação são fornecidas posteriormente neste guia.

IMPORTANT
Antes de executar esse 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 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 do
BranchCache e registrar um ponto de conexão de serviço no AD DS, digite o seguinte comando em
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 status de exibição do comando para 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 dos 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 possa ser acessada dos 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 redimensionar o cache hospedado ()opcional .
 Mover e redimensionar o cache hospedado (
opcional)
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

Você pode usar este procedimento para mover o cache hospedado para a unidade e a pasta que preferir, e para
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 do cache padrão ( % windir% \ UserProfiles \ NetworkService \
AppData \ local \ PeerDistPub ) e Size – que é 5% do espaço total no 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 redimensionar o cache hospedado
1. abra Windows PowerShell com privilégios de administrador.
2. Digite o seguinte comando para mover o cache hospedado para outro local no computador local e
pressione ENTER.

IMPORTANT
Antes de executar o comando a seguir, substitua os valores de parâmetro, como – Path e – MoveTo, por valores
que são apropriados para sua implantação.

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

3. Digite o seguinte comando para redimensionar o cache hospedado – especificamente, o cache de dados -
no computador local. Pressione ENTER.

IMPORTANT
Antes de executar o comando a seguir, substitua os valores de parâmetro, como - percentual, por valores que são
apropriados para sua implantação.

Set-BCCache -Percentage 20

4. Para verificar a configuração do servidor de cache hospedado, digite o comando a seguir e pressione
ENTER.

Get-BCStatus

Os resultados do status de exibição do comando para 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 é exibido na saída do comando.
Para continuar com este guia, consulte prehash e pré-carregar conteúdo no servidor de cache hospedado
()opcional .
 Pré-hash e conteúdo de pré-carregamento no
servidor de cache hospedado ( opcional)
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

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 o conteúdo, os dados serão adicionados ao cache hospedado automaticamente à
medida que os clientes os baixarem pela conexão WAN.

IMPORTANT
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 (dados)
Importar pacotes de dados no servidor de cache hospedado (opcional)
Para continuar com este guia, consulte Create Content Server Data Packages for Web and File Content
(Optional).
 Criar pacotes de dados do servidor de conteúdo
para conteúdo da Web e do arquivo (opcional)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

Você pode usar esse procedimento para pré-abrir o conteúdo na Web e em servidores de arquivos e, em
seguida, criar pacotes de dados para importar no servidor de cache hospedado.
Esse procedimento é opcional porque você não precisa pré-hash e pré-carregar conteúdo em seus servidores
de cache hospedados. Se você não pré-carregar o conteúdo, os dados serão adicionados ao cache hospedado
automaticamente à medida que os clientes os baixarem pela conexão WAN.
Este procedimento fornece instruções para pré-aplicação de conteúdo em servidores de arquivos e servidores
Web. Se você não tiver um desses tipos de servidores de conteúdo, não será preciso executar as instruções para
esse tipo de servidor de conteúdo.

IMPORTANT
Antes de executar este 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 de pré-hash do
conteúdo – modificar o segredo do servidor invalida os - 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 pré-manter e adicionar a
um pacote de dados. Identifique ou crie uma pasta na qual você deseja salvar seu pacote de dados
posteriormente neste procedimento.
2. No computador do servidor, abra Windows PowerShell privilégios de Administrador.
3. Faça um ou ambos os seguintes, dependendo dos tipos de servidores de conteúdo que você tem:

NOTE
O valor do parâmetro –Path é a pasta em que 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 dados que você
deseja pré-manter e adicionar a um pacote.

Se o conteúdo que você deseja pré-hash 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 pré-hash 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 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 em seus servidores de cache hospedados em que

você deseja pré-carregar 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)
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

Você pode usar esse procedimento para importar pacotes de dados e pré-carregar conteúdo em seus
servidores de cache hospedados.
Esse procedimento é opcional porque você não precisa pré-hash e pré-carregar conteúdo em seus servidores
de cache hospedados.
Se você não pré-carregar 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 Configure Client Automatic Hosted Cache Discovery by Service
Connection Point.
 Configurar descoberta automática de cache
hospedado cliente por ponto de conexão de serviço
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

com este procedimento, você pode usar Política de Grupo para habilitar e configurar o modo de cache
hospedado do branchcache em - computadores ingressados no domínio que executam os - sistemas
operacionais compatíveis Windows com o branchcache a seguir.
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
O Windows 8 Enterprise

NOTE
para configurar computadores ingressados no domínio que executam o Windows server 2008 R2 ou Windows 7, consulte
o guia de implantação do BranchCachedo Windows Server 2008 R2.

A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste

procedimento.
Para usar Política de Grupo para configurar clientes para o modo de cache hospedado
1. Em um computador no qual a função de servidor do Active Directory Domain Services está instalada,
abra Gerenciador do Servidor, selecione o servidor local, clique em ferramentas e, 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:
Corp.contoso.com, domínios , corp.contoso.com, política de grupo objetos , em que Corp.contoso.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 - política de grupo objetos e clique em novo . A caixa de diálogo
Novo GPO é aberta. Em nome , digite um nome para o novo GPO do objeto de política 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 do Política de Grupo, verifique se política de grupo objetos 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ê tiver nomeado os computadores cliente do GPO BranchCache, clique com o
botão direito do mouse - em computadores cliente do BranchCache . Clique em 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í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 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 do Editor de Gerenciamento de Política de Grupo, verifique se o BranchCache ainda está
selecionado e, no painel de detalhes, clique duas vezes em - habilitar descober ta automática de
cache hospedado pelo ponto de conexão de ser viço . A caixa de diálogo configuração de política é
aberta.
9. Na caixa de diálogo habilitar descober ta automática de cache hospedado por ponto de
conexão de ser viço , clique em habilitado e em OK .
10. Para permitir que os computadores cliente baixem e armazenem o conteúdo em cache de servidores de
conteúdo baseados em servidor de arquivos do BranchCache - : no console do editor de gerenciamento
de política de grupo, verifique se o BranchCache ainda está selecionado e, 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 .

NOTE
Por padrão, os computadores cliente armazenam em cache o conteúdo de servidores de arquivos se a latência de
rede de ida e volta for maior que 80 milissegundos.

12. Para configurar a quantidade de espaço em disco 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, 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 quais segmentos são válidos no cache de dados do
BranchCache em computadores cliente: no console do Editor de Gerenciamento de Política de Grupo,
verifique se o BranchCache ainda está selecionado e, 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 na 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. Defina configurações adicionais de política de BranchCache para computadores cliente, conforme
apropriado para sua implantação.
15. Atualize Política de Grupo nos computadores cliente da filial executando o comando gpupdate/force ou
reinicializando os computadores cliente.
A implantação do modo de cache hospedado do BranchCache agora está concluída.
Para obter informações adicionais sobre as tecnologias deste guia, consulte recursos adicionais.
 Recursos adicionais do BranchCache
10/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
e Windows Server 2012

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 Guia de implantação do BranchCache do Server 2008 R2
 BranchCache
12/08/2021 • 34 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

NOTE
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?
o BranchCache é uma tecnologia de otimização de largura de banda de WAN (rede de longa distância) 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.
em filiais, o conteúdo é armazenado em servidores que estão configurados para hospedar o cache ou, quando
nenhum servidor está disponível na filial, em computadores cliente que executam 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.

NOTE
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 no 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.
Cau t i on

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 uma nuvem data center. Os seguintes tipos de
servidores de conteúdo são suportados pelo BranchCache:

NOTE
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 o conteúdo do Windows Update, poderá instalar um servidor de aplicativos do Windows
Server Update Services (WSUS) em seu escritório principal ou na nuvem data center e configurá-lo como um servidor de
conteúdo do BranchCache.

Servidores Web
os servidores Web com suporte incluem computadores que executam o Windows Server 2016, Windows
Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2 que têm a função de servidor servidor
Web (IIS) instalada e que usam http (Hypertext Transfer Protocol) 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 executam o Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2 que têm a função de servidor
serviços de arquivos e o BranchCache para o serviço de função de arquivos de rede instalados.
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 executam o Windows Server 2016,
Windows Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2 com o Serviço de Transferência
Inteligente em Segundo Plano (BITS) 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 o Microsoft Windows Server Update Services (WSUS) e Microsoft Endpoint
Configuration Manager servidores de ponto de distribuição de ramificação como servidores de conteúdo 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 preocupam onde
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.
 NOTE
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 o BranchCache com o protocolo HTTPS e não HTTP.

= = = = = = = para obter mais informações sobre as tecnologias de nuvem no Windows Server 2016, consulte
rede definida pelo Software (SDN).

Versões das informações de conteúdo

Há duas versões das informações de conteúdo:
as informações de conteúdo que são compatíveis com computadores que executam o 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.
as informações de conteúdo que são 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.

NOTE
Na tabela a seguir, o acrônimo "so" significa sistema operacional.

VERSÕ ES DA S
SIST EM A O P ERA C IO N A L SO DE SERVIDO R DE SO DE SERVIDO R DE C A C H E IN F O RM A Ç Õ ES DE
C L IEN T E C O N T EÚDO H O SP EDA DO C O N T EÚDO

Windows Server 2008 R2 e Windows Server 2012 ou Windows Server 2012 ou V1

Windows 7 posterior posterior; nenhum para o
modo de cache distribuído

Windows Server 2012 ou Windows Server 2008 R2 Windows Server 2012 ou V1

posterior; Windows 8 ou posterior; nenhum para o
posterior modo de cache distribuído

Windows Server 2012 ou Windows Server 2012 ou Windows Server 2008 R2 V1

posterior; Windows 8 ou posterior
posterior
 VERSÕ ES DA S
SIST EM A O P ERA C IO N A L SO DE SERVIDO R DE SO DE SERVIDO R DE C A C H E IN F O RM A Ç Õ ES DE
C L IEN T E C O N T EÚDO H O SP EDA DO C O N T EÚDO

Windows Server 2012 ou Windows Server 2012 ou Windows Server 2012 ou V2

posterior; Windows 8 ou posterior posterior; nenhum para o
posterior modo de cache distribuído

Quando você tem servidores de conteúdo e servidores de cache hospedados que executam 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 computadores que executam Windows Server 2008 R2 e Windows 7 solicitam conteúdo, o conteúdo e
os servidores de cache hospedados usam informações de conteúdo V1.

IMPORTANT
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 que estão 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 escritas
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 no Windows Server 2016 para instalar o recurso BranchCache ou o
serviço de função BranchCache para Arquivos de Rede 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.

IN STA L A R EST E EL EM EN TO DO
F UN C IO N A L IDA DE LO C A L N O C O M P UTA DO R B RA N C H C A C H E

Servidor de conteúdo ( Servidor de Matriz ou datacenter na nuvem Recurso BranchCache

aplicativos baseado em BITS)

Servidor de conteúdo ( Servidor Web) Matriz ou datacenter na nuvem Recurso BranchCache

Servidor de arquivos ( de conteúdo Matriz ou datacenter na nuvem Serviço de função BranchCache para
usando o protocolo SMB) Arquivos de Rede da função de
servidor Serviços de Arquivo
 IN STA L A R EST E EL EM EN TO DO
F UN C IO N A L IDA DE LO C A L N O C O M P UTA DO R B RA N C H C A C H E

Servidor de cache hospedado Filial Recurso BranchCache com modo de

servidor de cache hospedado
habilitado

Computador cliente habilitado por Filial Nenhuma instalação necessária; basta

BranchCache habilitar o 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 Arquivo e
Ser viços 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 Deduplication 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 serviços Armazenamento com o serviço de
função BranchCache para Arquivos de Rede.
Na página do assistente Selecione recursos , se você estiver instalando um servidor de conteúdo que não
seja 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 o BranchCache com suporte para BITS (Serviço de Transferência
Inteligente em Segundo Plano), HTTP (Hyper Text Transfer Protocol) e SMB (Server Message Block).
Windows 10 Enterprise
Windows 10 Education
Windows 8.1 Enterprise
O Windows 8 Enterprise
Windows 7 Enterprise
Windows 7 Ultimate
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, somente suporte a BITS
Windows 8.1 Pro, somente suporte a BITS
Windows 8 Pro, suporte somente para BITS
Windows 7 Pro, suporte somente para BITS

NOTE
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 somente para o protocolo BITS (Serviço de Transferência Inteligente em
Segundo Plano). Para obter mais informações e para baixar Windows Management Framework, consulte Windows
Management Framework (Windows PowerShell 2.0, WinRM 2.0 e BITS 4.0) em https://go.microsoft.com/fwlink/?
LinkId=188677 .

Sistemas operacionais para a funcionalidade de servidor de conteúdo BranchCache

Você pode usar as 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 Windows Server 2008 R2 de sistemas operacionais pode ser usada como servidores de
conteúdo BranchCache, com as seguintes exceções:
O BranchCache não tem suporte em instalações server core do Windows Server 2008 R2 Enterprise com
Hyper-V.
Não há suporte para o BranchCache em instalações 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 as Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012 de sistemas
operacionais como servidores de cache hospedados do BranchCache.
Além disso, os seguintes sistemas operacionais Windows Server 2008 R2 podem ser usados como servidores
de cache hospedados do BranchCache:
Windows Server 2008 R2 Enterprise
Windows Servidor 2008 R2 Enterprise com Hyper-V
Windows Server 2008 R2 Enterprise Server Core
Windows Instalação do Server 2008 R2 Enterprise Server Core com Hyper-V
Windows Server 2008 R2 for Itanium-Based Systems
Windows Server 2008 R2 Datacenter
Windows Datacenter do Server 2008 R2 com Hyper-V
Windows Instalação do Server 2008 R2 Datacenter Server Core com 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.

NOTE
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 o servidor
de conteúdo e o cliente estiverem - habilitados para 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.
Após 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.

NOTE
Se os segmentos de conteúdo completos não existirem em um computador, o protocolo de recuperação recuperará e
constituirá o conteúdo a partir de uma combinação de origens: um conjunto de computadores clientes no 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 da matriz.

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. no Windows 7, o algoritmo de criptografia padrão
usado pelo BranchCache é o AES-128, a chave de criptografia é Ke e o tamanho da chave é de 128 bits,
conforme determinado 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 executam o Windows Server 2008 R2, um certificado do
servidor de cache hospedado e uma chave privada associada são necessários e a AC (autoridade de
certificação) que emitiu o certificado deve ser confiável para computadores cliente na filial. Isso permite
que o cliente e o servidor participem com êxito na autenticação do servidor HTTPS.

IMPORTANT
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á vinculado 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 adição de 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 de blocos do servidor de cache hospedado. 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á executando 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 pelo link 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.

NOTE
Os servidores de cache hospedados que estão executando Windows Server 2016, Windows Server 2012 R2 ou Windows
Server 2012 criptografam 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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

no Windows Server, você pode configurar e gerenciar o BranchCache usando os comandos de Windows
PowerShell ou de Shell de rede (Netsh) para BranchCache.
Nas futuras versões do Windows, a Microsoft poderá remover a funcionalidade do netsh para BranchCache. a
Microsoft recomenda a transição 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 as duas
referências de comando tenham sido publicadas para sistemas operacionais anteriores a 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

TIP
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
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este guia para aprender a 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

o BranchCache é uma tecnologia de otimização de largura de banda de WAN (rede de longa distância) incluída
em algumas edições do Windows Server 2016, Windows server ® 2012 R2, Windows server ® 2012,
Windows server ® 2008 R2 e sistemas operacionais de Windows cliente 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.
em 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 Server 2008 R2-ou, se não houver
servidores disponíveis na filial, o conteúdo será armazenado em cache em computadores cliente em execução
Windows 10 ® , Windows ® 8,1, Windows 8 ou Windows 7 ® .
Depois que um computador cliente solicita e recebe o conteúdo do escritório principal ou do datacenter de
nuvem e o conteúdo é armazenado em cache na filial, outros computadores na mesma filial podem obter o
conteúdo localmente, em vez de entrar em contato com o servidor de conteúdo pelo link WAN.
Benefícios da implantação do BranchCache
O BranchCache armazena em cache o conteúdo de arquivos, da Web e de aplicativos em locais de filiais,
permitindo que os computadores cliente acessem dados usando a LAN (rede local) em vez de acessar o
conteúdo em conexões WAN lentas.
O BranchCache reduz o tráfego de 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 seu
conteúdo criptografando os caches no servidor de cache hospedado e em 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, armazenamos em cache o
conteúdo para 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 do Branch Office 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. Em seguida, o servidor de cache hospedado armazena em cache o
 conteúdo para 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 que é 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:
Ser vidores de conteúdo baseados em ser vidor 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 as versões Windows Server 2016, Windows Server 2012 r2, Windows
Server 2012 ou Windows Server 2008 R2 que dão suporte ao BranchCache e no qual o recurso
BranchCache está instalado.
Ser vidores de aplicativos baseados em bits . Esses servidores de conteúdo enviam conteúdo para
computadores cliente do BranchCache usando o Serviço de Transferência Inteligente em Segundo Plano
(BITS). 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 dão suporte ao
BranchCache e no qual o recurso BranchCache está instalado.
Ser vidores de conteúdo baseados em ser vidor 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 dão suporte ao BranchCache e no qual a função de servidor serviços de
arquivo 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 ser vidores de conteúdo da Web e de arquivo devem estar executando um dos seguintes
sistemas operacionais para fornecer a funcionalidade do BranchCache: Windows Server 2016, Windows
Server 2012 R2, Windows Server 2012 ou Windows Server 2008 R2. os clientes Windows 8 e
posteriores continuam a ver os benefícios do BranchCache ao acessar os servidores de conteúdo que
estão executando o Windows Server 2008 R2, no entanto, eles não podem usar as novas tecnologias de
agrupamento e de 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 fazer
uso do modelo de implantação mais recente e os aprimoramentos de agrupamento e de hash que foram
introduzidos com o Windows Server 2012.
os ser vidores de cache hospedados devem estar executando Windows Server 2016, Windows Server
2012 R2 ou Windows Server 2012 para fazer uso dos aprimoramentos de implantação e recursos de
escala descritos neste documento. um computador que esteja executando um desses sistemas
operacionais configurado como um servidor de cache hospedado pode continuar a servir os
computadores cliente que estão executando o Windows 7, mas para fazer isso, ele deve estar equipado
com um certificado adequado para TLS (segurança de camada de transporte), conforme descrito no guia
de implantação do BranchCacheWindows server 2008 R2 e Windows 7.
Um domínio Active Director y é necessário para aproveitar o política de grupo e a descoberta
automática de cache 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 estejam executando Windows Server 2012 ou posterior para utilizar novas
configurações de Política de Grupo do BranchCache; você pode importar os modelos administrativos do
BranchCache para controladores de domínio que executam sistemas operacionais anteriores ou pode
 criar objetos de política de grupo remotamente em outros computadores que estejam executando
Windows 10, Windows Server 2016, Windows 8.1, Windows Server 2012 R2, Windows 8 ou Windows
Server 2012.
Active Director y sites são usados para limitar o escopo de 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 sobre 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 nos sistemas operacionais Windows Server 2012, Windows 8 e posteriores.

NOTE
se você estiver implantando o BranchCache em sistemas operacionais diferentes de Windows Server 2016, os recursos de
documentação a seguir estarão disponíveis.
para obter informações sobre o BranchCache em 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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber mais sobre os modos de BranchCache e para selecionar os melhores
modos para sua implantação.
Você pode usar este guia para implantar o BranchCache nos modos e combinações de modo a seguir.
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 estã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 descreve 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 (aplicativos)
Pré-hashiing e preloading content on Hosted Cache Servers (opcional)
Configurar computadores cliente BranchCache

NOTE
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 e configurar servidores de conteúdo
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 servidores do sistema de sites de distribuição
do branch do Windows Server Update Services (WSUS) e do branch do Microsoft Endpoint Configuration
Manager, você deve instalar o recurso BranchCache, iniciar o serviço BranchCache e (somente para servidores
WSUS) executar etapas de configuração adicionais.
Consulte os tópicos a seguir para implantar servidores de conteúdo.
Instalar o recurso BranchCache
Configurar Windows Server Update Services (servidores de conteúdo) WSUS
 Instalar o recurso BranchCache
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.
A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.
Antes de executar este procedimento, é recomendável instalar e configurar seu aplicativo baseado em BITS ou
servidor Web.

NOTE
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

1. No Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções e Recursos . O
assistente Adicionar Funções e Recursos é 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 ser vidor de destino, verifique se o servidor correto está selecionado e clique em
Próximo.
4. Em Selecionar funções de ser vidor , clique em Avançar .
5. Em Selecionar recursos, clique em BranchCache e, em seguida, 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)
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

NOTE
Quando você implanta um servidor de arquivos habilitado para BranchCache ou um servidor Web como um servidor de
conteúdo, as informações de conteúdo agora são calculadas offline, bem antes de um cliente do BranchCache solicitar um
arquivo. Por causa dessa 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 realizados.

Consulte os tópicos a seguir para implantar servidores de conteúdo.

Configurar a função de servidor de Serviços de Arquivo
Habilitar a 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode implantar servidores de conteúdo baseados no servidor de arquivos do branchcache em

computadores que executam Windows Server 2016 e a função de servidor serviços de arquivo com o
BranchCache para o ser viç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 tem os
serviços de arquivo 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á esteja configurado
com a função de servidor de serviços de arquivo, 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.
A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.

NOTE
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
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. Em Antes de Começar , clique em Avançar .
2. Em Selecionar tipo de instalação , verifique se a instalação baseada em função ou em recurso está
selecionada e clique em Avançar .
3. Em selecionar ser vidor de destino , verifique se o servidor correto está selecionado e clique em
Avançar .
4. em selecionar funções de ser vidor , em funções , observe que a função arquivo e ser viç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, em seguida, clique na seta à esquerda de ser viços de arquivo e iSCSI .
5. Marque as caixas de seleção do ser vidor de arquivos e do BranchCache para arquivos de rede .

TIP
É 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para instalar o BranchCache para o serviço de função de arquivos de rede
da função de servidor de serviços de arquivo em um computador que executa o Windows Server 2016.

IMPORTANT
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.

A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.

NOTE
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

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 o BranchCache para o serviço de função de arquivos de rede

1. No Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções e Recursos . O
assistente Adicionar funções e recursos é aberto. Clique em Próximo .
2. Em Selecionar tipo de instalação , verifique se a instalação baseada em função ou em recurso está
selecionada e clique em Avançar .
3. Em selecionar ser vidor de destino , verifique se o servidor correto está selecionado e clique em
Avançar .
4. em selecionar funções de ser vidor , em funções , observe que a função arquivo e ser viç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, em seguida, clique na seta à esquerda de ser viços de arquivo e iSCSI .
5. Marque a caixa de seleção do BranchCache para arquivos de rede .

TIP
Se você ainda não tiver feito isso, é recomendável marcar também 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 .
 Habilitar publicação de hash para servidores de
arquivos
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 Política de Grupo do computador
local, consulte habilitar a publicação de hash para servidores de arquivos não membro do domínio.
Para habilitar a publicação de hash em vários servidores de arquivos usando o Política de Grupo de
domínio, consulte habilitar a publicação de hash para servidores de arquivos do membro do domínio.

NOTE
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, você poderá usar as instruções no tópico habilitar a
publicação de hash para servidores de arquivos não membro do domínio.
 Habilitar publicação de hash para servidores de
arquivos do membro que não sejam de domínio
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 de Serviços de Arquivos
instalada.
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.
A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.

NOTE
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, Ser vidor Lanman. Clique em
Ser vidor 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 compar tilhadas 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 compar tilhadas.
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
compar tilhadas 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 compar tilhadas .
8. Clique em OK .
 Habilitar publicação de hash para servidores de
arquivos associados ao domínio
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.
Para criar 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
ferramentas e, em seguida, clique em Active Director y 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, 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 Ser vidores
de arquivos BranchCache e clique em OK .
 Mover servidores de arquivos para a unidade
organizacional de servidores de arquivos
BranchCache
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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).
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.

NOTE
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
ferramentas e, em seguida, clique em Active Director y 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 ser vidores 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para criar a publicação de hash BranchCache Política de Grupo Objeto (GPO).
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.

NOTE
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

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
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 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.
A associação a Adminis. do Domínio ou equivalente é o requisito mínimo para a execução deste
procedimento.

NOTE
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 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
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 , ser vidor 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 compar tilhadas e
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 compar tilhadas .
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
compar tilhadas 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 compar tilhadas .
10. Clique em OK .

NOTE
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)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para habilitar o BranchCache em um compartilhamento de arquivos.

IMPORTANT
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 compar tilhadas.

A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.

Para habilitar o BranchCache em um compartilhamento 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 Pastas
Compar tilhadas . O Assistente para Pastas Compartilhadas é aberto com o objeto Computador Local
selecionado. Configure a Exibição de sua preferência, clique em Concluir e clique em OK.
4. Clique duas vezes em Pastas Compar tilhadas (Local) e clique em Compar tilhamentos .
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 hospedado
(opcional)
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para instalar e configurar servidores de cache hospedados do BranchCache
localizados em filiais em que você deseja implantar o modo de cache hospedado do BranchCache. com o
BranchCache no Windows Server 2016, você pode implantar vários servidores de cache hospedados em uma
filial.

IMPORTANT
Essa 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 será necessário
implantar um servidor de cache hospedado e não precisará executar as etapas neste procedimento.

Você deve ser 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 Windows PowerShell prompt para instalar o recurso do 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 de 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 em Active Directory para descoberta automática de
servidor de cache hospedado por computadores cliente, digite o seguinte comando no prompt de
Windows PowerShell e pressione ENTER.
Enable-BCHostedServer -RegisterSCP

3. para verificar a configuração correta do servidor de cache hospedado, digite o seguinte comando no
prompt de Windows PowerShell e pressione ENTER.
Get-BCStatus

NOTE
Depois de executar esse comando, na seção HostedCacheSer verConfiguration , o valor de
HostedCacheSer verIsEnabled será true . Se você tiver configurado um servidor de cache hospedado associado
ao domínio para registrar um SCP (ponto de conexão de serviço) em 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)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para forçar a criação de informações de conteúdo – também chamadas de
hashes-em servidores Web e de arquivos habilitados para BranchCache. Você também pode reunir os dados em
arquivos e servidores Web em pacotes que podem ser transferidos para servidores de cache hospedados
remotos. Isso fornece a capacidade de pré-carregar conteúdo em servidores de cache hospedados remotos para
que os dados estejam disponíveis para o primeiro acesso para cliente.
Você deve ser membro de Administradores ou equivalente para executar este procedimento.
Para colocar o conteúdo de pré -hash e pré -carregar o conteúdo em servidores de cache hospedados
1. Faça logon no arquivo ou servidor Web que contém os dados que você deseja pré-carregar e identifique
as pastas e os arquivos que você deseja carregar em um ou mais servidores de cache hospedados
remotamente.
2. execute Windows PowerShell como administrador. Para cada pasta e arquivo, execute o
Publish-BCFileContent comando ou o Publish-BCWebContent comando, dependendo do tipo de servidor
de conteúdo, para disparar a geração de hash e para adicionar dados a um pacote de dados.
3. Depois que todos os dados tiverem sido adicionados ao pacote de dados, exporte-os usando o
Export-BCCachePackage comando para produzir um arquivo de pacote de dados.

4. Mova o arquivo de pacote de dados para os servidores de cache hospedado remoto usando sua opção
de tecnologia de transferência de arquivo. FTP, SMB, HTTP, DVD e discos rígidos portáteis são
Transportações viáveis.
5. Importe o arquivo de pacote de dados nos servidores de cache hospedados remotos usando o
Import-BCCachePackage comando.
 Configurar BranchCache em computadores cliente
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar os tópicos a seguir para configurar computadores cliente membros do domínio e não membros
do domínio como clientes de cache distribuído branchCache ou modo de cache 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 são do domínio para permitir o tráfego do
BranchCache
Verificar o computador cliente Configurações
 Usar Política de Grupo para configurar
computadores cliente membro do domínio
07/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Nesta seção, você criará um objeto Política de Grupo para todos os computadores em sua organização,
configurará computadores cliente membro do domínio com o modo de cache distribuído ou o modo de cache
hospedado e configurará o Firewall do Windows 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 Política de Grupo e configurar os modos 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 avançadas de tráfego de saída de segurança

TIP
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 outro contêiner apropriado para sua implantação.

Você deve ser um membro de Administradores de Domínio ou equivalente para executar esses
procedimentos.

Para criar um objeto Política de Grupo e configurar os modos

BranchCache
1. Em um computador no qual a função Active Directory Domain Services servidor está instalada, no
Gerenciador do Servidor, clique em Ferramentas e, em seguida, clique em Política de Grupo
Management . O console Política de Grupo Management é aberto.
2. No console de Gerenciamento do Política de Grupo, expanda o seguinte caminho: Floresta:
example.com, Domínios , example.com, objetos Política de Grupo , em que example.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 Política 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 do 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 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 BranchCache modo de Cache Distribuído . 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 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 por 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 Habilitado e, em seguida, clique em OK .

NOTE
Quando você habilita as configurações de política Definir Cache Distribuído do BranchCache e Habilitar
Descoberta Automática de Cache Hospedado por Ponto de Conexão de Serviço, os computadores cliente operam
no modo de cache distribuí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, objetos Política de Grupo , em que example.com é o nome do
domínio em que estão localizadas as contas de computador cliente do BranchCache que você deseja
configurar.
2. No Console de Gerenciamento de Diretiva de Grupo, verifique se Objetos de Diretiva de Grupo está
selecionado e, no painel de detalhes, clique no GPO dos computadores cliente BranchCache criados
anteriormente. 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.
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 , Segurança Configurações ,
Firewall do Windows com Segurança Avançada, Firewall do Windows com Segurança Avançada –
LDAP, Regras de Entrada .
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 .

IMPORTANT
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.
9. Em Tipo de Regra, clique em Predefinido, expanda a lista de opções e clique em BranchCache –
Descoberta de Pares (Usa WSD). Clique em Próximo .
10. Em Regras Predefinidas , clique em Avançar .
11. Em Ação , verifique se Permitir a conexão está selecionado e clique em Concluir .

IMPORTANT
Selecione Permitir a conexão para que o cliente BranchCache possa receber o tráfego nesta porta.

Para configurar o firewall Windows com regras avançadas de tráfego

de saída de segurança
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.
2. 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 .
3. Em Regras Predefinidas , clique em Avançar .
4. Em Ação , verifique se Permitir a conexão está selecionado e clique em Concluir .

IMPORTANT
Selecione Permitir a conexão para que o cliente BranchCache possa enviar o tráfego nesta porta.

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.
6. Em Tipo de Regra, clique em Predefinido, expanda a lista de opções e clique em BranchCache –
Descoberta de Pares (Usa WSD). Clique em Próximo .
7. Em Regras Predefinidas , clique em Avançar .
8. Em Ação , verifique se Permitir a conexão está selecionado e clique em Concluir .

IMPORTANT
Selecione Permitir a conexão para que o cliente BranchCache possa enviar o tráfego nesta porta.
 usar Windows PowerShell para configurar
computadores cliente que não são membros do
domínio
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para configurar manualmente um computador cliente do BranchCache para
o modo de cache distribuído ou o modo de cache hospedado.

NOTE
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.

A associação a Administradores ou equivalente é o requisito mínimo para a execução deste procedimento.

Para habilitar o modo de cache distribuído ou hospedado do BranchCache
1. no computador cliente do BranchCache que você deseja configurar, execute Windows PowerShell como
administrador e, em seguida, siga um destes procedimentos.
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

TIP
Se você quiser especificar os servidores de cache hospedados disponíveis, use o -ServerNames
parâmetro com uma lista separada por vírgulas de seus 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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

NOTE
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 Caching e Descoberta de 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 Configurações do computador cliente
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para verificar se o computador cliente está configurado corretamente para
BranchCache.

NOTE
Este procedimento inclui etapas para atualizar manualmente Política de Grupo e para reiniciar o serviço do BranchCache.
Não será necessário executar essas ações se você reinicializar o computador, pois eles ocorrerão automaticamente nessa
circunstância.

Você deve ser membro de Administradores ou equivalente para executar este 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 são configurados para
descobrir automaticamente servidores de cache hospedados pelo ponto de conexão de serviço, execute
os seguintes comandos para parar e reiniciar o serviço do BranchCache.
net stop peerdistsvc

net start peerdistsvc

3. Inspecione o modo operacional do BranchCache atual executando o comando a seguir.

Get-BCStatus

4. em Windows PowerShell, examine 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 que você configurou usando este guia.
No ClientSettings , se você configurou o modo de cache hospedado e forneceu os nomes dos seus
servidores de cache hospedados durante a configuração, ou se o cliente localizou automaticamente os
servidores de cache hospedados usando pontos de conexão de serviço, HostedCacheSer verList deve
ter um valor igual ao nome ou aos nomes dos seus servidores de cache hospedados. Por exemplo, se o
servidor de cache hospedado for denominado HCS1 e seu domínio for corp.contoso.com, o valor de
HostedCacheSer verList 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 de diretiva de computador local ou Política de Grupo,
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 do BranchCache.
 DirectAccess
10/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para obter uma breve visão geral do DirectAccess, incluindo os sistemas
operacionais de servidor e cliente que dão suporte ao DirectAccess e links para a documentação adicional do
DirectAccess para Windows Server 2016.

NOTE
Além deste tópico, a seguinte documentação do DirectAccess está disponível.
caminhos de implantação do directaccess no servidor Windows
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 a conectividade para usuários remotos para recursos de rede da organização sem a
necessidade de conexões de VPN (rede virtual privada) tradicionais. Com as conexões do DirectAccess, os
computadores cliente remotos são sempre conectados à sua organização – não há necessidade de que os
usuários remotos iniciem e parem conexões, como é necessário com conexões VPN. Além disso, os
administradores de ti podem gerenciar computadores cliente do DirectAccess sempre que estiverem em
execução e conectados à Internet.

IMPORTANT
Não tente implantar o acesso remoto em uma VM de 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 no Windows Server 2016 ou em versões anteriores do
Windows Server. para obter mais informações, consulte suporte de software de servidor da Microsoft para máquinas
virtuais Microsoft Azure.

O DirectAccess fornece suporte apenas para clientes ingressados no domínio que incluem suporte ao sistema
operacional para o DirectAccess.
Os sistemas operacionais de servidor a seguir dão suporte ao DirectAccess.
você pode implantar todas as versões do Windows Server 2016 como um cliente directaccess ou um
servidor directaccess.
você pode implantar todas as versões do Windows Server 2012 R2 como um cliente directaccess ou um
servidor directaccess.
 você pode implantar todas as versões do Windows Server 2012 como um cliente directaccess ou um
servidor directaccess.
você pode implantar todas as versões do Windows Server 2008 R2 como um cliente directaccess ou um
servidor directaccess.
Os sistemas operacionais cliente a seguir dão suporte ao DirectAccess.
Windows 10 Enterprise
Windows 10 Enterprise 2015 Branch de Manutenção em Longo Prazo (LTSB)
Windows 8 e 8,1 Enterprise
Windows 7 Ultimate
Windows 7 Enterprise
 Sistema de nome de domínio (DNS)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

O DNS (sistema de nomes de domínio) é um dos pacotes padrão do setor de protocolos que compõem TCP/IP
e, juntos, o cliente DNS e o servidor DNS fornecem serviços de resolução de nomes de nome de computador
para os computadores e usuários.

NOTE
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
vídeo: Windows Server 2016: gerenciamento de DNS em IPAM

no Windows Server 2016, o DNS é uma função de servidor que você pode instalar usando Gerenciador do
Servidor ou Windows PowerShell comandos. Se você estiver instalando um novo Active Directory floresta e
domínio, o DNS será instalado automaticamente com 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 de Active Directory é executada, como autenticação,
atualização ou pesquisa, os computadores usam o DNS para localizar Active Directory controladores de
domínio. Além disso, os controladores de domínio usam o DNS para localizar um ao outro.
o serviço cliente DNS está incluído em todas as versões de cliente e servidor do sistema operacional Windows e
está sendo executado por padrão na 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 para resolver nomes de computador para endereços IP. Por exemplo, quando um
usuário de rede com uma conta de usuário Active Directory faz logon em um domínio Active Directory, o
serviço cliente DNS consulta o servidor DNS para localizar um controlador de domínio para o domínio de
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 Windows Server 2016 servidor dns e os serviços cliente dns usam o protocolo dns que está incluído no
pacote de protocolo TCP/IP. O DNS faz parte da camada de aplicativo do modelo de referência TCP/IP, conforme
mostrado na ilustração a seguir.
 Novidades no cliente DNS no Windows Server 2016
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e 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 ser viç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 Tabela de Políticas de
Resolução de Nomes (NRPT), o serviço cliente DNS não se vinculará a uma interface específica.

NOTE
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.

Referências adicionais
Novidades do servidor DNS no Windows Server 2016
 o que há de novo no servidor DNS no Windows
server
13/08/2021 • 9 minutes to read
Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016
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.
F UN C IO N A L IDA DE
Políticas de DNS
Limitação de taxa de resposta (RRL)
Autenticação baseada em DNS de
entidades nomeadas (SUNDANÊS)
Suporte a registro desconhecido
N O VO O U M EL H O RA DO DESC RIÇ Ã O
Novo 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.
Novo 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.
Novo Você pode usar os registros TLSA
(autenticação de segurança de camada
de transporte) para fornecer
informações aos clientes DNS que
afirmam a qual AC 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.
Novo você pode adicionar registros que não
são explicitamente suportados pelo
servidor DNS Windows usando a
funcionalidade de registro
desconhecida.
 F UN C IO N A L IDA DE N O VO O U M EL H O RA DO DESC RIÇ Ã O

Dicas de raiz IPv6 Novo 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.

Windows PowerShell Support Melhoria de novos cmdlets Windows PowerShell

estão disponíveis para o servidor DNS.

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 - Brain, 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, 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 na localização geográfica. 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 Brain, 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 de cérebro
para Active Directory zonas integradas ou para zonas em servidores DNS autônomos.
Aplica. 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 . Este é o número máximo de vezes que a mesma resposta será dada a um
cliente dentro de um segundo.
Erros por segundo . Este é o número máximo de vezes que uma resposta de erro será enviada para o
mesmo cliente dentro de um segundo.
Janela . Este é 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 . Essa é a frequência com que o servidor DNS responderá 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 emitirá para um cliente
enquanto as respostas são suspensas.
Domínios daList 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 ser vidor deList. 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 tipo de 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 receberá um
certificado de CA2 e poderá 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 do Windows já tem a capacidade de processar tipos de registros desconhecidos. Windows
O servidor DNS não fará nenhum processamento específico de registro para os registros desconhecidos, mas o
enviará 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 do 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 Windows Server 2016.
Add-DnsSer verRecursionScope . 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-DnsSer verRecursionScope . Esse cmdlet Remove escopos de recursão existentes.
Set-DnsSer verRecursionScope . Esse cmdlet altera as configurações de um escopo de recursão
existente.
Get-DnsSer verRecursionScope . Esse cmdlet recupera informações sobre escopos de recursão
existentes.
Add-DnsSer verClientSubnet . Esse cmdlet cria uma nova sub-rede de cliente DNS. As sub-redes são
usadas pelas políticas de DNS para identificar onde um cliente DNS está localizado.
Remove-DnsSer verClientSubnet . Esse cmdlet Remove as sub-redes de cliente DNS existentes.
Set-DnsSer verClientSubnet . Esse cmdlet altera as configurações de uma sub-rede de cliente DNS
existente.
Get-DnsSer verClientSubnet . Esse cmdlet recupera informações sobre sub-redes de cliente DNS
existentes.
Add-DnsSer verQuer yResolutionPolicy . 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 é
respondida, com base em critérios diferentes.
Remove-DnsSer verQuer yResolutionPolicy . Esse cmdlet Remove as políticas DNS existentes.
Set-DnsSer verQuer yResolutionPolicy . Esse cmdlet altera as configurações de uma política DNS
existente.
Get-DnsSer verQuer yResolutionPolicy . Esse cmdlet recupera informações sobre as políticas de DNS
existentes.
Enable-DnsSer verPolicy . Esse cmdlet habilita as políticas DNS existentes.
Disable-DnsSer verPolicy . Esse cmdlet desabilita as políticas de DNS existentes.
Add-DnsSer verZoneTransferPolicy . Esse cmdlet cria uma nova política de transferência de zona do
servidor DNS. Políticas de transferência de zona DNS especifique se deseja negar ou ignorar uma
transferência de zona com base em critérios diferentes.
Remove-DnsSer verZoneTransferPolicy . Este cmdlet Remove as políticas de transferência de zona do
servidor DNS existentes.
Set-DnsSer verZoneTransferPolicy . Este cmdlet altera as configurações de uma política de
transferência de zona de servidor DNS existente.
 Get-DnsSer verResponseRateLimiting . Esse cmdlet recupera as configurações de RRL.
Set-DnsSer verResponseRateLimiting . Esse cmdlet altera a configurações de RRL.
Add-DnsSer verResponseRateLimitingExceptionlist . Esse cmdlet cria uma lista de exceções de RRL
no servidor DNS.
Get-DnsSer verResponseRateLimitingExceptionlist . Esse cmdlet recupera as listas de excception de
RRL.
Remove-DnsSer verResponseRateLimitingExceptionlist . Esse cmdlet Remove uma lista de exceções
de RRL existente.
Set-DnsSer verResponseRateLimitingExceptionlist . Esse cmdlet altera as listas de exceções de RRL.
Add-DnsSer verResourceRecord . Este cmdlet foi atualizado para dar suporte ao tipo de registro
desconhecido.
Get-DnsSer verResourceRecord . Este cmdlet foi atualizado para dar suporte ao tipo de registro
desconhecido.
Remove-DnsSer verResourceRecord . Este cmdlet foi atualizado para dar suporte ao tipo de registro
desconhecido.
Set-DnsSer verResourceRecord . Este cmdlet foi atualizado para dar suporte ao tipo de registro
desconhecido
para obter mais informações, consulte os tópicos de referência de comando a seguir Windows Server 2016
Windows PowerShell.
Módulo DnsServer
Módulo DnsClient

Referências adicionais
O que há de novo no cliente DNS
 Cliente DNS seguro via HTTPS (DoH)
12/08/2021 • 4 minutes to read

A partir do Windows Server 2022, o cliente DNS dá suporte a DNS sobre 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-texto. Ao passar a consulta DNS em uma conexão criptografada,
ela é protegida contra interceptação por terceiros nãotrudos.

Configurar o cliente DNS para dar suporte ao DoH

Você só poderá configurar o cliente Windows Server para usar o DoH se o servidor DNS primário ou
secundário selecionado para o 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 tradicionais de texto sem-
texto. Para configurar o cliente DNS para dar suporte ao DoH no Windows Server com Experiência Desktop, faça
as seguintes etapas:
1. No painel Windows Configurações controle, selecione Rede & Internet .
2. Na página Rede & Internet, selecione Ethernet .
3. Na tela Ethernet, selecione o 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 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 estão presentes na lista de servidores DoH conhecidos, o
menu suspenso Criptografia DNS preferencial será habilitada. Você pode escolher entre as seguintes
configurações para definir a criptografia DNS preferencial:
Somente criptografado (DNS sobre 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 são alternados de DoH para texto sem-texto.
Somente não criptografado. Todo o tráfego de consulta DNS para o servidor DNS especificado
não é criptografado. Essa configuração define o cliente DNS para usar consultas DNS de texto
sem-texto simples tradicionais.

6. Selecione Salvar para aplicar as configurações do DoH ao cliente DNS.

Se você estiver configurando o endereço do servidor DNS para um cliente usando o PowerShell usando o
cmdlet , a configuração do DoH dependerá se a configuração de fallback do servidor estiver na lista de
servidores Set-DNSClientServerAddress DoH conhecidos tabela. No momento, você não pode definir as
configurações do DoH para o cliente DNS no Windows Server 2022 usando o Windows Admin Center ou
sconfig.cmd.
Configurando o DoH por meio Política de Grupo
Windows As configurações locais e de domínio do Server 2022 Política de Grupo incluem a política de
resolução de nomes Configurar DNS sobre HTTPS (DoH). 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 deem
suporte ao protocolo. Se os servidores não deem suporte ao DoH, as consultas não criptografadas serão
emitidas.
Proibir o DoH. Impedirá o uso de DoH com consultas de cliente DNS.
Exigir DoH . Exigirá que as consultas sejam executadas usando o DoH. Se os servidores DNS
configurados não deem suporte ao DoH, a resolução de nomes falhará.

Não habilita 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 Active Directory Domain Services rede seja
criptografado, considere implementar regras de segurança de conexão baseadas em IPsec para proteger esse
tráfego. Confira 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 O servidor é acompanhando 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 Get-DNSClientDohServerAddress cmdlet
do PowerShell.
A lista padrão de servidores DoH conhecidos é a seguinte:

P RO P RIETÁ RIO DO SERVIDO R EN DEREÇ O S IP DO SERVIDO R DN S

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
Add-DnsClientDohServerAddress cmdlet do PowerShell. Especifique a URL do modelo do DoH e se você permitirá
que o cliente volte para uma consulta não criptografada caso a consulta segura falhe. A sintaxe desse comando
é:

Add-DnsClientDohServerAddress -ServerAddress '<resolver-IP-address>' -DohTemplate '<resolver-DoH-template>'

-AllowFallbackToUdp $False -AutoUpgrade $True

Usar Tabela de Políticas de Resolução de Nomes com o DoH

Você pode usar o Tabela de Políticas de Resolução de Nomes (NRPT) 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
maneira não criptografada.
 Visão geral do DNS anycast
13/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2016 e Windows Server 2019

Este tópico fornece informações sobre como o DNS Anycast funciona.

O que é Anycast?
Anycast é uma tecnologia que fornece vários caminhos de roteamento para um grupo de pontos de
extremidade que são atribuídos a cada um deles 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 (caminho múltiplo) 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 Anycast com DNS?

Com o DNS 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 Anycast também fornece uma camada extra de
redundância e pode ajudar a proteger contra ataques de negação de serviço dns.
Como o DNS Anycast funciona
O DNS Anycast funciona usando protocolos de roteamento, como Border Gateway Protocol (BGP) para enviar
consultas DNS para um servidor DNS ou grupo preferencial de servidores DNS (por exemplo: um grupo de
servidores DNS gerenciados por um balanceador de carga). Isso 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 é o local
mais próximo com base na topologia de rede. Veja o exemplo a seguir.
Figura 1: quatro servidores DNS localizados em sites diferentes em uma rede anunciam cada um o mesmo
endereço IP Anycast (setas pretas) para a rede. Um dispositivo cliente DNS envia uma solicitação para o
endereço IP Anycast. Os dispositivos de rede analisam as rotas disponíveis e enviam a consulta DNS do cliente
para o local mais próximo (seta azul).
O DNS Anycast é usado normalmente hoje para rotear o tráfego DNS para muitos serviços DNS globais. Por
exemplo, o sistema de servidor DNS raiz depende muito do DNS Anycast. O Anycast também funciona com
uma variedade de protocolos de roteamento e pode ser usado exclusivamente em intranets.

Windows Demonstração do Anycast do BGP nativo do servidor

O procedimento a seguir demonstra como o BGP nativo no Windows Server pode ser usado com o DNS
Anycast.
Requisitos
Um dispositivo físico com a função Hyper-V instalada.
Windows Server 2012 R2, Windows 10 ou posterior.
Duas VMs cliente (qualquer sistema operacional).
Recomendamos a instalação de ferramentas BIND para DNS, como dig.
3 VMs de servidor (Windows Server 2016 ou Windows Server 2019).
Se o Windows PowerShell loopbackAdapter do Windows PowerShell ainda não estiver instalado em
VMs de servidor (DC001, DC002), o acesso à Internet será temporariamente necessário para instalar
este módulo.
Configuração do Hyper-V
Configure o servidor Hyper-V da seguinte forma:
Duas redes de comu switch virtual privadas estão configuradas
Uma rede de Internet simulada 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 servidor tem home-home duplo e está anexado às duas redes 131.253.1.0/24 e 10.10.10.0/24.
Configuração de rede da máquina virtual
De definir 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 em DC001.
Configurar DNS
Use Gerenciador do Servidor e o console de gerenciamento dns ou Windows PowerShell para instalar as
funções de servidor a seguir 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)
Crie uma zona estática (não integrada ao AD) chamada zone.tst em DC001 e DC002
Adicione 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 Windows PowerShell elevado em DC001 e DC002 para configurar
adaptadores de loopback.
 NOTE
O comando Install-Module requer acesso à Internet. Isso pode ser feito atribuindo temporariamente a VM a uma rede
externa no Hyper-V.

$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

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

2. DC001

Install-WindowsFeature RemoteAccess -IncludeManagementTools

Install-RemoteAccess -VpnType RoutingOnly
Add-BgpRouter -BgpIdentifier “10.10.10.1” -LocalASN 65511
Add-BgpPeer -Name "Labgw" -LocalIPAddress 10.10.10.1 -PeerIPAddress 10.10.10.254 -PeerASN 8075 –LocalASN
65511
Add-BgpCustomRoute -Network 51.51.51.0/24

3. DC002

Install-WindowsFeature RemoteAccess -IncludeManagementTools

Install-RemoteAccess -VpnType RoutingOnly
Add-BgpRouter -BgpIdentifier "10.10.10.2" -LocalASN 65511
Add-BgpPeer -Name "Labgw" -LocalIPAddress 10.10.10.2 -PeerIPAddress 10.10.10.254 -PeerASN 8075 –LocalASN
65511
Add-BgpCustomRoute -Network 51.51.51.0/24

Diagrama de resumo
Figura 2: Configuração do laboratório para demonstração nativa do DNS Anycast do BGP

Demonstração de DNS anycast

1. Verificar o roteamento de 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. No client1 e client2, verifique se você pode alcançar 51.51.51.51
PS C: > ping 51.51.51.51
Ping 51.51.51.51 com 32 bytes de dados:
Resposta de 51.51.51.51: bytes=32 horas<1 ms TTL=126
Resposta de 51.51.51.51: bytes=32 horas<1 ms TTL=126
Resposta de 51.51.51.51: bytes=32 horas<1 ms TTL=126
Resposta de 51.51.51.51: bytes=32 horas<1 ms TTL=126
Estatísticas de ping para 51.51.51.51:
Pacotes: Enviado = 4, Recebido = 4, Perdido = 0 (perda de 0%),
Tempos de ida e volta aproximados em mili-segundos:
Mínimo = 0 ms, Máximo = 0 ms, Média = 0 ms

NOTE
Se o ping falhar, verifique também se não há regras de firewall bloqueando ICMP.
3. No client1 e client2, use nslookup ou dig para consultar o registro TXT. Exemplos de ambos são
mostrados abaixo.
PS C: > dig server.zone.tst TXT +short
PS C: > nslookup -type=txt server.zone.tst 51.51.51.51
Um cliente exibirá "DC001" e o outro cliente exibirá "DC002" verificando se o Anycast está funcionando
corretamente. Você também pode consultar no servidor de gateway.
4. Em seguida, desabilite o adaptador Ethernet em DC001.
PS C: > (Get-NetAdapter). Nome
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 para 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 do DC001 mudaram para
DC002.
PS C: > nslookup -type=txt server.zone.tst 51.51.51.51
Servidor: Não Conhecido
Endereço: 51.51.51.51
server.zone.tst text =
"DC001"
PS C: > nslookup -type=txt server.zone.tst 51.51.51.51
Servidor: Não Conhecido
Endereço: 51.51.51.51
server.zone.tst text =
"DC002"
6. Confirme se a sessão BGP está ino mesmo no DC001 usando Get-BgpStatistics no servidor de gateway.
7. Habilita 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.

NOTE
Se um balanceador de carga não for usado, um cliente individual usará o mesmo servidor DNS de back-end se ele 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 Anycast é uma boa solução a ser usada em um ambiente DNS local?
R: O DNS Anycast funciona perfeitamente com um serviço DNS local. No entanto, 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á nenhum impacto direto na funcionalidade. Se um balanceador de carga for usado, nenhuma
configuração adicional em controladores de domínio será necessária.
P: Há suporte para uma configuração de DNS Anycast pelo serviço de atendimento ao cliente da Microsoft?
R: Se você usar um balanceador de carga não Microsoft para encaminhar consultas DNS, a Microsoft dará
suporte a problemas relacionados ao serviço servidor DNS. Consulte o fornecedor do balanceador de carga
para 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 anycast e DNS do Azure têm funcionalidade semelhante?
R: DNS do Azure usa Anycast. Para usar o Anycast com DNS do Azure, configure o balanceador de carga para
encaminhar solicitações para o DNS do Azure servidor.
 Guia de cenários de política de DNS
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.
Este guia contém as seções a seguir.
Visão geral das políticas dns
Usar política de DNS para gerenciamento de tráfego baseado em localização geográfica com servidores
primários
Usar política de DNS para gerenciamento de tráfego baseado em localização 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
 Visão geral das políticas de DNS
13/08/2021 • 12 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber mais sobre a política DNS, que é nova no Windows Server 2016. 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 - Brain, 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, 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 na localização geográfica. 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 Brain, 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 de cérebro
para Active Directory zonas integradas ou para zonas em servidores DNS autônomos.
Aplica. 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.

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 de cliente representa uma sub-rede IPv4 ou IPv6 da qual
as consultas são enviadas a um servidor DNS. Você pode criar sub-redes para definir posteriormente as
políticas a serem aplicadas com base em qual sub-rede as solicitações vêm. Por exemplo, em um cenário
de DNS de divisão Brain, a solicitação de resolução para 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 da recursão: 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. 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 devem ser usados e se a recursão deve ser usada.
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 de 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 de DNS são divididas por nível e tipo. Você pode usar as 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 no nível da zona.
Políticas de resolução de consulta
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 DESC RIÇ Ã O VA LO RES P O SSÍ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 processamento Quando uma consulta é classificada -Valor numérico

por nível e aplica-se a, o servidor -Valor exclusivo por política que
encontra a primeira política para a qual contém o mesmo nível e aplica-se ao
a consulta corresponde aos critérios e valor
a aplica à consulta

Ação Ação a ser executada pelo servidor -Permitir (padrão para nível de zona)
DNS -Deny (padrão no nível do servidor)
-Ignorar

Critérios Condição de política (AND/OR) e lista -Operador-condição (AND/OR)

de critérios a serem atendidos para -Lista de critérios (consulte a tabela
que a política seja aplicada critério abaixo)
 CAMPO DESC RIÇ Ã O
Escopo Lista de escopos de zona e valores
ponderados por escopo. Valores
ponderados são usados para
distribuição de balanceamento de
carga. Por exemplo, se essa lista incluir
Datacenter1 com peso de 3 e
datacenter2 com um peso de 5, o
servidor responderá com um registro
de datacentre1 três vezes em oito
solicitações
NOTE
As políticas de nível de servidor só podem ter os valores negar ou ignorar como uma ação.
O campo de critérios de política DNS é composto por dois elementos:
NOME DESC RIÇ Ã 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 transpor te Protocolo de transporte usado na
consulta. As entradas possíveis são
UDP e TCP
Protocolo IP Protocolo de rede usado na consulta.
As entradas possíveis são IPv4 e IPv6
Endereço IP da interface do Endereço IP para a interface de rede
ser vidor do servidor DNS de entrada
FQDN FQDN do registro na consulta, com a
possibilidade de usar um curinga
Tipo de consulta Tipo de registro que está sendo
consultado (A, SRV, TXT)
VA LO RES P O SSÍVEIS
-Lista de escopos de zona (por nome)
e pesos
VA LO RES DE EXEM P LO
- EQ, Espanha, França -resolve para
verdadeiro se a sub-rede for
identificada como Espanha ou França
- Ne, Canadá, México -resolve para
verdadeiro se a sub-rede do cliente for
qualquer sub-rede diferente do
Canadá e do México
- EQ, TCP
- EQ, UDP
- EQ, IPv4
- EQ, IPv6
- EQ, 10.0.0.1
- EQ, 192.168.1.1
- EQ, www. contoso. com -resolve
para verdadeiro somente se a consulta
estiver tentando resolver o FQDN do
www.contoso.com
- EQ, * . contoso.com, * .
Woodgrove.com -resolve para
verdadeiro se a consulta for para
qualquer registro que termina em *
contoso.com *ou Woodgrove.com
- EQ, txt, SRV -resolve para
verdadeiro se a consulta estiver
solicitando um registro txt ou SRV
- EQ, MX -resolve para verdadeiro se
a consulta estiver solicitando um
registro MX
 NOME DESC RIÇ Ã O VA LO RES DE EXEM P LO

Hora do dia Hora do dia em que a consulta é - EQ, 10:00-12:00, 22:00-23:00 -

recebida resolve para verdadeiro se a consulta
for recebida entre 10 a.m. e meio-dia,
ou entre 19:10 e 23h

Usando a tabela acima como ponto de partida, a tabela a seguir pode ser usada para definir um critério que é
usado para fazer a correspondência de consultas de qualquer tipo de registro, mas SRV registros no domínio
contoso.com provenientes de um cliente na sub-rede 10.0.0.0/24 via TCP entre 8 e 10 PM por meio da interface
10.0.0.3:

NOME VA LO R

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
as 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 consultas atinge o caminho de recursão Você pode escolher um valor de
negar ou ignorar 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 de divisão-cérebro. Nessa
configuração, o servidor DNS executa a recursão para um conjunto de clientes para uma consulta, enquanto o
servidor DNS não executa 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 DESC RIÇ Ã O

Aplicar na recursão Especifica que essa política só deve ser usada para recursão.

Escopo da recursão Nome do escopo de recursão.

NOTE
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 seu
servidor DNS. Você pode criar políticas para transferência de zona no nível do servidor ou no nível da 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.

NOTE
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 de nível de 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
as consultas de entrada da seguinte maneira:
Gerenciando políticas DNS
Você pode criar e gerenciar políticas DNS usando o PowerShell. Os exemplos a seguir passam por diferentes
cenários de exemplo que você pode configurar por meio de políticas de DNS:
Gerenciamento de tráfego
Você pode direcionar o tráfego com base em um FQDN para servidores diferentes, dependendo do local 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 da América do Norte 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 de cliente para América do Norte e Europa. As
duas linhas depois dessa criam um escopo de zona dentro do domínio contoso.com, uma para cada região. As
duas linhas depois dessa criam um registro em cada zona que associa ww.contoso.com a um endereço IP
diferente, um para a Europa, outro para América do Norte. Por fim, as últimas linhas do script criam duas
políticas de resolução de consulta DNS, uma para ser aplicada à sub-rede América do Norte, outra para a sub-
rede da Europa.
Bloquear consultas para um domínio
Você pode usar uma política de resolução de consulta DNS para bloquear consultas a 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, em seguida, 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 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, ao mesmo tempo em que é desabilitado para clientes
externos em um cenário de divisão Brain.

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 chamado de "." (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 quaisquer
consultas provenientes 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 bloqueio de 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 provenientes de uma interface de 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
Usar política de DNS para gerenciamento de tráfego baseado em localização 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 implantação de DNS
Use 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

Usando a política DNS em Read-Only controladores de domínio

A política DNS é compatível com Read-Only controladores de domínio. 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 que podem ser escritos.
 Usar política de DNS para gerenciamento de
tráfego baseado em localização geográfica com
servidores primários
11/08/2021 • 9 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber como configurar a política DNS para permitir que servidores DNS
primá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.

IMPORTANT
Este cenário ilustra como implantar a política DNS para o gerenciamento de tráfego baseado na localização geográfica
quando você estiver usando somente servidores DNS primários. Você também pode realizar o gerenciamento de tráfego
baseado na 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, em seguida, conclua as etapas que são fornecidas no
tópico usar política DNS para gerenciamento de tráfego baseado em Geo-Location com implantações de Primary-
Secondary.

Com as novas políticas de DNS, você pode criar uma política DNS que permite que o servidor DNS responda a
uma consulta de cliente solicitando o endereço IP de um servidor Web. As instâncias do servidor Web podem
estar localizadas em data centers diferentes em locais físicos diferentes. O DNS pode avaliar os locais do cliente
e do servidor Web e, em seguida, responder à solicitação do cliente, fornecendo ao cliente um endereço IP do
servidor Web para um servidor Web localizado fisicamente mais próximo 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 transpor te . 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 ser vidor . 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 (e/ou) 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 descarta a consulta silenciosamente.
Negar . O servidor DNS responde a consulta com uma resposta de falha.
Permitir . O servidor DNS responde de volta com a resposta gerenciada de tráfego.
Exemplo de gerenciamento de tráfego baseado na localização
geográfica
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: serviços de nuvem da Contoso, que fornecem soluções de
Hospedagem de domínio e Web; e os serviços do Woodgrove Food, que fornecem serviços de entrega de
alimentos em várias cidades em todo o mundo e que tem um site chamado woodgrove.com.
Os serviços de nuvem da Contoso têm dois data centers, um nos EUA e outro na Europa. O datacenter Europeu
hospeda um portal de pedidos de alimentos para woodgrove.com.
Para garantir que os clientes do woodgrove.com tenham uma experiência responsiva de seu site, o Woodgrove
quer clientes europeus direcionados para o datacenter Europeu e os clientes norte-americanos direcionados
para o datacenter dos EUA. Os clientes localizados em outro lugar do mundo podem ser direcionados para um
dos datacenters.
A ilustração a seguir descreve 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 nomes DNS que é enviada para o servidor DNS que é 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 de LDNS, o servidor LDNS encaminhará a consulta para o
servidor DNS 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 ao computador do usuário.
Como os serviços de nuvem da Contoso usam políticas de servidor DNS, o servidor DNS autoritativo que
hospeda o contoso.com é configurado para retornar respostas gerenciadas de tráfego com base na localização
geográfica. Isso resulta na direção dos clientes europeus para o datacenter Europeu e na direção dos clientes
norte-americanos para o datacenter dos EUA, conforme ilustrado 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, o uso do endereço IP do servidor LDNS quando você configura as
respostas de consulta baseadas na 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.

NOTE
As políticas de 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 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 as sub-redes do cliente DNS
2. Criar os escopos da zona
3. Adicionar registros aos escopos de zona
4. Criar as políticas

NOTE
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.

IMPORTANT
as seções a seguir incluem exemplo Windows PowerShell comandos que contêm valores de exemplo para muitos
parâmetros. Certifique-se de substituir 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

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 Europa, precisará
identificar as sub-redes ou os espaços de endereço IP dessas regiões.
Você pode obter essas informações de mapas de IP geográfico. Com base nessas distribuições de IP geográfico,
você deve criar as "sub-redes de cliente DNS". Uma sub-rede de cliente DNS é um agrupamento lógico de sub-
redes IPv4 ou IPv6 do qual as consultas são enviadas a um servidor DNS.
você pode usar os seguintes comandos de Windows PowerShell para criar sub-redes de cliente DNS.

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 de cliente são configuradas, você deve particionar a zona cujo tráfego você deseja
redirecionar em dois escopos de zona diferentes, um escopo para cada uma das sub-redes de cliente DNS que
você configurou.
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.

NOTE
Por padrão, um escopo de zona existe nas zonas DNS. Esse escopo de zona tem o mesmo nome que a zona e as
operações de DNS herdadas funcionam nesse escopo.

você pode usar os seguintes comandos de Windows PowerShell para criar escopos de zona.

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 escopos de duas zonas.
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 de zona.

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "192.0.0.1" -ZoneScope

"USZoneScope
Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "141.1.0.1" -ZoneScope
"EuropeZoneScope"

neste exemplo, você também deve usar os comandos de Windows PowerShell a seguir para adicionar registros
ao escopo de zona padrão para garantir que o restante do mundo ainda possa acessar o servidor web
woodgrove.com de qualquer um dos dois data centers.

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "192.0.0.1"

Add-DnsServerResourceRecord -ZoneName "woodgrove.com" -A -Name "www" -IPv4Address "141.1.0.1"

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
conectam as sub-redes e as partições, de modo que quando uma consulta vier de uma origem em uma das sub-
redes de cliente DNS, a resposta de consulta será retornada do escopo correto da zona. Nenhuma política é
necessária para mapear o escopo de zona padrão.
você pode usar os seguintes comandos de Windows PowerShell para criar uma política DNS que vincula as sub-
redes do cliente DNS e os escopos de zona.

Add-DnsServerQueryResolutionPolicy -Name "USPolicy" -Action ALLOW -ClientSubnet "eq,USSubnet" -ZoneScope

"USZoneScope,1" -ZoneName "woodgrove.com"
Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -
ZoneScope "EuropeZoneScope,1" -ZoneName "woodgrove.com"

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

Agora, o servidor DNS é 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 de 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 de zona associado será usado para
responder à consulta e o usuário será direcionado para o recurso que está geograficamente mais próximo.
Você pode criar milhares de políticas de 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 gerenciamento de
tráfego baseado em localização geográfica com
implantações primárias e secundárias
13/08/2021 • 9 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber como criar uma política DNS para o 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-Locationcom servidores
primários, forneceu instruções para configurar a política DNS para o gerenciamento de tráfego baseado em
localização geográfica em um servidor DNS primário. Na infraestrutura de Internet, no entanto, os servidores
DNS são amplamente implantados em um modelo primário-secundário, em que a cópia que pode ser gravada
de uma zona é armazenada em servidores primários selecionados e seguros, e as 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 IXFR
(Transferência Incremental de Zona) para solicitar e receber atualizações de zona que incluem novas alterações
nas zonas nos servidores DNS primários.

NOTE
Para obter mais informações sobre o AXFR, consulte a IETF (Internet Engineering Task Force) Request for Comments 5936.
Para obter mais informações sobre o IXFR, consulte a Solicitação de IETF (Internet Engineering Task Force) para
Comentários 1995.

Primary-Secondary Geo-Location gerenciamento de tráfego baseado

em dados
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 – Serviços de Nuvem da Contoso, que fornece soluções web e de
hospedagem de domínio; e o 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 recebam uma experiência responsiva de seu site, a Woodgrove
deseja clientes europeus direcionados para o datacenter europeu e clientes americanos direcionados para o
datacenter dos EUA. Os clientes localizados em outro lugar do mundo podem ser direcionados para qualquer
um dos datacenters.
Os Serviços de Nuvem da Contoso têm dois datacenters, um nos EUA e outro na Europa, nos quais a Contoso
hospeda seu portal de pedidos de alimentos para woodgrove.com.
A implantação do DNS da Contoso inclui dois servidores secundários: Secondar ySer ver1 , com o endereço IP
10.0.0.2; e Secondar ySer ver2 , com o endereço IP 10.0.0.3. Esses servidores secundários estão atuando como
servidores de nomes em duas regiões diferentes, com SecondaryServer1 localizado na Europa e
SecondaryServer2 localizado nos EUA.
Há uma cópia de zona principal que pode ser escrita no Primar ySer ver (endereço IP 10.0.0.1), em que as
alterações de zona são feitas. Com as transferências de zona regulares para os servidores secundários, os
servidores secundários estão sempre atualizados com as novas alterações na zona no PrimaryServer.
A ilustração a seguir ilustra esse cenário.

Como o sistema Primary-Secondary DNS funciona

Quando você implanta o gerenciamento de tráfego baseado em localização geográfica em uma implantação de
DNS primária secundária, é importante entender como as transferências normais de zona primária-secundária
ocorrem antes de aprender sobre transferências no nível do escopo da zona. As seções a seguir fornecem
informações sobre transferências no nível de escopo de zona e zona.
Transferências de zona em uma implantação dns primária-secundária
Transferências no nível do escopo da zona em uma implantação primária-secundária do DNS
Transferências de zona em uma implantação dns primária-secundária
Você pode criar uma implantação dns primária-secundária 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 aos 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 no nível do escopo da 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 escopos de zona
diferentes. Por isso, etapas adicionais são necessárias para transferir os dados dentro dos escopos de zona para
os servidores secundários e para 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 no nível
do escopo da zona são executadas automaticamente pelo DNS, usando os processos a seguir.
Para garantir a transferência no nível do escopo da zona, os servidores DNS usam os Mecanismos de Extensão
para DNS (EDNS0) OPT RR. Todas as solicitações de transferência de zona (AXFR ou IXFR) das zonas com
escopos são originadas com um EDNS0 OPT RR, cuja ID de opção é definida como "65433" por padrão. Para
obter mais informações sobre 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 proveniente desse 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 atualizem 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 essa
solicitação de escopo de zona para notificações.
Para qualquer atualização adicional em um escopo de zona, uma notificação IXFR é enviada aos servidores
secundários, com o mesmo OPT RR. O escopo de zona que recebe essa notificação faz com que a solicitação
IXFR contenha essa OPT RR e o mesmo processo descrito acima a seguir.

Como configurar a política DNS para o gerenciamento de tráfego

Primary-Secondary Geo-Location com base em dados
Antes de começar, verifique se você concluiu todas as etapas no tópico Usar política DNSpara gerenciamento de
tráfego baseado em Geo-Location 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.

NOTE
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 de DNS iniciais. No futuro, talvez você queira
alterar as configurações de sub-redes, escopos de zona e políticas do cliente DNS 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, você deve executar as etapas a seguir.
Criar as zonas secundárias
Configurar o Configurações zona na zona primária
Copiar as sub-redes do cliente DNS
Criar os escopos de zona no servidor secundário
Configurar política DNS
As seções a seguir fornecem instruções de configuração detalhadas.
 IMPORTANT
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.
A associação em DnsAdmins ou equivalente é necessária para executar os procedimentos a seguir.

Criar as zonas secundárias

Você pode criar a cópia secundária da zona que deseja replicar para SecondaryServer1 e SecondaryServer2
(supondo que os cmdlets estão sendo executados remotamente de um único cliente de gerenciamento).
Por exemplo, você pode criar a cópia secundária do www.woodgrove.com em SecondaryServer1 e
SecondarySesrver2.
Você pode usar os comandos Windows PowerShell a seguir para criar as zonas secundárias.

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 zona na zona primária
Você deve definir as configurações de zona primária para que:
1. 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.

NOTE
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 seleção de secundários.

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.

Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-DnsServerClientSubnet -ComputerName

SecondaryServer1
Get-DnsServerClientSubnet -ComputerName PrimaryServer | Add-DnsServerClientSubnet -ComputerName
SecondaryServer2
Para obter mais informações, consulte Add-DnsServerClientSubnet.
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ção incremental.
Você pode usar os comandos Windows PowerShell a seguir para criar os escopos de zona nos servidores
secundários.

Get-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName PrimaryServer|Add-DnsServerZoneScope -

ZoneName "woodgrove.com" -ComputerName SecondaryServer1 -ErrorAction Ignore
Get-DnsServerZoneScope -ZoneName "woodgrove.com" -ComputerName PrimaryServer|Add-DnsServerZoneScope -
ZoneName "woodgrove.com" -ComputerName SecondaryServer2 -ErrorAction Ignore

NOTE
Nesses comandos de exemplo, o parâmetro -ErrorAction Ignore está incluído, porque existe um escopo de zona
padrão em cada zona. O escopo de 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.

Para obter mais informações, consulte Add-DnsServerZoneScope.

Configurar política DNS
Depois de criar as sub-redes, as partições (escopos de zona) e adicionar registros, você deve criar políticas que
conectam as sub-redes e partições, de modo que, quando uma consulta vem de uma origem em uma das sub-
redes do cliente DNS, a resposta da consulta é retornada do escopo correto da zona. Nenhuma política é
necessária para mapear o escopo de zona padrão.
Você pode usar os comandos Windows PowerShell a seguir para criar uma política DNS que vincula as sub-
redes do cliente DNS e os escopos de zona.

$policy = Get-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName PrimaryServer

$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName SecondaryServer1
$policy | Add-DnsServerQueryResolutionPolicy -ZoneName "woodgrove.com" -ComputerName SecondaryServer2

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

Agora, os servidores DNS secundários estão configurados com as políticas 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 de zona associado será usado para
responder à consulta e o usuário será direcionado para o recurso geograficamente mais próximo a eles.
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 a política de DNS para respostas de DNS
inteligente com base na hora do dia
13/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para aprender a distribuir o tráfego de aplicativo 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, localizados em outro fuso horário. Isso permite balancear a carga
do tráfego entre instâncias de aplicativo durante períodos 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 presentes online em
todo o mundo por meio de seu site, contosogiftservices.com.
O contosogiftservices.com Web está 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 conhecimento 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.
O Contoso Gift Services executa uma análise de site e descobre que todas as tardes entre 18h e 21h no horário
local, 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 europeu e americano. Em outros
momentos do dia, os servidores lidam com volumes de tráfego que estão bem abaixo de sua capacidade
máxima.
Para garantir que contosogiftservices.com clientes recebam 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 algum tráfego de Seattle para os servidores de aplicativos de Dublin
entre 18h e 21h em Seattle.
A ilustração a seguir ilustra esse cenário.
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 localização
geográfica, o servidor DNS faz o seguinte.
Responde às quatro primeiras consultas que ele recebe com o endereço IP do servidor Web no datacenter
local.
Responde à quinta consulta que recebe com o endereço IP do servidor Web no datacenter remoto.
Esse comportamento baseado em políticas descarrega 20% da carga de tráfego do servidor Web local para o
servidor Web remoto, endossando a tensão no servidor de aplicativos local e melhorando o desempenho do
site para os clientes.
Fora do 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 América do Norte
ou Europa, o servidor DNS balanceia 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 prioridade mais baixa. 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
prioridade mais alta. Se você criar políticas de hora do dia e der a elas alta prioridade na lista de políticas, o DNS
processa e usa essas políticas primeiro se elas corresponderem aos parâmetros da consulta do cliente DNS e
aos critérios definidos na política. Se eles não corresponderem, o DNS move para baixo a lista de políticas para
processar as políticas padrão até encontrar uma combinação.
Para obter mais informações sobre tipos e critérios de política, consulte Visão geral das políticas 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 no balanceamento de carga do aplicativo de
hora do dia, você deve executar as etapas a seguir.
Criar as sub-redes do cliente DNS
Criar os escopos de zona
Adicionar registros aos escopos de zona
 Criar as políticas DNS

NOTE
Você deve executar essas etapas no servidor DNS autoritativo para a zona que você 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.

IMPORTANT
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

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 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.

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"

Para obter mais informações, consulte Add-DnsServerClientSubnet.

Criar os escopos de zona
Depois que as sub-redes do cliente são configuradas, você deve 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 que
você configurou.
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.
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.

NOTE
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 herddas funcionam nesse escopo.

Você pode usar os comandos Windows PowerShell a seguir para criar escopos de zona.

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "SeattleZoneScope"

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DublinZoneScope"

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, no SeattleZoneScope , o registro www.contosogiftser vices.com é adicionado com o endereço
IP 192.0.0.1, que está localizado em um datacenter de Seattle. Da mesma forma, no DublinZoneScope, o
registro www.contosogiftser vices.com é adicionado com o endereço IP 141.1.0.3 no datacenter de Dublin
Você pode usar os comandos Windows PowerShell a seguir para adicionar registros aos escopos de zona.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.0.0.1" -

ZoneScope "SeattleZoneScope

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "141.1.0.3" -

ZoneScope "DublinZoneScope"

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 DNS
Depois de criar as sub-redes, as partições (escopos de zona) e adicionar registros, você deve criar políticas que
conectam as sub-redes e partições, de modo que, quando uma consulta vem de uma origem em uma das sub-
redes do cliente DNS, a resposta da consulta é retornada do escopo correto da zona. Nenhuma política é
necessária para mapear o escopo de zona 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 restante 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 Windows PowerShell a seguir para criar uma política DNS que vincula as sub-
redes do cliente DNS e os escopos de zona.

NOTE
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.
 Add-DnsServerQueryResolutionPolicy -Name "America6To9Policy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet"
-ZoneScope "SeattleZoneScope,4;DublinZoneScope,1" -TimeOfDay "EQ,01:00-04:00" -ZoneName
"contosogiftservices.com" -ProcessingOrder 1

Add-DnsServerQueryResolutionPolicy -Name "Europe6To9Policy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -

ZoneScope "SeattleZoneScope,1;DublinZoneScope,4" -TimeOfDay "EQ,17:00-20:00" -ZoneName
"contosogiftservices.com" -ProcessingOrder 2

Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -

ZoneScope "SeattleZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 3

Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -

ZoneScope "DublinZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 4

Add-DnsServerQueryResolutionPolicy -Name "RestOfWorldPolicy" -Action ALLOW --ZoneScope

"DublinZoneScope,1;SeattleZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 5

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

Agora, o servidor DNS está configurado com as políticas DNS necessárias para redirecionar o tráfego com base
na localização geográfica e na hora do dia.
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 de zona associado será usado para
responder à consulta e o usuário será direcionado para o recurso geograficamente mais próximo a eles.
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.
 Respostas de DNS com base na hora do dia com o
Servidor de aplicativos da nuvem do Azure
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para aprender a distribuir o tráfego de aplicativo 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, localizados em outro fuso
horário. Isso permite balancear a carga do tráfego entre instâncias de aplicativo durante períodos de pico
quando os servidores primários estão sobrecarregados com o tráfego.

NOTE
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 de 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 presentes online em
todo o mundo por meio de seu site, contosogiftservices.com.
O contosogiftservices.com site é hospedado somente 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.
O Contoso Gift Services executa uma análise de site e descobre que todas as tardes entre 18h e 21h no horário
local, há um aumento no tráfego para o servidor Web de Seattle. O servidor Web não pode dimensionar 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 recebam uma experiência responsiva do site, a Contoso Gift
Services decide que, durante essas horas, ele alugará uma VM de máquina virtual no Microsoft Azure para
hospedar uma cópia de seu ( ) servidor Web.
O 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.
 NOTE
Para obter mais informações sobre VMs do Azure, consulte a documentação de Máquinas Virtuais

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.
A ilustração a seguir ilustra esse cenário.

Como as respostas DNS inteligentes com base na hora do dia com

Azure App Server funcionam
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 s meio por cento das respostas DNS para clientes que contêm o endereço IP do servidor
Web de Seattle e 30% das respostas DNS para clientes que contêm o endereço IP do servidor Web do Azure,
Dessa forma, direciona o tráfego do cliente para o novo servidor Web do Azure e impede que o servidor Web
de Seattle se torne sobrecarregado.
Em todos os outros horários do dia, o processamento normal de consulta 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 expirou 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 escalando para o Azure conforme a demanda exige.

Como configurar a política DNS para respostas DNS inteligentes com

base na hora do dia com Azure App Server
Para configurar a política DNS para respostas de consulta baseadas no balanceamento de carga do aplicativo de
hora do dia, você deve executar as etapas a seguir.
Criar os escopos de zona
Adicionar registros aos escopos de zona
Criar as políticas DNS

NOTE
Você deve executar essas etapas no servidor DNS autoritativo para a zona que você 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.

IMPORTANT
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 os escopos de zona

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.

NOTE
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 herddas funcionam nesse escopo.

Você pode usar o comando de exemplo a seguir para criar um escopo de zona para hospedar os registros do
Azure.

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "AzureZoneScope"

Para obter mais informações, consulte Add-DnsServerZoneScope

Adicionar registros aos escopos de zona
A próxima etapa é adicionar os registros que representam o host do servidor Web aos escopos de 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, o TTL do registro para VMs do Azure é mantido em 600s (10 minutos) para que o LDNS não o
coloque 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.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.68.31.44" -

ZoneScope "AzureZoneScope" –TimeToLive 600

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.68.30.2"

Para obter mais informações, consulte Add-DnsServerResourceRecord.

Criar as políticas DNS
Depois que os escopos de zona são criados, você pode criar políticas DNS que distribuem 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

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

Agora, o servidor DNS está configurado com as políticas DNS necessárias para 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 uma combinação ZoneScope e peso que instrui o servidor DNS a
enviar o endereço IP do servidor Web de Seattle por cento do tempo, ao enviar o endereço IP do servidor Web
do Azure 30% do tempo.
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 a política DNS para a implantação de DNS de
divisão - Brain
13/08/2021 • 9 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para aprender a configurar a política dns no Windows Server ® 2016 para
implantações de dns de divisão-brain, 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.

NOTE
Para obter informações sobre como usar a política DNS para a implantação de DNS de divisão - Brain com Active
Directory zonas DNS integrado, consulte usar a política dns para Split-Brain DNS no Active Directory.

Anteriormente, esse cenário exigia que os administradores de DNS mantenham dois servidores DNS diferentes,
cada um fornecendo serviços a cada conjunto de usuários, interno e externo. Se apenas alguns registros dentro
da zona tiverem sido reduzidos - ou se ambas as instâncias da zona (internas e externas) tiverem sido delegadas
para o mesmo domínio pai, isso se tornaria um enigma de gerenciamento.
Outro cenário de configuração para implantação de divisão-Brain é o controle de recursão seletiva para a
resolução de nomes DNS. em algumas circunstâncias, espera-se que os servidores DNS Enterprise executem a
resolução recursiva pela Internet para os usuários internos, enquanto eles também devem atuar como
servidores de nome autoritativo para usuários externos e bloquear a recursão para eles.
Este tópico inclui as seções a seguir.
Exemplo de implantação de Split-Brain de DNS
Exemplo de controle de recursão seletiva de DNS

Exemplo de implantação de Split-Brain de DNS

Veja a seguir um exemplo de como você pode usar a política de DNS para realizar o cenário descrito
anteriormente de DNS de divisão-cérebro.
Esta seção contém os seguintes tópicos.
Como funciona a implantação do DNS Split-Brain
Como configurar a implantação de Split-Brain de DNS
Este exemplo usa uma empresa fictícia, 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 da política DNS, o administrador precisa hospedar essas duas zonas em servidores DNS do
Windows Server separados e gerenciá-las separadamente.
Usando políticas DNS essas zonas agora podem ser hospedadas no mesmo servidor DNS.
A ilustração a seguir descreve esse cenário.

Como funciona a implantação do DNS Split-Brain

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 corresponde a qualquer uma das políticas, o escopo de
zona associado é 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 que são
recebidas na interface de rede pública recebem uma resposta DNS que contém o endereço IP público no escopo
de zona padrão (isso é o mesmo que a resolução de consulta normal).

Como configurar a implantação de Split-Brain de DNS

Para configurar a implantação de Split-Brain de DNS usando a política DNS, você deve usar as etapas a seguir.
Criar os escopos de zona
Adicionar registros aos escopos de zona
Criar as políticas de DNS
As seções a seguir fornecem instruções de configuração detalhadas.
 IMPORTANT
as seções a seguir incluem exemplo Windows PowerShell comandos que contêm valores de exemplo para muitos
parâmetros. Certifique-se de substituir os valores de exemplo nesses comandos por valores apropriados para sua
implantação antes de executar esses comandos.

Criar os escopos de zona

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.

NOTE
Por padrão, um escopo de zona existe nas zonas DNS. Esse escopo de zona tem o mesmo nome que a zona e as
operações de DNS herdadas funcionam nesse escopo. Esse escopo de zona padrão hospedará a versão externa do
www.career.contoso.com.

Você pode usar o seguinte comando de exemplo para particionar o escopo de 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"

Para obter mais informações, consulte Add-DnsServerZoneScope

Adicionar registros aos escopos de zona
A próxima etapa é adicionar os registros que representam o host do servidor Web nos escopos de duas zonas-
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.
Não , o parâmetro – ZoneScope é fornecido nos comandos de exemplo a seguir quando o registro está
sendo adicionado ao escopo de zona padrão. Isso é semelhante à adição de registros a uma zona de baunilha.
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10"
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39” -ZoneScope
"internal"

Para obter mais informações, consulte Add-DnsServerResourceRecord.

Criar as políticas de DNS
Depois de identificar as interfaces de servidor para a rede externa e a rede interna e criar os escopos de zona,
você deverá criar políticas de DNS que conectem os escopos de zona interna e externa.

NOTE
Este exemplo usa a interface de servidor como os critérios para diferenciar entre os clientes internos e externos. Outro
método para diferenciar entre clientes externos e internos é usar sub-redes de cliente como um critério. Se você puder
identificar as sub-redes às quais os clientes internos pertencem, você pode 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 o gerenciamento de tráfego baseado em Geo-Location com
servidores primários.
Quando o servidor DNS recebe uma consulta na interface privada, a resposta de consulta DNS é retornada do
escopo da zona interna.

NOTE
Nenhuma política é necessária para mapear o escopo de 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

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

Exemplo de controle de recursão seletiva de 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 seletiva de DNS.
Esta seção contém os seguintes tópicos.
Como funciona o controle de recursão seletiva de DNS
Como configurar o controle de recursão seletiva de 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 DNS Split-Brain, o mesmo servidor DNS responde aos clientes internos e
externos e fornece a eles respostas diferentes.
Algumas implantações de DNS podem exigir que o mesmo servidor DNS execute a resolução de nomes
recursiva 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 de DNS.
nas versões anteriores do Windows Server, a habilitação da recursão significava que ela foi habilitada no
servidor DNS inteiro para todas as zonas. Como o servidor DNS também está ouvindo consultas externas, a
recursão é habilitada para clientes internos e externos, tornando o servidor DNS um resolvedor aberto.
Um servidor DNS configurado como um resolvedor aberto pode estar vulnerável ao esgotamento de recursos e
pode ser abuso por clientes mal-intencionados para criar ataques de reflexo.
Por isso, os administradores de DNS da Contoso não querem que o servidor DNS para contoso.com execute a
resolução de nomes recursiva para clientes externos. Há apenas uma necessidade de controle de recursão para
clientes internos, enquanto o controle de recursão pode ser bloqueado para clientes externos.
A ilustração a seguir descreve esse cenário.
Como funciona o controle de recursão seletiva de DNS
Se uma consulta para a qual o servidor DNS contoso é não autoritativo for recebida, como para
https://www.microsoft.com , 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 no nível da zona, ( conforme definido
no exemplo de divisão-Brain, ) não são avaliadas.
O servidor DNS avalia as políticas de recursão e as consultas que são 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 obter a resposta https://www.microsoft.com da Internet e
armazena a resposta em cache localmente.
Se a consulta for recebida na interface externa, nenhuma política de DNS será correspondente 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 está atuando
como um resolvedor de cache para clientes internos.
Como configurar o controle de recursão seletiva de DNS
Para configurar o controle de recursão seletiva de 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 de DNS
Criar escopos de recursão DNS
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 referenciadas como o escopo de recursão
padrão. Você não pode adicionar ou remover o escopo de recursão padrão, identificado pelo nome ponto ( "." ) .
Neste exemplo, a configuração de recursão padrão é desabilitada, enquanto um novo escopo de recursão para
clientes internos é criado onde a recursão está habilitada.
 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 do servidor DNS para escolher um escopo de recursão para um conjunto
de consultas que corresponderem 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 interno com recursão habilitada está associado ao interface de rede
privada.
Você pode usar o comando de exemplo a seguir para configurar políticas de recursão dns.

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy" -Action ALLOW -ApplyOnRecursion -

RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.39"

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

Agora, o servidor DNS está configurado com as políticas DNS necessárias para um servidor de nomes de dupla
dupla ou um servidor DNS com controle de recursão seletivo habilitado para clientes internos.
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.
Para obter mais informações, consulte Guia do cenário de política dns.
 Usar a política de DNS para DNS com partição de
rede no Active Directory
13/08/2021 • 7 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para aproveitar as funcionalidades de gerenciamento de tráfego de políticas DNS
para implantações duplas com - zonas DNS integradas do Active Directory Windows Server 2016.
No 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 de DNS mantenham 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 (internas e externas) foram delegadas para o
mesmo domínio pai, isso se tornou um conflito de - gerenciamento.

NOTE
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 Usar a Política dns para Split-Brain de DNS explica como você pode usar políticas DNS e escopos de zona para
implantar um sistema DNS de dupla encefálica em um único Windows Server 2016 - DNS.

Exemplo de - DNS split brain no Active Directory

Este exemplo usa uma empresa fictícia, Contoso, que mantém um site de carreira no www.career.contoso.com.
O site tem duas versões, uma para os usuários internos em que as postagem de trabalho internas estão
disponíveis. Esse 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 da política dns, o administrador é necessário para hospedar essas duas zonas em servidores DNS
Windows servidor separados e gerenciá-los 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 dns da Contoso poderá seguir as etapas neste tópico para obter uma
implantação - dividida.
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.
A ilustração a seguir ilustra esse cenário.
Como funciona a política - de DNS para dividir o DNS do Brain no
Active Directory
Quando o servidor DNS é configurado com as políticas DNS necessárias, cada solicitação de resolução de
nomes é 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 de
zona associado será usado para responder à consulta.
Portanto, em nosso exemplo, as consultas DNS para www.career.contoso.com que são 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 no
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 e eliminação de DDNS de DNS dinâmico apenas ( no escopo da zona ) padrão.
Como os clientes internos são atendidos pelo escopo de zona padrão, os Administradores de DNS da Contoso
podem continuar usando os mecanismos existentes (DNS dinâmico ou estático) para atualizar os registros
contoso.com. Para escopos de zona não padrão, como o escopo externo neste - ( exemplo, o DDNS ou o suporte
para limpeza ) não estão disponíveis.
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.

$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 Windows PowerShell referência a seguir.
Get-DnsServerQueryResolutionPolicy
Add-DnsServerQueryResolutionPolicy
Como configurar a política DNS para dividir - o DNS do Brain no
Active Directory
Para configurar a implantação de Split-Brain DNS usando a Política de 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 contoso.com do Active Directory ao
servidor DNS.

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 criar um escopo de zona externa.
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.
Como você está adicionando esse novo escopo de zona em uma zona integrada do Active Directory, o escopo
da zona e os registros dentro dela 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 herddas 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.

Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "external"

Para obter mais informações, consulte Add-DnsServerZoneScope.

Adicionar registros aos escopos de zona
A próxima etapa é adicionar os registros que representam o host do servidor Web aos dois escopos de zona:
externo e padrão ( para clientes ) internos.
No escopo de 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.

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10" -

ZoneScope "external"
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39”
 NOTE
O parâmetro –ZoneScope não é incluído quando o registro é adicionado ao escopo de zona padrão. Essa ação é igual
à adição de registros a uma zona normal.

Para obter mais informações, consulte Add-DnsServerResourceRecord.

Criar as políticas DNS
Depois de identificar as interfaces de servidor para a rede externa e a rede interna e criar os escopos de zona,
você deve criar políticas DNS que conectam os escopos de zona interna e externa.

NOTE
Este exemplo usa a interface do servidor do 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 é
usar sub-redes de cliente como critérios. Se você puder identificar as sub-redes às quais os clientes internos pertencem,
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 política DNS para
gerenciamento de tráfego baseado em Geo-Location 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.

NOTE
Nenhuma política é necessária para mapear o escopo da zona interna padrão.

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface

"eq,208.84.0.53" -ZoneScope "external,1" -ZoneName contoso.com

NOTE
208.84.0.53 é o endereço IP no interface de rede pública.

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

Agora, o servidor DNS está configurado com as políticas DNS necessárias para um servidor de nomes divididos
com uma zona DNS integrada do Active Directory.
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 a Política de DNS para a aplicação de filtros
em consultas DNS
12/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para aprender a configurar a política DNS no Windows Server ® 2016 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.
Por exemplo, você pode configurar a política DNS com a lista de blocos de filtro de consulta que bloqueia
consultas DNS de domínios mal-intencionados conhecidos, o que impede que o DNS responda a consultas
desses domínios. Como nenhuma resposta é enviada do servidor DNS, a consulta DNS do membro do domínio
mal-intencionado atinge o tempo limite.
Outro exemplo é criar uma lista de permissões de filtro de consulta 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 (e/ou/não) dos critérios a seguir.

NOME DESC RIÇ Ã 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 Transporte Protocolo de transporte usado na consulta. Os valores

possíveis são UDP e TCP.

Protocolo IP Protocolo de rede usado na consulta. Os valores 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 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 ( , 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.
 NOTE
os comandos de exemplo neste tópico usam o comando Windows PowerShell Add-DnsSer verQuer yResolutionPolicy .
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 identificados
como mal-intencionados ou para domínios que não estão em conformidade com as diretrizes de uso de sua
organização. Você pode executar consultas de bloqueio para domínios usando a política DNS.
A política que você configura neste exemplo não é criada em nenhuma zona específica – em vez disso, você cria
uma política no nível do 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, devem ser correspondidas primeiro quando
uma consulta é recebida pelo servidor DNS.
O comando de exemplo a seguir configura uma política de nível de servidor para bloquear qualquer consulta
com o sufixo de domínio contosomalicious.com .
Add-DnsServerQueryResolutionPolicy -Name "BlockListPolicy" -Action IGNORE -FQDN "EQ,*.contosomalicious.com" -
PassThru

NOTE
Quando você configura o parâmetro Action com o valor ignore , o servidor DNS é configurado para descartar consultas
sem nenhuma resposta. Isso faz com que o cliente DNS no domínio mal-intencionado expire.

Bloquear consultas de uma sub-rede

Com este exemplo, você pode bloquear consultas de uma sub-rede se ela for considerada infectada 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"-ação 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 infectadas.
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 nos servidores. Por
exemplo, você pode bloquear a consulta ' ANY ', que pode ser usada maliciosamente 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 pode usar apenas a política DNS para bloquear consultas, você pode usá-las para aprovar
automaticamente as consultas de domínios ou sub-redes específicas. Quando você configura listas de
permissões, o servidor DNS processa apenas consultas de domínios permitidos, ao mesmo tempo que 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 permissões 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 permissão a QTYPEs.
Por exemplo, se você tiver clientes externos consultando a interface do servidor DNS 164.8.1.1, somente certas
QTYPEs poderão ser consultadas, enquanto há 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

Você pode criar milhares de políticas de 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 a Política de DNS para balanceamento de
carga de aplicativo
12/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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ó forneceam balanceamento de carga usando round robin
respostas; mas com DNS no Windows Server 2016, você pode configurar a política DNS para 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 de 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 presentes online e que
tem um site chamado contosogiftser vices.com .
O contosogiftservices.com site é hospedado em vários datacenters que têm endereços IP diferentes.
No América do Norte, que é o principal mercado dos Serviços contoso Gift, 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 duas vezes mais carga do
que os outros dois sites. Os Serviços de Presentes da Contoso querem que o tráfego de aplicativos seja
direcionado da maneira a seguir.
Como o servidor Web de Seattle inclui mais recursos, metade dos clientes do aplicativo são direcionados
para esse servidor
Um quarto dos clientes do aplicativo é direcionado para o datacenter Dallas, TX
Um quarto dos clientes do aplicativo é direcionado para Chicago, IL, datacenter
A ilustração a seguir ilustra esse cenário.
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.
Portanto, 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 pelo resolvedor/LDNS, que pode 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 de TTL de vida de vida baixa para os
registros DNS que - - devem ter ( ) balanceador de carga.
Como configurar o balanceamento de carga do aplicativo
As seções a seguir mostram como configurar a política DNS para balanceamento de carga do aplicativo.
Criar os escopos de zona
Primeiro, você deve criar os escopos da zona contosogiftservices.com para os datacenters em que eles estão
hospedados.
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.

NOTE
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 herddas funcionam nesse escopo.

Você pode usar os comandos Windows PowerShell a seguir para criar escopos de zona.
 Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "SeattleZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DallasZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "ChicagoZoneScope"

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 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 no DallasZoneScope, você pode adicionar um registro www.contosogiftservices.com com o
endereço ( ) IP 162.0.0.1 no datacenter de Chicago.
Você pode usar os comandos Windows PowerShell a seguir para adicionar registros aos escopos de zona.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "192.0.0.1" -

ZoneScope "SeattleZoneScope"
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "182.0.0.1" -
ZoneScope "ChicagoZoneScope"
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "162.0.0.1" -
ZoneScope "DallasZoneScope"

Para obter mais informações, consulte Add-DnsServerResourceRecord.

Criar as políticas DNS
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 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 chicago e Dallas.
Você pode usar os comandos Windows PowerShell a seguir para criar uma política DNS que equilibra o tráfego
de aplicativos entre esses três datacenters.

NOTE
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 de parâmetros <ZoneScope> , <weight> .

Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -ZoneScope

"SeattleZoneScope,2;ChicagoZoneScope,1;DallasZoneScope,1" -ZoneName "contosogiftservices.com"

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

Agora você criou com êxito uma política DNS que fornece balanceamento de carga de aplicativo entre
servidores Web em três datacenters diferentes.
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 a Política de DNS para balanceamento de
aplicativo com reconhecimento de localização
geográfica
12/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 DNSpara Balanceamento de Carga de Aplicativo, 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.

NOTE
É 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 aplicativos distribuído entre servidores Web localizados em Dublin, Irlanda, 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.
 IMPORTANT
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.

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

Para obter mais informações, consulte Add-DnsServerClientSubnet.

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.
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.

NOTE
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 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.
Você pode usar os comandos Windows PowerShell a seguir para criar escopos de zona.

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "DublinZoneScope"

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name "AmsterdamZoneScope"

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 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.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "151.1.0.1" -

ZoneScope "DublinZoneScope”
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name "www" -IPv4Address "141.1.0.1" -
ZoneScope "AmsterdamZoneScope"

Para obter mais informações, consulte Add-DnsServerResourceRecord.

Criar as políticas DNS
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.

Add-DnsServerQueryResolutionPolicy -Name "AmericaLBPolicy" -Action ALLOW -ClientSubnet "eq,AmericaSubnet" -

ZoneScope "SeattleZoneScope,2;ChicagoZoneScope,1; TexasZoneScope,1" -ZoneName "contosogiftservices.com" –
ProcessingOrder 1
Add-DnsServerQueryResolutionPolicy -Name "EuropeLBPolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -
ZoneScope "DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName "contosogiftservices.com" -ProcessingOrder 2
Add-DnsServerQueryResolutionPolicy -Name "WorldWidePolicy" -Action ALLOW -FQDN "eq,*.contoso.com" -ZoneScope
"SeattleZoneScope,1;ChicagoZoneScope,1; TexasZoneScope,1;DublinZoneScope,1;AmsterdamZoneScope,1" -ZoneName
"contosogiftservices.com" -ProcessingOrder 3

Para obter mais informações, consulte Add-DnsServerQueryResolutionPolicy.

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.
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.
 Solução de problemas de DNS (Sistema de Nomes
de Domínio)
13/08/2021 • 2 minutes to read

Problemas de resolução de nome de domínio podem ser divididos em problemas do lado do cliente e 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 scoping que o problema está definitivamente ocorrendo no lado do servidor.
Solução de problemas de clientes DNS
Solução de problemas de 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 Windows de rede de um cliente afetado e seu servidor DNS configurado, siga estas etapas:
1. Iniciar capturas de rede no cliente e no servidor:

netsh trace start capture=yes tracefile=c:\%computername%_nettrace.etl

2. Limpe o cache DNS no cliente DNS executando o seguinte comando:

ipconfig /flushdns

3. Reproduza o problema.
4. Parar e salvar rastreamentos:

netsh trace stop

5. Salve os 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
12/08/2021 • 2 minutes to read

Este artigo discute como solucionar problemas de clientes DNS.

Verificar a configuração de IP
1. Abra uma janela do Prompt de Comando como administrador no computador cliente.
2. Execute o comando a seguir:

ipconfig /all

3. Verifique se o cliente tem um endereço IP válido, uma máscara de sub-rede e um gateway padrão para a
rede à qual ele está anexado 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 TCP/IP válida, use um dos seguintes métodos:
Para clientes configurados dinamicamente, use o comando para forçar manualmente o cliente a renovar
sua configuração de endereço ipconfig /renew IP com o servidor DHCP.
Para clientes configurados estaticamente, modifique as propriedades TCP/IP do cliente para usar
definições de configuração válidas ou conclua sua configuração de DNS para a rede.

Verificar a conexão de rede

Teste de ping
Verifique se o cliente pode entrar em contato com um servidor DNS preferencial (ou alternativo) pingando o
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:

ping 10.0.0.1

Se nenhum servidor DNS configurado responder a um ping direto de seu endereço IP, isso indicará que a
origem do problema é mais provável 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 fazer ping no computador do servidor DNS, tente usar os comandos a seguir para testar
se o servidor nslookup pode responder a clientes DNS. Como nslookup não usa o cache DNS do cliente, a
resolução de nomes usará o servidor DNS configurado do cliente.
Testar um cliente
 nslookup <client>

Por exemplo, se o computador cliente for chamado client1 , execute este comando:

nslookup client1

Se uma resposta bem-sucedida não for retornada, tente executar o seguinte comando:

nslookup <fqdn of client>

Por exemplo, se o FQDN for client1.corp.contoso.com , execute este comando:

nslookup client1.corp.contoso.com.

NOTE
Você deve incluir o período à parte final ao executar esse teste.

Se Windows encontrar o FQDN com êxito, mas não for possível encontrar o nome curto, verifique a
configuração do Sufixo DNS na guia DNS da guia TCP/IP avançado Configurações da NIC. Para obter mais
informações, consulte Configuring DNS Resolution.
Testar o servidor DNS

nslookup <DNS Server>

Por exemplo, se o servidor DNS for chamado DC1, execute este comando:

nslookup dc1

Se os testes anteriores foram bem-sucedidos, esse teste também deve ser bem-sucedido. Se esse teste não for
bem-sucedido, verifique a conectividade com o servidor DNS.
Testar o registro com falha

nslookup <failed internal record>

Por exemplo, se o registro com falha app1.corp.contoso.com , execute este comando:

nslookup app1.corp.contoso.com

Testar um endereço público da Internet

nslookup <external name>

Por exemplo:

nslookup bing.com
Se todos os quatro testes foram bem-sucedidos, execute ipconfig /displaydns e verifique a saída do nome que
falhou. Se você vir "Nome não existe" com o nome com falha, uma resposta negativa foi retornada de um
servidor DNS e foi 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 Solução de problemas de servidores DNS.
 Desabilitar o cache do DNS do lado do cliente em
clientes DNS
13/08/2021 • 3 minutes to read

Windows contém um cache DNS do lado do cliente. O recurso de cache DNS do lado do cliente pode gerar uma
falsa impressão de que o balanceamento de carga do DNS "round robin" não está ocorrendo do servidor DNS
para o computador Windows cliente. Quando você usa o comando ping para pesquisar o mesmo nome de
domínio de registro A, o cliente pode usar o mesmo endereço IP.

Como desabilitar o cache do lado do cliente

Para interromper o cache DNS, execute um dos seguintes comandos:

net stop dnscache

sc servername stop dnscache

Para desabilitar o cache DNS permanentemente Windows, use a ferramenta Controlador de Serviço ou a
ferramenta Serviços para definir o tipo de inicialização do serviço Cliente DNS como Desabilitado. Observe
que o nome do serviço Windows cliente DNS também pode aparecer como "Dnscache".

NOTE
Se o cache do resolvedor de DNS for desativado, o desempenho geral do computador cliente diminuirá e o tráfego de
rede para consultas DNS aumentará.

O serviço cliente DNS otimiza o desempenho da resolução de nomes DNS, armazenar nomes resolvidos
anteriormente na memória. Se o serviço cliente DNS estiver desligado, o computador ainda poderá resolver
nomes DNS usando os servidores DNS da rede.
Quando o Windows resolvedor recebe uma resposta, seja positiva ou negativa, a uma consulta, ele adiciona
essa resposta ao cache e, assim, cria um registro de recurso DNS. O resolvedor sempre verifica o cache antes de
consultar qualquer servidor DNS. Se um registro de recurso DNS estiver no cache, o resolvedor usará o registro
do cache em vez de consultar um servidor. Esse comportamento agiliza consultas e diminui o tráfego de rede
para consultas DNS.
Você pode usar a ferramenta ipconfig para exibir e liberar o cache do resolvedor de DNS. Para exibir o cache do
resolvedor de DNS, execute o seguinte comando em um prompt de comando:

ipconfig /displaydns

Esse comando exibe o conteúdo do cache do resolvedor dns, incluindo os registros de recursos DNS pré-
carregados do arquivo Hosts e quaisquer nomes consultados recentemente que foram resolvidos pelo sistema.
Após algum tempo, o resolvedor descarta o registro do cache. O período de tempo é especificado pelo valor
TTL (Vida Vida) associado ao registro de recurso DNS. Você também pode liberar o cache manualmente.
Depois de liberar o cache, o computador deverá consultar servidores DNS novamente para quaisquer registros
de recurso DNS que foram resolvidos anteriormente pelo computador. Para excluir as entradas no cache do
resolvedor dns, execute ipconfig /flushdns em um prompt de comando.

Usando o Registro para controlar o tempo de cache

IMPORTANT
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.

O período de tempo para o qual uma resposta positiva ou negativa é armazenada em cache depende dos
valores de entradas na seguinte chave do Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\DNSCache\Parameters
O TTL para respostas positivas é o menor dos seguintes valores:
O número de segundos especificado na resposta de consulta que o resolvedor recebeu
O valor da configuração do Registro MaxCacheTtl.

NOTE
O TTL padrão para respostas positivas é de 86.400 segundos (1 dia).
O TTL para respostas negativas é o número de segundos especificado na configuração do Registro
MaxNegativeCacheTtl.
O TTL padrão para respostas negativas é de 5 segundos; antes da Windows 10, versão 1703, o padrão era 900
segundos (15 minutos). Se você não quiser que respostas negativas sejam armazenadas em cache, defina a
configuração do Registro MaxNegativeCacheTtl como 0.

Para definir o tempo de cache em um computador cliente:

1. Inicie o Editor do Registro (Regedit.exe).
2. Localize e clique na seguinte chave no Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Ser vices\Dnscache\Parameters
3. No menu Editar, aponte para Novo, clique em Valor DWORD e adicione os seguintes valores do Registro:
Nome do valor: MaxCacheTtl
Tipo de dados: REG_DWORD
Dados de valor: valor padrão 86400 segundos.
Se você diminuir o valor máximo de TTL no cache DNS do cliente para 1 segundo, isso dará a
aparência de que o cache DNS do lado do cliente foi desabilitado.
Nome do valor: MaxNegativeCacheTtl
Tipo de dados: REG_DWORD
Dados de valor: valor padrão de 5 segundos.
De definir o valor como 0 se você não quiser que respostas negativas sejam armazenadas em
cache.
4. Digite o valor que você deseja usar e clique em OK.
5. Feche o Editor do Registro.
 Solução de problemas de servidores DNS
13/08/2021 • 9 minutes to read

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 procurado. Em caso afirmativo,
consulte Verificando se há problemas com dados autoritativos.
3. Execute o comando a seguir:

nslookup <name> <IP address of the DNS server>

Por exemplo:

nslookup app1 10.0.0.1

Se você receber uma resposta de falha ou tempo-out, consulte Verificando problemas de recursão.
4. Liberar o cache do resolvedor. Para fazer isso, execute o seguinte comando em uma janela administrativa
do Prompt de Comando:

dnscmd /clearcache

Ou, em uma janela administrativa do PowerShell, execute o seguinte cmdlet:

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 está acessível nos computadores cliente.

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 de "Falha do servidor" ou "Consulta recusada", a zona
provavelmente será pausada ou o servidor possivelmente será sobrecarregado. Você pode saber se ele
está em pausa verificando a guia Geral das propriedades da zona no console DNS.
Se o resolvedor retornar uma resposta "Solicitação ao servidor com tempo de vida", ou "Nenhuma resposta do
servidor", o serviço DNS provavelmente não está em execução. Tente reiniciar o serviço servidor DNS inserindo
o seguinte em um prompt de comando no servidor:

net start DNS

Se o problema ocorrer quando o serviço estiver em execução, o servidor poderá não estar escutando no
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 somente em 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 está na lista.
Você pode tentar 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 acessível somente por meio de um host intermediário (como um roteador de
filtragem de pacotes ou servidor proxy), o servidor DNS poderá usar uma porta não padrão para escutar e
receber solicitações do cliente. Por padrã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 estiver, 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 está hospedando 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 ins entram 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 recebe transferências de zona).

NOTE
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:

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 não
tenha, você provavelmente terá 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 não, os dados
estão incorretos na zona primária. O problema pode ser causado por erro do usuário quando os usuários
ins entram 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 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 tem um tempo de vida maior antes de ser concluída.
Um servidor que é usado durante a consulta falha ao responder.
Um servidor que é 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
forem 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, consulte Verificar problemas do
servidor DNS. Quando essa seção instruir você a executar uma tarefa no cliente, execute-a no servidor.
Se o servidor estiver ínteco 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:

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 o endereço IP que 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 com tempo de vida", 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 avançada de firewall 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-máximo recursivo seja muito curto.
Testar uma delegação interrompida
Inicie os testes no procedimento a seguir consultando um servidor raiz válido. O teste leva você por 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:

nslookup
server <server IP address>
set norecursion
set querytype= <resource record type>
<FQDN>

NOTE
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 contém um registro de recurso "NS", você tem uma delegação interrompida.
Se a resposta contiver registros de recurso "NS", mas nenhum registro de recurso "A", insira
definir recursão e consulte individualmente os 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, terá uma delegação interrompida.
3. Se você determinar que tem uma delegação interrompida, 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 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 pareceram estar configuradas corretamente, verifique se o servidor DNS usado em uma
resolução de nomes com falha pode fazer 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 tanto para o servidor DNS primário quanto para o 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 de zona no console DNS. Se o servidor
restringe as transferências de zona para uma lista de servidores, como aqueles listados na guia
ser vidores de nomes das propriedades de 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 você for solicitado a executar uma tarefa no cliente, execute a tarefa no servidor
secundário em vez disso.
Verifique se o servidor secundário está executando outra implementação de servidor DNS, como BIND.
Se for, o problema poderá ter uma das seguintes causas:
o servidor primário Windows pode ser configurado para enviar transferências de zona rápidas,
mas o servidor secundário de terceiros pode não oferecer 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 secundários de associação na guia
avançado das propriedades do servidor.
se uma zona de pesquisa direta no servidor de Windows contiver um tipo de registro (por
exemplo, um registro SRV) ao qual o servidor secundário não oferece suporte, o servidor
secundário poderá ter problemas para obter a 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 Windows não
reconheça.
Se o servidor mestre ou secundário estiver executando outra implementação de servidor DNS, verifique ambos
os servidores para garantir que eles ofereçam suporte aos mesmos recursos. você pode verificar o servidor de
Windows no console DNS na guia avançado da página de propriedades do servidor. Além da caixa habilitar
associações secundárias, essa página inclui a lista suspensa de verificação de nome . Isso permite que você
selecione a imposição de conformidade RFC estrita para caracteres em nomes DNS.
 Protocolo DHCP
12/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para uma breve visão geral do DHCP Windows Server 2016.

NOTE
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
13/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico descreve a funcionalidade DHCP (Dynamic Host Configuration Protocol) 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, como 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 na atualização Windows 10

maio de 2020
O cliente DHCP 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 se conectar à Internet por
meio de um telefone Android conectado, a conexão deverá ser marcada como "medida". Anteriormente, as
conexões eram marcadas como não marcadas. Observe que nem todos os telefones com dispositivos Android
serão detectados como monitorados, e algumas outras redes também podem aparecer como medida.
Além disso, o nome tradicional do fornecedor do cliente foi atualizado para alguns Windows baseados em
dados. 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 na atualização Windows 10

de abril de 2018
O cliente DHCP no Windows 10 foi atualizado na Atualização de abril de 2018 do Windows (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 DHCP 119 é especificada no RFC 3397.

Opções de seleção de sub-rede DHCP

O DHCP agora dá suporte à opção 82 ( sub-opção 5 ) . Você pode usar essa opção para permitir que clientes de
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 DHCP 82, sub opçã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 DHCP.

Novos eventos de registro em log para falhas de registro 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 registro em log DHCP para registros de registro DNS.

Não há suporte para NAP DHCP no Windows Server 2016

A NAP da Proteção de Acesso à Rede foi preterida no Windows Server 2012 R2 e, Windows Server 2016 função
de Servidor DHCP não dá mais suporte ( ) a NAP. Para obter mais informações, consulte Recursos removidos ou
preterido no Windows Server 2012 R2.
O suporte nap foi introduzido à função de servidor DHCP com o Windows Server 2008 e tem suporte em
sistemas operacionais cliente e servidor do Windows antes do Windows 10 e Windows Server 2016. A tabela a
seguir resume o suporte para NAP no Windows Server.

SIST EM A O P ERA C IO N A L SUP O RT E A N A P

Windows Server 2008 Com suporte

Windows Server 2008 R2 Com suporte

Windows Server 2012 Com suporte

Windows Server 2012 R2 Com suporte

Windows Server 2016 Sem suporte

Em uma implantação NAP, um servidor DHCP executando um sistema operacional que dá suporte a NAP pode
funcionar como um ponto de imposição NAP para o método de imposição de NAP DHCP. Para obter mais
informações sobre o DHCP no NAP, consulte Checklist: Implementing a DHCP Enforcement Design.
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 instrução de
soH de saúde com a ( ) solicitação DHCP. Se o servidor DHCP estiver executando Windows Server 2016, essas
solicitações serão processadas como se nenhum SoH estivesse presente. O servidor DHCP concede uma
concessão DHCP normal ao cliente.
Se os servidores que estão executando o Windows Server 2016 são proxies RADIUS que encaminham
solicitações de autenticação para um NPS do Servidor de Política de Rede que dá suporte a NAP, esses clientes
NAP são avaliados pelo NPS como não compatíveis com NAP e o processamento ( ) NAP - falha.

Referências adicionais
Protocolo DHCP
 Opções de seleção de sub-rede DHCP
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para obter informações sobre as novas opções de seleção de sub-rede DHCP.
O DHCP agora dá suporte à opção 82 ( sub-opção 5 ) . Você pode usar essas opções para permitir que clientes
de proxy DHCP e agentes de retransmissão solicitem um endereço IP para uma sub-rede específica e de um
escopo e intervalo de endereços IP específicos. Para obter mais detalhes, consulte Opção 82 Sub Option 5 :
RFC 3527 Link Selection sub-option for the Relay Agent Information Option for DHCPv4.
Se você estiver usando um agente de retransmissão DHCP configurado com a opção DHCP 82, sub-opçã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.

Option 82 Sub Option 5: Link Selection Sub Option

A sub-opçã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 de Endereço IP do Gateway
para se ( ) comunicar com servidores DHCP. No entanto, o GIADDR é limitado por suas duas funções
operacionais:
1. Para informar o servidor DHCP sobre a sub-rede na qual reside o cliente DHCP que está solicitando a
concessão de endereço IP.
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 Sub seleção de link da opção 82 é útil nessa situação, permitindo que o agente de retransmissão estado
explicitamente a sub-rede da qual ele deseja que o endereço IP alocado na forma da opção DHCP v4 82 sub
opção 5.

NOTE
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 Windows servidor DHCP não reconhecerá 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 são 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, impedindo que os endereços GIADDR seja atribuídos.

Cenário do caso de uso

Nesse cenário, uma rede da organização inclui um servidor DHCP e um AP de Ponto de Acesso Sem Fio ( ) para
os usuários convidados. Os endereços IP do cliente 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 em maiúsculas.
Para resolver essa restrição, o AP é configurado com a Opção 5 de Seleção de Link para especificar a sub-rede
da qual 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Os logs de eventos do servidor DHCP agora fornecem informações detalhadas sobre falhas de registro dns.

NOTE
Em muitos casos, o motivo para falhas de registro de registro DNS por servidores DHCP é que uma Zona de Lookup
Inversa 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 Lookup Inversa de DNS configurada - inadvertida ou ausente.

ID EVEN TO VA LO R

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 endereço IPv4 %1 e FQDN %2
com o erro %3.

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 endereço IPv6 %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.

20322 DHCPv6.ForwardRecordDNSTimeout Falha no registro de encaminhamento

para o endereço IPv6 %1 e FQDN %2
com o erro %3.
ID EVEN TO VA LO R

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
12/08/2021 • 24 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

este guia fornece instruções sobre como usar Windows PowerShell para implantar um servidor dhcp do
protocolo de configuração de Host dinâmico do protocolo Internet (IP) versão 4 ( ) que atribui automaticamente
endereços IP e opções dhcp a clientes dhcp IPv4 que estão conectados a uma ou mais sub-redes em sua rede.

NOTE
para baixar este documento no formato do Word na galeria do TechNet, consulte implantar o DHCP usando o Windows
PowerShell em Windows Server 2016.

O uso de servidores DHCP para atribuir endereços IP economiza em sobrecarga administrativa porque você não
precisa configurar manualmente as configurações de TCP/IP V4 para cada adaptador de rede em cada
computador na rede. Com DHCP, a configuração de TCP/IP V4 é executada automaticamente quando um
computador ou outro cliente DHCP está conectado à sua rede.
Você pode implantar o servidor DHCP em um grupo de trabalho como um servidor autônomo ou como parte
de um domínio de Active Directory.
Este guia contém as seções a seguir.
Visão geral da implantação de DHCP
Visões gerais de tecnologia
Planejar a implantação do DHCP
Usando este guia em um laboratório de teste
Implantar o DHCP
Verificar a funcionalidade do servidor
Windows PowerShell Comandos para DHCP
lista de comandos Windows PowerShell neste guia

Visão geral da implantação de DHCP

A ilustração a seguir descreve o cenário que você pode implantar usando este guia. O cenário inclui um servidor
DHCP em um domínio Active Directory. O servidor está configurado para fornecer endereços IP a clientes DHCP
em duas sub-redes diferentes. As sub-redes são separadas por um roteador que tem o encaminhamento de
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
cada dispositivo 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
envolvidos na configuração de computadores.
Visão geral de TCP/IP
por padrão, todas as versões do Windows Server e dos sistemas operacionais cliente Windows 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 de 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 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 ) .
o 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 servidores Web e protocolo FTP
(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 Server 2008 R2
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 a rede
Tablets e telefones celulares com Ethernet com fio ou tecnologia sem fio 802,11 habilitada

Planejar a implantação do 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.

C L A SSE DE EN DEREÇ O B IT S PA RA M Á SC A RA DE SUB - REDE M Á SC A RA DE SUB - REDE

Classe A 11111111 00000000 00000000 255.0.0.0

00000000

Classe B 11111111 11111111 00000000 255.255.0.0

00000000

Classe C 11111111 11111111 11111111 255.255.255.0

00000000

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.

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO

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.

IT EN S DE C O N F IGURA Ç Ã O VA LO RES DE EXEM P LO

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

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. Finalizando o endereço IP 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.

NOTE
Se você não quiser implantar o DHCP em um laboratório de teste, poderá pular para a seção Implantar DHCP.

Os requisitos para seu laboratório diferem dependendo se você está usando servidores físicos ou VMs de
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 do DHCP usando este guia.
Requisitos do laboratório de teste 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 comu switch virtual, dois servidores virtuais e um cliente
virtual:
No servidor físico, no Gerenciador do Hyper-V, crie os itens a seguir.
1. Um comu switch virtual interno. Não crie um comutadores vir tuais externos, pois se o host Hyper V
estiver em uma sub-rede que inclui 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 com switch virtual interno que você criou. Para
corresponder a este guia, esse servidor deve ter um endereço IP configurado estaticamente de 10.0.0.2. Para
obter informações sobre como AD DS, consulte a seção Implantando DC1 no Guia de rede Windows
Server 2016 Core.
3. Uma VM em execução Windows Server 2016 que você configurará como um servidor DHCP usando este
guia e que está conectada ao comu switch virtual interno que você criou.
4. Uma VM executando um sistema operacional cliente Windows que está conectado ao comutório virtual
interno que você criou 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 ser vidor DHCP
Essa implantação requer um servidor físico, um comu switch virtual, um servidor virtual e um cliente virtual:
No servidor físico, no Gerenciador do Hyper-V, crie os itens a seguir.
1. Um comu switch virtual interno. Não crie um comutadores vir tuais externos, pois se o host Hyper V
estiver em uma sub-rede que inclui 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 comu switch virtual interno que você criou.
3. Uma VM executando um sistema operacional cliente Windows que está conectado ao comutório virtual
interno que você criou e que você usará para verificar se o servidor DHCP está alocando dinamicamente
endereços IP e opções DHCP para clientes DHCP.
Requisitos do laboratório de teste 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 uma opção, dois servidores físicos e um cliente físico:
1. Um hub Ethernet ou uma opção para a qual você pode conectar os computadores físicos com cabos Ethernet
2. Um computador físico executando Windows Server 2016 configurado como um controlador de domínio
com Active Directory Domain Services. Para corresponder a este guia, esse servidor deve ter um endereço IP
configurado estaticamente de 10.0.0.2. Para obter informações sobre como AD DS, consulte a seção
Implantando DC1 no Guia de rede 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 Windows operacional cliente que você usará para verificar se o
servidor DHCP está alocando dinamicamente endereços IP e opções DHCP para clientes DHCP.

NOTE
Se você não tiver máquinas 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 ser vidor DHCP

Essa implantação requer um hub ou uma opção, um servidor físico e um cliente físico:
1. Um hub Ethernet ou uma opção para a 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 executando um Windows operacional cliente que você usará para verificar se o
servidor DHCP está alocando dinamicamente endereços IP e opções DHCP para clientes DHCP.

Implantar o DHCP
Esta seção fornece exemplos Windows PowerShell comandos que você pode usar para implantar o DHCP em
um servidor. Antes de executar esses comandos de exemplo em seu servidor, você deve modificar os comandos
para corresponder à rede e ao ambiente.
Por exemplo, antes de executar os comandos, você deve substituir os 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

IMPORTANT
Examine e modifique todos os comandos 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 de 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 a computadores na rede física à qual o host Hyper-V está conectado,
você deverá conectar o adaptador de rede virtual da VM a um Computação Virtual Hyper-V externo.
Para obter mais informações, consulte a seção Criar um com switch 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 privilégios de Administrador.
1. Em um computador executando Windows Server 2016, clique em Iniciar e, em seguida, clique com o
botão direito do mouse Windows PowerShell ícone. Um menu é exibido.
2. No menu, clique em Mais e, em seguida, 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 de 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 tiver feito 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.
Configurar um endereço IP estático
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 do servidor DNS correto. 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.3 -InterfaceAlias "Ethernet" -DefaultGateway 10.0.0.1 -AddressFamily IPv4

-PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.0.0.2

Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
New-NetIPAddress
Set-DnsClientServerAddress
Renomear o computador
Você pode usar os comandos a seguir para renomear e reiniciar o computador.

Rename-Computer -Name DHCP1

Restart-Computer

Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Rename-Computer
Restart-Computer
Ingressar o computador no domínio ( Opcional)
Se você estiver instalando o 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 domínio NetBios name CORP 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 Add-Computer, consulte o tópico a seguir.

Add-Computer
Instalar o DHCP
Depois que o computador for reiniciado, abra Windows PowerShell privilégios de Administrador e instale o
DHCP executando o comando a seguir.

Install-WindowsFeature DHCP -IncludeManagementTools

Para obter mais informações sobre esse comando, consulte o tópico a seguir.
Install-WindowsFeature
Criar grupos de segurança DHCP
Para criar grupos de segurança, você deve executar um comando netsh do Shell de Rede no Windows
PowerShell e reiniciar o serviço DHCP para que os novos grupos se tornem ( ) ativos.
Quando você executar o comando netsh a seguir no servidor DHCP, os grupos de segurança Administradores
DHCP e Usuários DHCP serã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

Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Shell de Rede (Netsh)
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.

NOTE
Servidores DHCP não autorizados instalados em domínios do Active Directory não podem funcionar corretamente e não
arrendam endereços IP para 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.

NOTE
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 que são exibidos Windows PowerShell.

IPAddress DnsName
--------- -------
10.0.0.3 DHCP1.corp.contoso.com

Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Add-DhcpServerInDC
Get-DhcpServerInDC
Notificar Gerenciador do Servidor que a - configuração do DHCP pós-instalação está concluída ( Opcional)
Depois de concluir as tarefas pós-instalação, como criar grupos de segurança e autorizar o servidor DHCP no
Active Directory, o Gerenciador do Servidor ainda poderá exibir um alerta na interface do usuário informando
que as etapas de pós-instalação devem ser concluídas usando o assistente de Configuração de Pós-Instalação
do - - DHCP.
Você pode impedir que essa mensagem desnecessária e imprecisa apareça no Gerenciador do Servidor
configurando a seguinte chave do Registro usando esse comando - Windows PowerShell segurança.

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 definições de configuração de atualização dinâmica de 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, ela afetará todos os escopos que você configurar no servidor.
Este comando de exemplo também configura o servidor DHCP para excluir registros de recursos DNS para
clientes quando o cliente expira menos.

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
não registrar 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, em seguida, armazena o
objeto na variável $Credential dados. 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 em seu
servidor DNS.

$Credential = Get-Credential
Set-DhcpServerDnsCredential -Credential $Credential -ComputerName "DHCP1.corp.contoso.com"

Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
Set-DhcpServerv4DnsSetting
Set-DhcpServerDnsCredential
Configurar o escopo Corpnet
Após a conclusão da instalação do DHCP, você pode 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.

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
Set-DhcpServerv4OptionValue -DnsDomain corp.contoso.com -DnsServer 10.0.0.2

Para obter mais informações sobre esses comandos, consulte os tópicos a seguir.
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, 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.

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

State Active
Add-DhcpServerv4ExclusionRange -ScopeID 10.0.1.0 -StartRange 10.0.1.1 -EndRange 10.0.1.15
Set-DhcpServerv4OptionValue -OptionID 3 -Value 10.0.1.1 -ScopeID 10.0.1.0 -ComputerName
DHCP1.corp.contoso.com

Se você tiver sub-redes adicionais que são ativas 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.

IMPORTANT
Verifique se todos os roteadores entre os clientes DHCP e o 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 a serviço. 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 revendo os resultados ou executando testes de
conectividade, como tentar acessar recursos da Web com seu navegador ou compartilhamentos de arquivos
com o 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 à opção Ethernet, hub ou roteador.
2. Se você tiver conectado 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 estão ativados abrindo o console do DHCP ( Gerenciador do servidor, ferramentas ,
DHCP ) , expandindo a árvore do servidor para examinar escopos e clicando com o botão direito - 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 exibirá desativar .)

Windows PowerShell Comandos para DHCP

a referência a seguir fornece descrições de comando e sintaxe para todos os comandos de Windows PowerShell
de servidor DHCP para Windows Server 2016. O tópico lista os comandos em ordem alfabética com base no
verbo no início dos comandos, como Get ou set .
 NOTE
você não pode usar os 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 de Windows PowerShell
de servidor DHCP para o Windows Server 2012 R2. O tópico lista os comandos em ordem alfabética com base
no verbo no início dos comandos, como Get ou set .

NOTE
você pode usar os comandos do Windows Server 2012 R2 no Windows Server 2016.

Cmdlets do servidor DHCP no Windows PowerShell

lista de comandos Windows PowerShell neste guia

A seguir está uma lista simples de comandos e valores de exemplo que são usados neste guia.
New-NetIPAddress -IPAddress 10.0.0.3 -InterfaceAlias "Ethernet" -DefaultGateway 10.0.0.1 -AddressFamily IPv4
-PrefixLength 24
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 10.0.0.2
Rename-Computer -Name DHCP1
Restart-Computer

Add-Computer CORP
Restart-Computer

Install-WindowsFeature DHCP -IncludeManagementTools

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

$Credential = Get-Credential
Set-DhcpServerDnsCredential -Credential $Credential -ComputerName "DHCP1.corp.contoso.com"

rem At prompt, supply credential in form DOMAIN\user, password

rem Configure scope Corpnet

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
Set-DhcpServerv4OptionValue -DnsDomain corp.contoso.com -DnsServer 10.0.0.2

rem Configure scope Corpnet2

Add-DhcpServerv4Scope -name "Corpnet2" -StartRange 10.0.1.1 -EndRange 10.0.1.254 -SubnetMask 255.255.255.0 -
State Active
Add-DhcpServerv4ExclusionRange -ScopeID 10.0.1.0 -StartRange 10.0.1.1 -EndRange 10.0.1.15
Set-DhcpServerv4OptionValue -OptionID 3 -Value 10.0.1.1 -ScopeID 10.0.1.0 -ComputerName
DHCP1.corp.contoso.com
 Guia de solução de problemas do DHCP (protocolo
de configuração dinâmica de hosts)
10/08/2021 • 2 minutes to read

Para qualquer dispositivo (como um computador ou telefone) ser capaz de operar em uma rede, ele deve ser
atribuído a 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 cliente e o servidor DHCP do
Microsoft 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 auxiliar/IP de agente de retransmissão DHCP para enviar solicitações de difusão DHCP a 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 com base em difusão (descoberta, oferta, solicitação, confirmação). O processo é composto
pelas seguintes etapas:
O cliente DHCP envia uma solicitação de difusão de descoberta de DHCP para todos os servidores
DHCP disponíveis no intervalo.
Uma resposta de difusão de oferta DHCP é recebida do servidor DHCP, oferecendo uma concessão
de endereço IP disponível.
A solicitação de difusão de cliente DHCP solicita a concessão de endereço IP oferecido e a
confirmação de difusão DHCP no final.
Se o cliente DHCP e o servidor estiverem localizados em diferentes segmentos de rede lógica, um
agente de retransmissão DHCP atuará em um encaminhador, enviando os pacotes de difusão
DHCP para frente e para trás entre os pares.
Solicitações de renovação de 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 em qualquer servidor DHCP dentro do
intervalo do cliente. Eles são enviados após 87,5% da duração da concessão do endereço IP porque isso
indica que a solicitação unicast direcionada não funcionou. Para o processo DORA, esse processo envolve
uma comunicação de agente de retransmissão DHCP.
Se um cliente DHCP da Microsoft não receber um endereço DHCP IPv4 válido, provavelmente o cliente será
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: Noções básicas de 169289 DHCP (protocolo de configuração de host
dinâmico).
 Noções básicas do DHCP (Dynamic Host
Configuration Protocol)
10/08/2021 • 15 minutes to read

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 Windows) e endereços de servidor WINS (Serviço de Nome de 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 Versões do servidor 3.5, 3.51 e 4.0
Windows NT Estação de trabalho 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 Versão do servidor 3.5
Windows NT Versão do servidor 3.51
Windows NT Versão do servidor 4.0
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: 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 = 15408 (0x3C30)
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 = 0x2FA8
IP: Source Address = 157.54.48.151
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: Offer (xid=21274A1D)

DHCP: Op Code (op) = 2 (0x2)
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) = 157.54.50.5
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 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
DHCP: End of this option field

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.

IP: ID = 0x100; 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 = 256 (0x100)
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 = 0x38A6
IP: Source Address = 0.0.0.0
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: Request (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 Request
DHCP: Client-identifier = (Type: 1) 08 00 2b 2e d8 5e
DHCP: Requested Address = 157.54.50.5
DHCP: Server Identifier = 157.54.48.151
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field

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: 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 = 15664 (0x3D30)
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 = 0x2EA8
IP: Source Address = 157.54.48.151
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: ACK (xid=21274A1D)

DHCP: Op Code (op) = 2 (0x2)
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) = 157.54.50.5
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 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: Server Identifier = 157.54.48.151
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
DHCP: End of this option field

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.
 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: Request (xid=2757554E)

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) = 660034894 (0x2757554E)
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 Request
DHCP: Client-identifier = (Type: 1) 08 00 2b 2e d8 5e
DHCP: Requested Address = 157.54.50.5
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field

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: 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 = 16154 (0x3F1A)
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 = 0x2CBE
IP: Source Address = 157.54.48.151
IP: Destination Address = 255.255.255.255
IP: Data: Number of data bytes remaining = 308 (0x0134)

DHCP: NACK (xid=74A005CE)

DHCP: Op Code (op) = 2 (0x2)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 1956644302 (0x74A005CE)
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 NACK
DHCP: Server Identifier = 157.54.48.151
DHCP: End of this option field

Em seguida, o cliente iniciará o processo de descoberta, mas o pacote DHCPDISCOVER ainda tentará a
concessão do mesmo endereço. Em muitas instâncias, o cliente tth obterá o mesmo endereço, mas talvez não.
 IP: ID = 0x100; 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 = 256 (0x100)
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 = 0x38A6
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=3ED14752)

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) = 1053902674 (0x3ED14752)
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: Requested Address = 157.54.51.5
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field

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
12/08/2021 • 2 minutes to read

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,
algo mudou antes do problema começar. 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
10/08/2021 • 5 minutes to read

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
IMPORTANT
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\Interfaces\<Adapter GUID>

NOTE
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
12/08/2021 • 2 minutes to read

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 star t 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 de administrador/eventos do cliente microsoft-Windows-dhcp/operacional e
microsoft-Windows-dhcp. Todos os eventos relacionados ao serviço de cliente DHCP são enviados a esses logs
de eventos. os eventos do cliente Microsoft-Windows-DHCP estão localizados no Visualizador de Eventos em
Logs de aplicativos e ser viços .
O comando do PowerShell "Get-netadapter-IncludeHidden" fornece as informações necessárias para interpretar
os eventos listados nos logs. Por exemplo, ID de interface, endereço MAC e assim por diante.

Coleta de dados
Recomendamos que você colete dados simultaneamente no cliente DHCP e no lado 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 o 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:

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 será interrompida.
 Solucionar problemas no servidor DHCP
12/08/2021 • 3 minutes to read

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 de servidor DHCP é iniciado e em execução. Para verificar essa configuração, execute o
comando net star t e procure o Servidor DHCP.
O servidor DHCP está autorizado. Consulte Windows autorização do servidor DHCP 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 para o escopo apropriado no console de
gerenciamento do servidor DHCP.
Verifique se alguma _ listagem de ENDEREÇOS ERRADOs 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
DHCP.
Verifique se o endereço IP ao qual o servidor DHCP está associado está dentro da sub-rede dos escopos
dos quais os endereços IP devem ser arrendados. Isso ocorre caso nenhum agente de retransmissão está
disponível. Para fazer isso, execute o cmdlet Get-DhcpSer ver v4Binding ou Get-
DhcpSer ver v6Binding.
Verifique se apenas o servidor DHCP está escutando nas portas UDP 67 e 68. Nenhum outro processo ou
outros serviços (como WDS ou PXE) devem ocupar essas portas. Para fazer isso, execute o netstat -anb
comando .
Verifique se a isenção de IPsec do servidor DHCP foi adicionada se você estiver lidando com um
ambiente implantado pelo IPsec.
Verifique se o endereço IP do agente de retransmissão pode ser pingado do servidor DHCP.
Enumerar e verificar políticas e filtros DHCP configurados.

Logs de eventos
Verifique os logs de eventos do sistema e do serviço servidor DHCP (Logs de aplicativos e serviços >
Microsoft > Windows > DHCP-Ser ver ) para 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 DHCPEventos administrativos do servidor DHCP Eventos do sistema do servidor
DHCPEventos de notificação de filtro do servidor DHCPEventos de auditoria do servidor DHCP

Coleta de dados
Log do Servidor DHCP
Os logs de depuração do serviço 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 que são 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. Vá para GitHube baixe o arquivo tss _tools.zip.
2. Copie o arquivotools.zip Tss e expanda-o para um local no disco local, como para _ a pasta ferramentas \
C:.
3. Execute o seguinte comando das ferramentas C: \ em uma janela de prompt de comando com elevados:

TSS Ron Trace <Stop:Evt:>20321:<Other:>DhcpAdminEvents NoSDP NoPSR NoProcmon NoGPresult

NOTE
Neste comando, substitua e pela ID do evento e o canal de evento no que você se <Stop:Evt:> <Other:>
concentrará em sua sessão de rastreamento. O Tss.cmd ReadMeHelp.docx arquivos contidos no arquivo
Tsstools.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 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
07/08/2021 • 27 minutes to read

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 car tão inteligente ou outras propriedades de cer tificado 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 Transpor t 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.

IMPORTANT
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 ser vidores durante o processo de autenticação. Se a
autenticação do ser vidor 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 inadver tidamente 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 autoridades de certificação raiz confiáveis.
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 Cer tificaçã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.

NOTE
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 Cer tificaçã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 ser vidores ou autoridades de cer tificação
confiáveis especifica que:
Se o nome do servidor não estiver na lista Conectar a estes ser vidores
ou o certificado raiz for localizado, mas não estiver selecionado na lista de Autoridades de
Cer tificaçã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 ser vidor ou cer tificado raiz não for especificado
 especifica que:
Se o nome do servidor não estiver na lista Conectar a estes ser vidores
ou o certificado raiz for localizado, mas não estiver selecionado na lista de Autoridades de
Cer tificação Raiz Confiáveis em Propriedades PEAP
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 ser vidor não pode ser verificada especifica se:
Se o nome do servidor não estiver na lista Conectar a estes ser vidores
ou o certificado raiz for localizado, mas não estiver selecionado na lista de Autoridades de
Cer tificação Raiz Confiáveis em Propriedades PEAP
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 car tão inteligente ou
outro cer tificado (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.
Para obter mais informações, consulte:
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
Este item fornece acesso às configurações de propriedade para o tipo de EAP especificado.
Habilitar reconexão rápida
Habilita a capacidade de 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 restabelece automaticamente as conexões VPN ativas quando a conectividade com a
Internet é restabelecida. 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
Esse item especifica que antes de as conexões com uma rede serem permitidas, as verificações de integridade
do sistema são executadas em suplicantes de EAP para determinar se atendem aos requisitos de integridade 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 de conexão devem encerrar o processo de autenticação de rede se o
servidor RADIUS não apresentar um TLV (tipo-tamanho-valor) de cryptobinding. 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.
Padrão = não habilitado
habilitar privacidade de identidade (somente Windows 8)
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ônima, 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ônima, a resposta de identidade para o usuário alice@example será @example .
essa configuração se aplica somente a computadores que executam o Windows 8 e versões anteriores.
Padrão = não habilitado

Itens de configuração de propriedades de senha de segurança

a verificação usar automaticamente o nome de logon e a senha do Windows (e o domínio, se
houver) especifica que o nome de entrada e a senha atuais Windows baseados no usuário são usados como
credenciais de autenticação de rede.
Padrões:
Com fio e sem fio = habilitado
VPN = não habilitado

Cartões inteligentes 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:
Com fio e sem fio = não habilitado
VPN = habilitado
Usar um certificado neste computador
Este item especifica que os clientes de autenticação devem usar um certificado localizado no repositório de
certificados do computador local ou do usuário atual .
Padrões:
Com fio e sem fio = habilitado
VPN = não habilitado
Usar seleção de certificado simples (recomendado )
este item especifica se Windows filtra os certificados que são improvável 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:
Com fio e sem fio = habilitado
VPN = não habilitado
Avançado
Esse item abre a caixa de diálogo Configurar seleção de cer tificado . Para obter mais informações sobre
como Configurar a seleção de cer tificado , 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 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.
Não desabilite essa caixa de seleção ou os computadores cliente não poderão verificar a
identidade de seus ser vidores durante o processo de autenticação. Se a autenticação do ser vidor
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 inadver tidamente a uma rede não autorizada.
Padrão = habilitado
Conectar-se a estes servidores
Esse item permite que você especifique o nome para 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 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 raiz confiáveis
Este item lista as autoridades de cer tificação raiz confiáveis . A lista é criada a partir das CAs raiz confiáveis
que estão instaladas nos repositórios 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.
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 autoridades de certificação raiz confiáveis.
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 Cer tificaçã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. 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 Cer tificação Raiz Confiáveis dos computadores clientes para o
Usuário Atual e Computador Local .

NOTE
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
Este item permite que você exiba as propriedades do certificado selecionado.
Não solicitar ao usuário autorização para novos servidores ou autoridades de certificação confiáveis
Este item impede que o usuário seja solicitado a confiar em um certificado de servidor se esse certificado
estiver configurado incorretamente, 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.
Padrão = não habilitado
Usar um nome de usuário diferente para a conexão
Este item especifica se deve ser usado um nome de usuário para autenticação que seja diferente do nome de
usuário no certificado.
Padrão = não habilitado

Configurar Nova Seleção de Certificado - itens de configuração

Use Nova Seleção de Cer tificado 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 para a nova seleção de cer tificado , 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 Cer tificação Raiz Confiáveis ou Autoridades de Cer tificaçã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 de cliente , qualquer finalidade ou qualquer
combinação delas. 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.
Padrão = não habilitado
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 a finalidade de autenticar o cliente no servidor.
Padrão = selecionado quando o uso estendido de chave (EKU) é 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 a finalidade de autenticar o cliente para o
servidor.
Padrão = selecionado quando o uso estendido de chave (EKU) é selecionado
Qualquer Finalidade
Quando selecionado, este item especifica que todos os certificados que têm qualquer EKU de finalidade e a
lista especificada de EKUs são considerados certificados válidos para a finalidade de autenticar o cliente para o
servidor.
Padrão = selecionado quando o uso estendido de chave (EKU) é selecionado
Adicionar
Esse item abre a caixa de diálogo selecionar EKUs , que permite adicionar EKUs padrão, personalizado ou
específico do fornecedor à autenticação do cliente ou a qualquer lista de finalidade .
Padrão = nenhum EKU listado
Remover
Este item remove o EKU selecionado da lista autenticação do cliente ou qualquer finalidade .
Padrão = N/D
 NOTE
Quando Emissor de Cer tificado 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.

IT EM DETA L H ES

Adicionar Abre a caixa de diálogo Adicionar ou editar EKU , que

permite que você defina e adicione EKUs personalizado. 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 que você edite EKUs personalizado que você
adicionou. Você não pode editar os EKUs padrão
predefinidos.

Removerr 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

IT EM DETA L H ES

Insira o nome de EKU Fornece um local para digitar o nome do EKU personalizado.

Insira o OID EKU Fornece um local para digitar o OID do EKU. Somente
números, separadores e “.” são permitidos. É permitido inserir
curingas. Nesse caso, todos os OIDs filhos na hierarquia são
permitidos. Por exemplo, se você informar 1.3.6.1.4.1.311.*,
serão permitidos 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 apenas suporte do lado do cliente, com a finalidade de
dar suporte à interoperação com os servidores RADIUS mais implantados que oferecem suporte a EAP-TTLS.
Esta seção lista os itens que podem ser configurados para EAP-TTLS.
habilitar privacidade de identidade (somente Windows 8)
Este item especifica que os clientes estão configurados para que não possam enviar sua identidade antes que o
cliente tenha autenticado o servidor RADIUS e, opcionalmente, forneça 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ônima, a resposta de identidade para um usuário com
alice@example identidade guest@example será. Se você selecionar Habilitar Privacidade de identidade ,
mas não fornecer um valor de identidade anônima, a resposta de identidade para o usuário alice@example será
@example .
Essa configuração se aplica somente a computadores que executam Windows 8.
Padrão = não habilitado
Conectar-se a estes servidores
Este item permite que você especifique o nome para 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 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*.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 cer tificação raiz confiáveis . A lista é criada a partir das CAs raiz confiáveis
que estão instaladas nos repositórios 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.
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 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.
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 Cer tificaçã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.
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 Cer tificação Raiz Confiáveis dos computadores clientes para o
Usuário Atual e Computador Local .

NOTE
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

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 uma das seguintes razões, o usuário receberá uma solicitação para aceitar ou rejeitar o servidor:
Um certificado raiz para o certificado do servidor não é encontrado ou selecionado na lista Autoridades de
Cer tificaçã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 ser vidores .
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, Selecione um método EAP para autenticação está 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, este item usa Windows credenciais de entrada. 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 .
usar automaticamente meu nome de logon e senha do Windows está desabilitado 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

NOTE
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 PEAP e 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)itens de configuração de propriedades .
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.

IT EM DESC RIÇ Ã O

Usar chaves de Criptografia for tes Se selecionada, especifica que o perfil usa criptografia forte.

Não revelar a identidade real no ser vidor quando a
identidade do pseudônimo estiver disponível
Quando habilitada, força o cliente a falhar na autenticação
quando as solicitações do servidor por identidade
permanente no cliente têm uma identidade de pseudônimo.
As identidades de pseudônimos são usadas na privacidade
de identidades, de modo que o identidade real ou
permanente de um usuário não seja revelada durante a
autenticação.

Habilitar uso de realms Fornece um local para digitação do nome do realm. Se esse
campo for 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 padrão Project 3GPP (3GPP) 23.003
V6.8.0.

Especificar um realm Fornece um local para digitar o nome do 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.

IT EM DESC RIÇ Ã O

Não revelar a identidade real no ser vidor quando a
identidade do pseudônimo estiver disponível
Quando habilitada, força o cliente a falhar na autenticação
quando as solicitações do servidor por identidade
permanente no cliente têm uma identidade de pseudônimo.
As identidades de pseudônimos são usadas na privacidade
de identidades, de modo que o identidade real ou
permanente de um usuário não seja revelada durante a
autenticação.

Habilitar uso de realms Fornece um local para digitação do nome do realm. Se esse
campo for 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 padrão Project 3GPP (3GPP) 23.003
V6.8.0.

Especificar um realm Fornece um local para digitação do nome do 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'.

IT EM DESC RIÇ Ã O

Não revelar a identidade real no ser vidor quando a
identidade do pseudônimo estiver disponível
Quando habilitada, força o cliente a falhar na autenticação
quando as solicitações do servidor por identidade
permanente no cliente têm uma identidade de pseudônimo.
As identidades de pseudônimos são usadas na privacidade
de identidades, de modo que o identidade real ou
permanente de um usuário não seja revelada durante a
autenticação.

Habilitar uso de realms Fornece um local para digitação do nome do realm. Se esse
campo for 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 padrão Project 3GPP (3GPP) 23.003
V6.8.0.

Especificar um realm Fornece um local para digitação do nome do realm.

Ignorar incompatibilidade de nome de rede
O cliente compara o nome da rede conhecido com o nome
enviado pelo servidor RADIUS durante a autenticação. Se
houver incompatibilidade, ela será ignorada se essa opção
estiver selecionada. Se não estiver selecionada, haverá falha
de autenticação.

Habilitar Reautenticação Rápida
Especifica que a reautenticação rápida está habilitada. Esse
recurso é útil quando a autenticação SIM é realizada com
frequência. As chaves de 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 a nova rede com fio (IEEE 802.3) políticas 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)
07/08/2021 • 2 minutes to read

aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

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:
Insider Preview
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
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

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 que não são do Hyper-V, como o NIC Teaming.
2. Recursos e tecnologias integradosde 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).

TIP
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
12/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

Somente recursos 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 (Virtual Machine Quality of Service), ACLs (Listas de Controle
de Acesso) e recursos não Hyper-V, como o NIC Teaming. Para saber mais, confira Requisitos de rede de host
para Azure Stack HCI.

ACLs (Listas de Controle de Acesso)

Um recurso Hyper-V e SDNv1 para gerenciar a segurança de uma VM. Esse recurso se aplica à pilha do Hyper-V
não virtualizada e à pilha HVNv1. Você pode gerenciar ACLs de comutadores do Hyper-V por meio dos cmdlets
Add-VMNetworkAdapterAcl e Remove-VMNetworkAdapterAcl do PowerShell.

ACLs estendidas
As ACLs estendidas do Com switch virtual hyper-V permitem que você configure as ACLs de Porta Estendida do
Com switch virtual do Hyper-V para fornecer proteção de firewall e impor políticas de segurança para as VMs
de locatário em datacenters. Como as ACLs de porta estão configuradas no Comutar Virtual do Hyper-V em vez
de dentro das VMs, o administrador pode gerenciar políticas de segurança para todos os locatários em um
ambiente multitenatário.
Você pode gerenciar ACLs estendidas do comutadores hyper-V por meio dos cmdlets Add-
VMNetworkAdapterExtendedAcl e Remove-VMNetworkAdapterExtendedAcl do PowerShell.

TIP
Esse recurso se aplica à pilha HNVv1. Para ACLs na pilha SDN, consulte ACLs do SDN de Rede Definida pelo Software
abaixo.

Para obter mais informações sobre 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 NIC Teaming, também chamado de vínculo NIC, é a agregação de várias portas NIC em uma entidade que o
host percebe como uma única porta NIC. O NIC Teaming 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 produtividade mais rápida. Para obter
mais detalhes, consulte NIC Teaming.
Com Windows Server 2016 você tem duas maneiras de fazer o teaming:
1. Windows Server 2012 de equipe
2. Windows Server 2016 Set (Switch Embedded Teaming)

RSC no vSwitch
O RSC (Receive Segment Coalescing) no vSwitch é um recurso que aceita pacotes que fazem parte do mesmo
fluxo e chegam entre interrupções de rede e os une em um único pacote antes de fornená-los ao sistema
operacional. O com switch virtual no Windows Server 2019 tem esse recurso. Para obter mais detalhes sobre
esse recurso, consulte Receive Segment Coalescing in the vSwitch.

ACLs de rede definida pelo software (SDN)

A extensão SDN em Windows Server 2016 maneiras aprimoradas de dar suporte a ACLs. Na pilha Windows
Server 2016 SDN v2, as ACLs SDN são usadas em vez de ACLs e ACLs estendidas. Você pode usar o
Controlador de Rede para gerenciar ACLs SDN.

QoS (Qualidade de Serviço) da SDN

A extensão SDN Windows Server 2016 maneiras aprimoradas de fornecer controle de largura de banda
(reservas de saída, 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 QoS do SDN é usado em vez do vmQoS. Você pode usar o Controlador de Rede para
gerenciar ODN QoS.

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. Para obter informações sobre o Switch Embedded Teaming nesta
biblioteca, consulte Acesso remoto direto à memória (RDMA) e Set (Switch Embedded Teaming).

vRSS (Virtual Receive Side Scaling)

O vRSS de software é usado para difundir o tráfego de entrada destinado a uma VM entre vários LPs
(processadores lógicos) 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. Para obter mais informações, consulte Virtual Receive Side Scaling (vRSS).

VMQoS (Qualidade de Serviço da Máquina Virtual)

A Qualidade de Serviço da Máquina Virtual é um recurso do Hyper-V que permite que a opção de definir 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 desabilitar outra VM para largura de banda. Na pilha
Windows Server 2016 SDN v2, o QoS do SDN substitui o vmQoS.
O 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 a opção Hyper-V.
Determine o modo de reserva de saída com o parâmetro –MinimumBandwidthMode do cmdlet New-
VMSwitch PowerShell.
De definir o valor do limite de saída com o parâmetro –MaximumBandwidth no cmdlet Set-
VMNetworkAdapter PowerShell.
De definir o valor da reserva de saída com um dos seguintes parâmetros do cmdlet Set
VMNetworkAdapter do PowerShell:
Se o parâmetro –MinimumBandwidthMode no cmdlet New-VMSwitch for Absolute, de definir o
parâmetro –MinimumBandwidthAbsolute no cmdlet Set VMNetworkAdapter.
Se o parâmetro –MinimumBandwidthMode no cmdlet New-VMSwitch for Weight, de definir 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 largura de
banda absoluta não seja mais de 20 vezes o menor peso ou largura de banda absoluta. Se mais controle for
necessário, considere usar a pilha SDN e o SDN-QoS recurso.
 Software e hardware (SH) integrado recursos e
tecnologias
07/08/2021 • 7 minutes to read

aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

Esses recursos têm componentes de software e hardware. O software está intimamente ligado a recursos de
hardware que são necessários para que o recurso funcione. Exemplos desses incluem VMMQ, VMQ,
descarregamento de soma de verificação do IPv4 do lado do envio e RSS. Para saber mais, confira requisitos de
rede do host para Azure Stack HCI.

TIP
Os recursos SH e HO estarão disponíveis se a NIC instalada der suporte a ele. As descrições de recurso a seguir abordarão
como saber se a NIC dá suporte ao recurso.

NIC convergida
A NIC convergida é uma tecnologia que permite que as NICs virtuais no host Hyper-V exponham serviços
RDMA para hospedar processos. Windows Server 2016 não requer mais NICs separadas para RDMA. O recurso
NIC convergida permite que as NICs virtuais na partição de host (vNICs) exponham 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 uma
maneira justa e gerenciável.

Você pode gerenciar a operação de 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 capacidade de NIC convergida:
1. Certifique-se de definir o host para DCB.
2. Certifique-se de habilitar o RDMA na NIC ou, no caso de uma equipe definida, as NICs estão associadas à
opção do Hyper-V.
3. Certifique-se de habilitar o RDMA no vNICs designado para RDMA no host.
Para obter mais detalhes sobre o RDMA e o conjunto, consulte acesso remoto direto à memória (RDMA) e
alternância inserida de equipe (Set).

DCB (Data Center Bridging)

O DCB é um conjunto de padrões de IEEE (Institute of Electrical and Electronics Engineers) que habilitam malhas
convergentes 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 de armazenamento, rede de dados, IPC
(comunicação de Inter-Process de cluster) e gerenciamento compartilham a mesma infraestrutura de rede
Ethernet. em Windows Server 2016, DCB pode ser aplicado a qualquer NIC individualmente e NICs associadas à
opção do Hyper-V.
para DCB, o servidor de Windows usa o controle de Flow baseado em prioridade (PFC), padronizado em qbb
IEEE 802.1. O PFC cria uma malha de rede (quase) sem perdas, impedindo o estouro nas classes de tráfego.
Windows O servidor também usa a seleção de transmissão avançada (ETS), padronizada em IEEE 802.1 Qaz. O
ETS permite 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 de PFC, pode iniciar e parar a transmissão dentro
de uma classe.
Para obter mais informações, consulte ponte do Data Center (DCB).

Virtualização de Rede Hyper-V

VERSÃ O DESC RIÇ Ã O

V1 (HNVv1) 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.

v2 NVGRE (HNVv2 NVGRE) em Windows Server 2016 e System Center Virtual Machine
Manager, a Microsoft fornece uma solução de virtualização
de rede de ponta a ponta que inclui Gateway de RAS,
balanceamento de carga de Software, controlador de rede e
muito mais. Para obter mais informações, consulte visão
geral da virtualização de rede Hyper-V no Windows Server
2016.

v2 VxL AN (HNVv2 VxL AN) no Windows Server 2016, faz parte da extensão SDN, que
você gerencia por meio do controlador de rede.

Descarregamento de tarefa IPsec (IPsecto)

O descarregamento de tarefa IPsec é um recurso NIC que permite que o sistema operacional use o processador
na NIC para o trabalho de criptografia IPsec.
 IMPORTANT
O descarregamento de tarefa IPsec é uma tecnologia herdada que não é suportada pela maioria dos adaptadores de rede
e onde ela existe, está desabilitada por padrão.

Rede de área local virtual privada (PVLAN).

PVLANs permitir 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ísica. Uma rede virtual privada é isolada de
todo o tráfego de rede externo 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 do Hyper-V e do SDN dão suporte apenas ao
modo de porta isolada PVLAN.
para obter detalhes sobre o isolamento de PVLAN, consulte System Center: Blog de engenharia de 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. Compatível com RDMA significa que a NIC (física
ou virtual) é capaz de expor RDMA a um cliente RDMA. Por outro lado, habilitado para RDMA significa que uma
NIC compatível com RDMA está expondo a interface RDMA na pilha.
Para obter mais detalhes sobre o RDMA, consulte acesso remoto direto à memória (RDMA) e comutador
inserido de equipe (Set).

RSS (Receive Side Scaling)

RSS é um recurso de NIC que separa diferentes conjuntos de fluxos e os entrega a processadores diferentes
para processamento. O RSS paralelize o processamento de rede, permitindo que um host seja dimensionado
para taxas de dados muito altas.
Para obter mais detalhes, consulte RSS (receber dimensionamento lateral).

SR-IOV (virtualização de Input-Output de raiz única)

O SR-IOV permite que o tráfego da VM seja movido diretamente da NIC para a VM sem passar pelo host do
Hyper-V. O SR-IOV é uma melhoria incrível no desempenho de uma VM, mas não tem a capacidade de o host
gerenciar esse pipe. Use somente Sr-IOV quando a carga de trabalho estiver bem comparada, confiável e
geralmente a única VM no host.
O tráfego que usa o SR-IOV ignora o comutador do Hyper-V, o que significa que qualquer política, por exemplo,
ACLs ou gerenciamento de largura de banda não será aplicada. O tráfego de SR-IOV também não pode ser
transmitido por meio de qualquer recurso de virtualização de rede; portanto, o encapsulamento VxLAN, GRE ou
não pode ser aplicado. Use somente 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, gerenciamento de largura de banda e tecnologias de
virtualização.
no futuro, duas tecnologias permitirão o SR-IOV: GFT (Generic Flow tables) e o Offload de QoS de Hardware
(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
saltos no aplicativo geral de SR-IOV.
Para obter mais detalhes, consulte visão geral de Sr-IOV (virtualização de e/s de raiz única).

Descarregamento de Chimney TCP

O descarregamento de Chimney TCP, também conhecido como TOE (TCP Engine Offload), é uma tecnologia que
permite que o host descarregue 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
Chimney TCP.

IMPORTANT
O descarregamento de Chimney TCP é uma tecnologia preterida. Recomendamos que você não use o descarregamento
de Chimney TCP, pois a Microsoft pode parar de dar suporte a ele no futuro.

Rede de área local virtual (VLAN)

VLAN é uma extensão para o cabeçalho de quadro de Ethernet para habilitar o particionamento de uma LAN
em várias VLANs, cada uma usando seu próprio espaço de endereço. no Windows Server 2016, as vlans são
definidas em portas do comutador do Hyper-V ou definindo interfaces de equipe em equipes de agrupamento
NIC. Para obter mais informações, consulte agrupamento NIC e redes locais virtuais (VLANs).

VMQ (Fila de Máquina Virtual)

VMQs é um recurso de NIC que aloca uma fila para cada VM. Sempre que você tiver habilitado o Hyper-V; Você
também deve habilitar a VMQ. no Windows Server 2016, VMQs use o comutador NIC vPorts com uma única fila
atribuída ao vPort para fornecer a mesma funcionalidade. Para obter mais informações, consulte vRSS
(recebimento virtual) e agrupamento NIC.

VMMQ (várias filas de máquina virtual)

VMMQ é um recurso de 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. O tráfego é passado para vários LPs na VM como seria em
vRSS, o que permite a entrega de largura de banda de rede substancial para a VM.
 Tecnologias e recursos do hardware apenas (HO)
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

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.

TIP
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)
Descarrega do UDP Checksum (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) :

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 ao quadro de quadros 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 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
deSegmento de Recebimento).
 As propriedades avançadas de NIC
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

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). Para saber mais, confira
Requisitos de rede de host para Azure Stack HCI.
1. No Windows PowerShell , execute o Get NetAdapterAdvancedProperty cmdlet em relação a duas
diferentes make/model de NICs.

Há semelhanças e diferenças nessas duas Listas de Propriedades Avançadas da NIC.

2. Na rede Painel de Controle (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.
 Novos recursos de HPN no Windows Server 2019
13/08/2021 • 2 minutes to read

VRSS dinâmico e VMMQ

Aplica-se a: Azure Stack HCI, versão 20H2; Windows Servidor 2019

No passado, filas de máquina virtual e várias filas de máquinas virtuais permitiam uma taxa de transferência
muito maior para VMs individuais, pois as taxas de transferência de rede atingiram primeiro a marca de 10 GbE
e além. Infelizmente, o planejamento, a base, o ajuste e o monitoramento necessários para o sucesso se
tornaram uma grande tarefa; geralmente mais do que o administrador de IT pretendia gastar.
Windows O Server 2019 aprimora essas otimizações, difundindo e ajustando dinamicamente o processamento
de cargas de trabalho de rede conforme necessário. Windows O Servidor 2019 garante a eficiência máxima e
remove a carga de configuração para os administradores de IT. Para saber mais, confira Requisitos de rede de
host para Azure Stack HCI.
Para obter mais informações, consulte:
Blog do comunicado
Guia de validação para a equipe de PRO

Receber segmento Coalescing (RSC) em vSwitch

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows 10, versão 1809

O RSC (Receive Segment Coalescing) 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 era um descarregado implementado pela NIC. Infelizmente, isso foi desabilitado no
momento em que você anexou o adaptador a um com switch virtual. A 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, a RSC no vSwitch é habilitada em comutadores virtuais externos.
Para obter mais informações, consulte:
Blog do comunicado
Guia de validação para a equipe de PRO
 RSC no vSwitch
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

A RSC ( Coalescing de Segmento de Recebimento) 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 posteriores 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 (Receive Segment Coalescing).

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:
Rede definida pelo software
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:

Get-VMSwitch -Name vSwitchName | Select-Object *RSC*

Habilitar ou desabilitar a RSC no vSwitch

IMPORTANT
Importante: a RSC no vSwitch pode ser habilitada e desabilitada em tempo real sem afetar as conexões existentes.

Desabilitar a RSC no vSwitch

Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $false

Habilitar a RSC no vSwitch

Set-VMSwitch -Name vSwitchName -EnableSoftwareRsc $True

Para obter mais informações, consulte Set-VMSwitch.

 (Diretrizes de configuração da NIC da placa de
interface de rede convergida )
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

NIC de placa de interface de rede convergida ( ) permite expor RDMA por meio de uma - vNIC NIC virtual de
partição de host ( ) para que os serviços de partição de host possam acessar o RDMA de acesso remoto direto à
memória ( ) nas mesmas NICs que os convidados do Hyper-V estão usando para tráfego TCP/IP.
Antes do recurso NIC convergido, os serviços de partição de host de gerenciamento ( ) que desejavam usar o
RDMA eram necessários para usar NICs compatíveis com RDMA dedicados - , mesmo que a largura de banda
estivesse disponível nas NICs que estavam associadas ao comutador virtual Hyper-V.
Com a NIC convergida, as duas cargas de trabalho ( gerenciam os usuários de tráfego de RDMA e convidado )
podem compartilhar as mesmas NICs físicas, permitindo que você instale menos NICs em seus servidores.
quando você implanta a NIC convergida com Windows Server 2016 hosts hyper-v e comutadores virtuais do
hyper-v, o vNICs nos hosts hyper-v expõe serviços RDMA para hospedar processos usando RDMA em qualquer
- tecnologia RDMA baseada em Ethernet.

NOTE
Para usar a tecnologia NIC convergida, os adaptadores de rede certificados em seus servidores devem dar suporte a
RDMA.

Este guia fornece dois conjuntos de instruções, um para implantações em que os servidores têm um único
adaptador de rede instalado, que é uma implantação básica da NIC convergida; e outro conjunto de instruções
em que os servidores têm dois ou mais adaptadores de rede instalados, que é uma implantação de NIC
convergida em uma ( equipe do conjunto de agrupamentos integrado de comutador ) de - adaptadores de rede
habilitado para RDMA.

Pré-requisitos
Veja a seguir os pré-requisitos para as implantações básica e de datacenter da NIC convergida.

NOTE
para os exemplos fornecidos, usamos um adaptador Ethernet Mellanox ConnectX-3 Pro 40 Gbps, mas você pode usar
qualquer um dos adaptadores de rede compatíveis com o Windows Server certified RDMA - que dão suporte a esse
recurso. para obter mais informações sobre adaptadores de rede compatíveis, consulte os cartões de LANdo tópico do
catálogo do Windows Server.

Pré -requisitos básicos da NIC convergida

Para executar as etapas deste guia para a configuração básica da NIC convergida, você deve ter o seguinte.
dois servidores que executam Windows Server 2016 datacenter edition ou Windows Server 2016 Standard
edition.
Um adaptador de rede com capacidade RDMA e certificado instalado em cada servidor.
 Função de servidor Hyper-V instalada em cada servidor.
Pré -requisitos de NIC convergida do datacenter
Para executar as etapas deste guia para a configuração de NIC convergida do datacenter, você deve ter o
seguinte.
dois servidores que executam Windows Server 2016 datacenter edition ou Windows Server 2016 Standard
edition.
Dois adaptadores de rede com capacidade RDMA e certificados instalados em cada servidor.
Função de servidor Hyper-V instalada em cada servidor.
Você deve estar familiarizado com o conjunto de agrupamentos incorporados ( ) de switch, uma solução de
agrupamento NIC alternativa usada em ambientes que incluem o Hyper-V e a pilha de Sdn (rede definida
pelo software) em Windows Server 2016. O conjunto integra algumas funcionalidades de agrupamento NIC
ao comutador virtual Hyper-V. Para obter mais informações, consulte acesso remoto direto à memória
(RDMA) e Comutador incorporado (Set).

Tópicos relacionados
Configuração de NIC convergida com um único adaptador de rede
Configuração NIC agrupada NIC convergida
Configuração de comutador físico para NIC convergida
Solucionando problemas de configurações de NIC convergida
 Configuração de NIC convergida com um único
adaptador de rede
13/08/2021 • 12 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Neste tópico, fornecemos as instruções para configurar a NIC convergida com uma única NIC em seu host
Hyper-V.
A configuração de exemplo neste tópico descreve dois hosts Hyper-V, Host A do Hyper-V e Host Hyper-V B.
Ambos os hosts têm uma única pNIC (NIC física) instalada e as NICs são conectadas a um comutador físico ( ToR
) de rack. Além disso, os hosts estão localizados na mesma sub-rede, que é 192.168.1.x/24.

Etapa 1. Testar a conectividade entre a origem e o destino

Verifique se a NIC física pode se conectar ao host de destino. Este teste demonstra a conectividade usando a
Camada 3 L3 , ou a camada IP, bem ( como a Camada ) 2 ( ) L2.
1. Exibir as propriedades do adaptador de rede.

Get-NetAdapter

Resultados:

IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED

M1 Mellanox 4 Up 7C-FE-90-93- 40 Gbps

ConnectX-3 8F-A1
Pro...

2. Exibir propriedades adicionais do adaptador, incluindo o endereço IP.

Get-NetAdapter M1 | fl *

Resultados:
 MacAddress : 7C-FE-90-93-8F-A1
Status : Up
LinkSpeed: 40 Gbps
MediaType: 802.3
PhysicalMediaType: 802.3
AdminStatus : Up
MediaConnectionState : Connected
DriverInformation: Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60
DriverFileName : mlx4eth63.sys
NdisVersion : 6.60
ifOperStatus : Up
ifAlias : M1
InterfaceAlias : M1
ifIndex : 4
ifDesc : Mellanox ConnectX-3 Pro Ethernet Adapter
ifName : ethernet_32773
DriverVersion: 5.25.12665.0
LinkLayerAddress : 7C-FE-90-93-8F-A1
Caption :
Description :
ElementName :
InstanceID : {39B58B4C-8833-4ED2-A2FD-E105E7146D43}
CommunicationStatus :
DetailedStatus :
HealthState :
InstallDate :
Name : M1
OperatingStatus :
OperationalStatus:
PrimaryStatus:
StatusDescriptions :
AvailableRequestedStates :
EnabledDefault : 2
EnabledState : 5
OtherEnabledState:
RequestedState : 12
TimeOfLastStateChange:
TransitioningToState : 12
AdditionalAvailability :
Availability :
CreationClassName: MSFT_NetAdapter

Etapa 2. Verifique se a origem e o destino podem se comunicar

Nesta etapa, usamos o comando Test-NetConnection Windows PowerShell, mas se você puder usar o
comando ping, se preferir.

TIP
Se você tiver certeza de que os hosts podem se comunicar entre si, ignore esta etapa.

1. Verifique a comunicação bi-direcional.

Test-NetConnection 192.168.1.5

Resultados:
 PA RÂ M ET RO VA LO R

ComputerName 192.168.1.5

RemoteAddress 192.168.1.5

AliasdeInterface M1

SourceAddress 192.168.1.3

PingSucceeded True

PingReplyDetails ( RTT) 0ms

Em alguns casos, talvez seja necessário desabilitar Windows Firewall com Segurança Avançada para executar
esse teste com êxito. Se você desabilitar o firewall, tenha em mente a segurança e verifique se a configuração
atende aos requisitos de segurança da sua organização.
2. Desabilite todos os perfis de firewall.

Set-NetFirewallProfile -All -Enabled False

3. Depois de desabilitar os perfis de firewall, teste a conexão novamente.

Test-NetConnection 192.168.1.5

Resultados:

PA RÂ M ET RO VA LO R

ComputerName 192.168.1.5

RemoteAddress 192.168.1.5

AliasdeInterface Test-40G-1

SourceAddress 192.168.1.3

PingSucceeded Falso

PingReplyDetails ( RTT) 0ms

Etapa 3. (Opcional) Configurar as IDs de VLAN para NICs instaladas

em seus hosts Hyper-V
Muitas configurações de rede usam VLANs e, se você estiver planejando usar VLANs em sua rede, deverá
repetir o teste anterior com VLANs configurados. Além disso, se você estiver planejando usar RoCE para
serviços RDMA, deverá habilitar VLANs.
Para esta etapa, as NICs estão no modo ACCESS. No entanto, quando você cria um vSwitch do Com switch
virtual do Hyper-V posteriormente neste guia, as propriedades da VLAN são aplicadas no nível da porta ( )
vSwitch.
Como uma opção pode hospedar várias VLANs, é necessário que o comutador físico Top of Rack ToR tenha a
porta à que o host está conectado configurado no modo ( ) Tronco.

NOTE
Consulte a documentação da opção ToR para obter instruções sobre como configurar o modo Tronco na opção .

A imagem a seguir mostra dois hosts Hyper-V, cada um com um adaptador de rede física e cada um
configurado para se comunicar na VLAN 101.

IMPORTANT
Execute isso nos servidores locais e de destino. Se o servidor de destino não estiver configurado com a mesma ID de
VLAN que o servidor local, os dois não poderão se comunicar.

1. Configure a ID da VLAN para NICs instaladas em seus hosts Hyper-V.

IMPORTANT
Não execute esse comando se você estiver conectado ao host remotamente por meio dessa interface, pois isso
resulta na perda de acesso ao host.

Set-NetAdapterAdvancedProperty -Name M1 -RegistryKeyword VlanID -RegistryValue "101"

Get-NetAdapterAdvancedProperty -Name M1 | Where-Object {$_.RegistryKeyword -eq "VlanID"}

Resultados:

NOME DISP L AY N A M E DISP L AY VA L UE REGIST RY K EY W O RD REGIST RY VA L UE

M1 ID DA VLAN 101 VlanID {101}

2. Reinicie o adaptador de rede para aplicar a ID da VLAN.

Restart-NetAdapter -Name "M1"

3. Verifique se o Status está Em Cima.

 Get-NetAdapter -Name "M1"

Resultados:

IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED

M1 adaptador 4 Up 7C-FE-90-93- 40 Gbps

Mellanox 8F-A1
ConnectX-3
Pro Ethernet
Ada...

IMPORTANT
Pode levar vários segundos para o dispositivo reiniciar e ficar disponível na rede.

4. Verifique a conectividade.
Se a conectividade falhar, inspecione a configuração do switch VLAN ou a participação de destino na
mesma VLAN.

Test-NetConnection 192.168.1.5

Etapa 4. Configurar a qualidade do serviço ( QoS)

NOTE
Você deve executar todas as seguintes etapas de configuração de DCB e QoS em todos os hosts que se destinam a se
comunicar entre si.

1. Instale o Data Center Bridge ( DCB ) em cada um dos hosts do Hyper-V.

Opcional para configurações de rede que usam iWarp para serviços RDMA.
Necessário para configurações de rede que usam RoCE ( qualquer versão ) para serviços RDMA.

Install-WindowsFeature Data-Center-Bridging

2. Defina as políticas de QoS para o SMB – Direct:

Opcional para configurações de rede que usam iWarp.
Necessário para configurações de rede que usam RoCE.
No comando de exemplo abaixo, o valor "3" é arbitrário. Você pode usar qualquer valor entre 1 e 7, desde
que você use consistentemente o mesmo valor em toda a configuração de políticas de QoS.

New-NetQosPolicy "SMB" -NetDirectPortMatchCondition 445 -PriorityValue8021Action 3

Da
 PA RÂ M ET RO VA LO R

Nome SMB

Proprietário (Máquina política de grupo)

NetworkProfile Tudo

Precedência 127

JobObject

NetDirectPort 445

Prioridadevalue 3

3. para implantações de RoCE, ative o controle de prioridade Flow para o tráfego SMB, o que não é
necessário para o iWarp.

Enable-NetQosFlowControl -priority 3
Get-NetQosFlowControl

Da

P RIO RIDA DE H A B IL ITA DA P O L ÍT IC A DE IF IN DEX IFA L IA S

0 Falso Global

1 Falso Global

2 Falso Global

3 True Global

4 Falso Global

5 Falso Global

6 Falso Global

7 Falso Global

4. Habilite a QoS para os adaptadores de rede local e de destino.

Não é necessário para configurações de rede que usam iWarp.
Necessário para configurações de rede que usam RoCE.

Enable-NetAdapterQos -InterfaceAlias "M1"

Get-NetAdapterQos -Name "M1"

Da
 Nome : M1 habilitado : verdadeiro
Técnicas

PA RÂ M ET RO H A RDWA RE C URREN T

MacSecBypass NotSupported NotSupported

DcbxSupport Nenhum Nenhum

NumTCs (Max/ETS/PFC) 8/8/8 8/8/8

OperationalTrafficClasses:

TC T SA L A RGURA DE B A N DA P RIO RIDA DES

0 ETS 70% 0-2, 4-7

1 ETS 30% 3

OperationalFlowControl:
Prioridade 3 habilitada
OperationalClassifications:

P ROTO C O LO P O RTA / T IP O P RIO RIDA DE

Padrão 0

NetDirect 445 3

5. Reserve um percentual da largura de banda para o RDMA do SMB Direct ( ) .

Neste exemplo, uma reserva de largura de banda de 30% é usada. Você deve selecionar um valor que
represente o que você espera que seu tráfego de armazenamento exija.

New-NetQosTrafficClass "SMB" -Priority 3 -BandwidthPercentage 30 -Algorithm ETS

Da

L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S

SMB ETS 30 3 Global

6. Exibir as configurações de reserva de largura de banda.

Get-NetQosTrafficClass

Da
 L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S

Os ETS 70 0-2, 4-7 Global

SMB ETS 30 3 Global

Etapa 5. Adicional Resolver o conflito do depurador do adaptador

Mellanox
Por padrão, ao usar um adaptador Mellanox, o depurador anexado bloqueia NetQos, que é um problema
conhecido. Portanto, se você estiver usando um adaptador de Mellanox e pretender anexar um depurador, use o
seguinte comando resolver esse problema. Essa etapa não será necessária se você não pretender anexar um
depurador ou se não estiver usando um adaptador Mellanox.

Set-ItemProperty HKLM:"\SYSTEM\CurrentControlSet\Services\NDIS\Parameters" AllowFlowControlUnderDebugger -

type DWORD -Value 1 –Force

Etapa 6. Verificar a configuração de RDMA (host nativo)

Você deseja garantir que a malha esteja configurada corretamente antes de criar um vSwitch e fazer a transição
para RDMA (NIC convergida).
A imagem a seguir mostra o estado atual dos hosts Hyper-V.

1. Verifique a configuração de RDMA.

Get-NetAdapterRdma

Da

NOME IN T ERFA C EDESC RIP T IO N H A B IL ITA DA

M1 adaptador de Ethernet Mellanox True

ConnectX-3 Pro

2. Determine o valor ifIndex do adaptador de destino.

Você usará esse valor em etapas subsequentes ao executar o script baixado.
 Get-NetIPConfiguration -InterfaceAlias "M*" | ft InterfaceAlias,InterfaceIndex,IPv4Address

Da

A L IA SDEIN T ERFA C E IN T ERFA C EIN DEX IP V4A DDRESS

M2 14 {192.168.1.5}

3. Baixe o utilitárioDiskSpd.exe e extraia-o em C:\test.

4. Baixe o script do PowerShell Test-RDMA para uma pasta de teste em sua unidade local, por exemplo,
C:\test.
5. Execute o Test-Rdma.ps1 script do PowerShell para passar o valor ifIndex para o script, junto com o
endereço IP do adaptador remoto na mesma VLAN.
Neste exemplo, o script passa o valor ifIndex de 14 no endereço IP do adaptador de rede remoto
192.168.1.5.

C:\TEST\Test-RDMA.PS1 -IfIndex 14 -IsRoCE $true -RemoteIpAddress 192.168.1.5 -PathToDiskspd

C:\TEST\Diskspd-v2.0.17\amd64fre\

VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\\diskspd.exe

VERBOSE: The adapter M2 is a physical adapter
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.1.5, is reachable.
VERBOSE: Remote IP 192.168.1.5 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 662979201 RDMA bytes written per second
VERBOSE: 37561021 RDMA bytes sent per second
VERBOSE: 1023098948 RDMA bytes written per second
VERBOSE: 8901349 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior
to sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.1.5

NOTE
Se o tráfego RDMA falhar, para o caso RoCE especificamente, consulte a configuração do comutador ToR para
configurações apropriadas de PFC/ETS que devem corresponder às configurações do host. Consulte a seção QoS
neste documento para obter os valores de referência.

Etapa 7. Remover a configuração de VLAN de acesso

Em preparação para criar a opção Hyper-V, você deve remover as configurações de VLAN instaladas acima.
1. Remova a configuração de VLAN de acesso da NIC física para impedir que a NIC marcação
automaticamente o tráfego de saída com a ID de VLAN incorreta.
A remoção dessa configuração também impede que ela filtre o tráfego de entrada que não corresponda à
 ID de VLAN de acesso.

Set-NetAdapterAdvancedProperty -Name M1 -RegistryKeyword VlanID -RegistryValue "0"

2. Confirme se a configuração de vlanid mostra o valor da ID de VLAN como zero.

Get-NetAdapterAdvancedProperty -name m1 | Where-Object {$_.RegistryKeyword -eq 'VlanID'}

Etapa 8. Criar um vSwitch do Hyper-V em seus hosts Hyper-V

A imagem a seguir ilustra o host do Hyper-V 1 com um vSwitch.

1. Crie um vSwitch Hyper-V externo no Hyper-v no host A do Hyper-V.

Neste exemplo, a opção é denominada VMSTEST. Além disso, o parâmetro AllowManagementOS cria
um host vNIC que herda os endereços MAC e IP da NIC física.

New-VMSwitch -Name VMSTEST -NetAdapterName "M1" -AllowManagementOS $true

Da

N ETA DA P T ERIN T ERFA C EDESC RIP T I

NOME SW ITC H T Y P E ON

VMSTEST Externo adaptador de Ethernet Mellanox

ConnectX-3 Pro

2. Exiba as propriedades do adaptador de rede.

Get-NetAdapter | ft -AutoSize

Da
 IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED

vEthernet ( Adaptador 27 Up E4-1D-2D-07- 40 Gbps

VMSTEST) Ethernet Virtual 40-71
do Hyper-V #2

3. Gerencie a vNIC do host de uma das duas maneiras.

A exibição NetAdapter opera com base no nome "vEthernet ( VMSTEST". ) Nem todas as
propriedades do adaptador de rede são exibidas nessa exibição.
A exibição VMNetworkAdapter descarta o prefixo "vEthernet" e simplesmente usa o nome
vmswitch. (Recomendado)

Get-VMNetworkAdapter –ManagementOS | ft -AutoSize

Resultados:

ISM A N A GEM SW ITC H N A M M A C A DDRES IPA DDRESSE

NOME EN TO S VM N A M E E S STAT US S

CORP- True CORP- 001B785768 {OK}

External- External- AAA
Switch Switch

VMSTEST True VMSTEST E41D2D074 {OK}

071

4. Teste a conexão.

Test-NetConnection 192.168.1.5

Resultados:

ComputerName : 192.168.1.5
RemoteAddress : 192.168.1.5
InterfaceAlias : vEthernet (CORP-External-Switch)
SourceAddress : 192.168.1.3
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms

5. Atribuir e exibir as configurações de VLAN do adaptador de rede.

Set-VMNetworkAdapterVlan -VMNetworkAdapterName "VMSTEST" -VlanId "101" -Access -ManagementOS

Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "VMSTEST"

Resultados:

VM N ET W O RK A DA P T ERN A
VM N A M E ME M O DE VL A N L IST

VMSTEST Access 101

6. Teste a conexão.
Pode levar alguns segundos para ser concluído antes que você possa fazer ping com êxito no outro
adaptador.

Test-NetConnection 192.168.1.5

Resultados:

ComputerName : 192.168.1.5
RemoteAddress : 192.168.1.5
InterfaceAlias : vEthernet (VMSTEST)
SourceAddress : 192.168.1.3
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms

Etapa 9. Testar o RDMA do Comutr Virtual do Hyper-V (Modo 2)

A imagem a seguir ilustra o estado atual de seus hosts Hyper-V, incluindo o vSwitch no Host hyper-V 1.

1. De definir a marcação de prioridade na vNIC do host.

Set-VMNetworkAdapter -ManagementOS -Name "VMSTEST" -IeeePriorityTag on

Get-VMNetworkAdapter -ManagementOS -Name "VMSTEST" | fl Name,IeeePriorityTag

Resultados:
Nome: VMSTEST IeeePriorityTag: On
2. Exibir as informações de RDMA do adaptador de rede.

Get-NetAdapterRdma

Resultados:

NOME IN T ERFA C EDESC RIP T IO N H A B IL ITA DA

vEthernet ( VMSTEST) Adaptador Ethernet Virtual do Falso

Hyper-V #2
 NOTE
Se o parâmetro Enabled tiver o valor False , isso significa que o RDMA não está habilitado.

3. Exibir as informações do adaptador de rede.

Get-NetAdapter

Resultados:

IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED

vEthernet Adaptador 27 Up E4-1D-2D-07- 40 Gbps

(VMSTEST) Ethernet Virtual 40-71
do Hyper-V #2

4. Habilita o RDMA na vNIC do host.

Enable-NetAdapterRdma -Name "vEthernet (VMSTEST)"

Get-NetAdapterRdma -Name "vEthernet (VMSTEST)"

Resultados:

NOME IN T ERFA C EDESC RIP T IO N H A B IL ITA DA

vEthernet ( VMSTEST) Adaptador Ethernet Virtual do True

Hyper-V #2

NOTE
Se o parâmetro Enabled tiver o valor True , isso significa que o RDMA está habilitado.

5. Execute o teste de tráfego RDMA.

 C:\TEST\Test-RDMA.PS1 -IfIndex 27 -IsRoCE $true -RemoteIpAddress 192.168.1.5 -PathToDiskspd
C:\TEST\Diskspd-v2.0.17\amd64fre\
VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\\diskspd.exe
VERBOSE: The adapter vEthernet (VMSTEST) is a virtual adapter
VERBOSE: Retrieving vSwitch bound to the virtual adapter
VERBOSE: Found vSwitch: VMSTEST
VERBOSE: Found the following physical adapter(s) bound to vSwitch: TEST-40G-1
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.1.5, is reachable.
VERBOSE: Remote IP 192.168.1.5 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 9162492 RDMA bytes sent per second
VERBOSE: 938797258 RDMA bytes written per second
VERBOSE: 34621865 RDMA bytes sent per second
VERBOSE: 933572610 RDMA bytes written per second
VERBOSE: 35035861 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior
to sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.1.5

A linha final nesta saída, "Teste de tráfego RDMA BEM-sucedido: o tráfego RDMA foi enviado para 192.168.1.5",
mostra que você configurou com êxito a NIC convergida em seu adaptador.

Tópicos relacionados
Configuração de NIC em NIC convergida
Configuração do com switch físico para NIC convergida
Solução de problemas de configurações de NIC convergida
 NIC convergida em uma configuração de NIC em
equipe (datacenter)
12/08/2021 • 24 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Neste tópico, fornecemos instruções para implantar a NIC convergida em uma configuração de NIC com Switch
Embedded Teaming ( SET ) .
A configuração de exemplo neste tópico descreve dois hosts Hyper-V, Host Hyper-V 1 e Host Hyper-V 2.
Ambos os hosts têm dois adaptadores de rede. Em cada host, um adaptador é conectado à sub-rede
192.168.1.x/24 e um adaptador está conectado à sub-rede 192.168.2.x/24.

Etapa 1. Testar a conectividade entre a origem e o destino

Verifique se a NIC física pode se conectar ao host de destino. Este teste demonstra a conectividade usando a
Camada 3 L3 – ou a camada IP – bem como a VLAN de redes locais virtuais de Camada ( ) ( 2 ) ( ) L2.
1. Exibir as primeiras propriedades do adaptador de rede.

Get-NetAdapter -Name "Test-40G-1" | ft -AutoSize

Resultados:

IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED

Test-40G-1 Adaptador 11 Up E4-1D-2D-07- 40 Gbps

Ethernet de Pro 43-D0
Mellanox
ConnectX-3

2. Exibir propriedades adicionais para o primeiro adaptador, incluindo o endereço IP.

 Get-NetIPAddress -InterfaceAlias "Test-40G-1"
Get-NetIPAddress -InterfaceAlias "TEST-40G-1" | Where-Object {$_.AddressFamily -eq "IPv4"} | fl
InterfaceAlias,IPAddress

Resultados:

PA RÂ M ET RO VA LO R

IPAddress 192.168.1.3

Interfaceindex 11

AliasdeInterface Test-40G-1

Addressfamily IPv4

Tipo Unicast

PrefixLength 24

3. Exibir as segundas propriedades do adaptador de rede.

Get-NetAdapter -Name "Test-40G-2" | ft -AutoSize

Resultados:

IN T ERFA C EDES
NOME C RIP T IO N SE_ÍN DIC E STAT US M A C A DDRESS L IN K SP EED

TEST-40G-2 Mellanox 13 Up E4-1D-2D-07- 40 Gbps

ConnectX-3 40-70
Pro Ethernet
A... #2

4. Exibir propriedades adicionais para o segundo adaptador, incluindo o endereço IP.

Get-NetIPAddress -InterfaceAlias "Test-40G-2"

Get-NetIPAddress -InterfaceAlias "Test-40G-2" | Where-Object {$_.AddressFamily -eq "IPv4"} | fl
InterfaceAlias,IPAddress

Resultados:

PA RÂ M ET RO VA LO R

IPAddress 192.168.2.3

Interfaceindex 13

AliasdeInterface TEST-40G-2

Addressfamily IPv4

Tipo Unicast
 PA RÂ M ET RO VA LO R

PrefixLength 24

5. Verifique se outros pNICs de membro set ou equipe NIC têm um endereço IP válido.
Use uma sub-rede separada, ( xxx.xxx.2 .xxx versus xxx.xxx. 1 .xxx ) , para facilitar o envio desse adaptador
para o destino. Caso contrário, se você localizar ambos os pNICs na mesma sub-rede, o Windows
balancear a carga da pilha TCP/IP entre as interfaces e a validação simples se tornará mais complicado.

Etapa 2. Verifique se a origem e o destino podem se comunicar

Nesta etapa, usamos o comando Test-NetConnection Windows PowerShell, mas se você puder usar o
comando ping, se preferir.
1. Verifique a comunicação bi-direcional.

Test-NetConnection 192.168.1.5

Resultados:

PA RÂ M ET RO VA LO R

ComputerName 192.168.1.5

RemoteAddress 192.168.1.5

AliasdeInterface Test-40G-1

SourceAddress 192.168.1.3

PingSucceeded Falso

PingReplyDetails ( RTT) 0ms

Em alguns casos, talvez seja necessário desabilitar Windows Firewall com Segurança Avançada para
executar esse teste com êxito. Se você desabilitar o firewall, tenha em mente a segurança e verifique se a
configuração atende aos requisitos de segurança da sua organização.
2. Desabilite todos os perfis de firewall.

Set-NetFirewallProfile -All -Enabled False

3. Depois de desabilitar os perfis de firewall, teste a conexão novamente.

Test-NetConnection 192.168.1.5

Resultados:

PA RÂ M ET RO VA LO R

ComputerName 192.168.1.5
 PA RÂ M ET RO VA LO R

RemoteAddress 192.168.1.5

AliasdeInterface Test-40G-1

SourceAddress 192.168.1.3

PingSucceeded Falso

RTT de PingReplyDetails () 0ms

4. Verifique a conectividade para NICs adicionais. Repita as etapas anteriores para todos os pNICs
subsequentes incluídos na NIC ou no conjunto de equipe.

Test-NetConnection 192.168.2.5

Da

PA RÂ M ET RO VA LO R

ComputerName 192.168.2.5

RemoteAddress 192.168.2.5

AliasdeInterface Teste-40G-2

SourceAddress 192.168.2.3

PingSucceeded Falso

RTT de PingReplyDetails () 0ms

Etapa 3. Configurar as IDs de VLAN para NICs instaladas em seus

hosts Hyper-V
Muitas configurações de rede fazem uso de VLANs e, se você estiver planejando usar VLANs em sua rede,
deverá repetir o teste anterior com VLANs configuradas.
Para esta etapa, as NICs estão no modo de acesso . No entanto, quando você cria um comutador virtual do
Hyper-V ( vSwitch ) posteriormente neste guia, as propriedades de VLAN são aplicadas no nível de porta
vSwitch.
Como uma opção pode hospedar várias VLANs, é necessário que a parte superior da ( chave física ToR do rack )
tenha a porta que o host está conectado para ser configurada no modo de tronco.

NOTE
Consulte a documentação do comutador ToR para obter instruções sobre como configurar o modo de tronco no
comutador.

A imagem a seguir mostra dois hosts Hyper-V com dois adaptadores de rede cada um com VLAN 101 e VLAN
102 configurados nas propriedades do adaptador de rede.

TIP
De acordo com os padrões de rede IEEE do Instituto de engenheiros elétricos e eletrônicos ( ) , as propriedades de QoS de
qualidade de serviço ( ) na NIC física agem no cabeçalho 802.1 p que é inserido no ( cabeçalho VLAN 802.1 q ) quando
você configura a ID de VLAN.

1. Configure a ID de VLAN na primeira NIC, Test-40G-1.

Set-NetAdapterAdvancedProperty -Name "Test-40G-1" -RegistryKeyword VlanID -RegistryValue "101"

Get-NetAdapterAdvancedProperty -Name "Test-40G-1" | Where-Object {$_.RegistryKeyword -eq "VlanID"} |
ft -AutoSize

Da

NOME DISP L AY N A M E DISP L AY VA L UE REGIST RY K EY W O RD REGIST RO VA L UE

TEST-40G-1 ID DA VLAN 101 VlanID {101}

2. Reinicie o adaptador de rede para aplicar a ID de VLAN.

Restart-NetAdapter -Name "Test-40G-1"

3. Verifique se o status está ativo .

Get-NetAdapter -Name "Test-40G-1" | ft -AutoSize

Da

IN T ERFA C EDES
NOME C RIP T IO N IF IN DEX STAT US M A C A DDRESS L IN K SP EED

Test-40G-1 adaptador 11 Up E4-1D-2D-07- 40 Gbps

Mellanox 43-D0
ConnectX-3
Pro Ethernet
Ada...

4. Configure a ID de VLAN na segunda NIC, Test-40G-2.

 Set-NetAdapterAdvancedProperty -Name "Test-40G-2" -RegistryKeyword VlanID -RegistryValue "102"
Get-NetAdapterAdvancedProperty -Name "Test-40G-2" | Where-Object {$_.RegistryKeyword -eq "VlanID"} |
ft -AutoSize

Da

NOME DISP L AY N A M E DISP L AY VA L UE REGIST RY K EY W O RD REGIST RO VA L UE

TESTE-40G-2 ID DA VLAN 102 VlanID {102}

5. Reinicie o adaptador de rede para aplicar a ID de VLAN.

Restart-NetAdapter -Name "Test-40G-2"

6. Verifique se o status está ativo .

Get-NetAdapter -Name "Test-40G-1" | ft -AutoSize

Da

IN T ERFA C EDES
NOME C RIP T IO N IF IN DEX STAT US M A C A DDRESS L IN K SP EED

Teste-40G-2 adaptador 11 Up E4-1D-2D-07- 40 Gbps

Mellanox 43-D1
ConnectX-3
Pro Ethernet
Ada...

IMPORTANT
Pode levar vários segundos para o dispositivo reiniciar e ficar disponível na rede.

7. Verifique a conectividade da primeira NIC, Test-40G-1.

Se a conectividade falhar, inspecione a configuração do switch VLAN ou a participação de destino na
mesma VLAN.

Test-NetConnection 192.168.1.5

Da

PA RÂ M ET RO VA LO R

ComputerName 192.168.1.5

RemoteAddress 192.168.1.5

AliasdeInterface Test-40G-1

SourceAddress 192.168.1.5
 PA RÂ M ET RO VA LO R

PingSucceeded True

RTT de PingReplyDetails () 0ms

8. Verifique a conectividade da primeira NIC, Test-40G-2.

Se a conectividade falhar, inspecione a configuração do switch VLAN ou a participação de destino na
mesma VLAN.

Test-NetConnection 192.168.2.5

Da

PA RÂ M ET RO VA LO R

ComputerName 192.168.2.5

RemoteAddress 192.168.2.5

AliasdeInterface Teste-40G-2

SourceAddress 192.168.2.3

PingSucceeded True

RTT de PingReplyDetails () 0ms

IMPORTANT
Não é incomum para um Test-NetConnection ou a falha de ping ocorrer imediatamente após a execução de
Restar t-netadapter . Portanto, aguarde até que o adaptador de rede seja inicializado completamente e tente
novamente.
Se as conexões de VLAN 101 funcionarem, mas as conexões de VLAN 102 não, o problema pode ser que a opção
precisa ser configurada para permitir o tráfego de porta na VLAN desejada. Você pode verificar isso Configurando
temporariamente os adaptadores com falha para a VLAN 101 e repetindo o teste de conectividade.

A imagem a seguir mostra os hosts do Hyper-V após configurar com êxito as VLANs.
Etapa 4. Configurar a qualidade do serviço ( QoS)
NOTE
Você deve executar todas as seguintes etapas de configuração de DCB e QoS em todos os hosts que se destinam a se
comunicar entre si.

1. Instale o Data Center Bridge ( DCB ) em cada um dos hosts do Hyper-V.

Opcional para configurações de rede que usam iWarp.
Necessário para configurações de rede que usam RoCE ( qualquer versão ) para serviços RDMA.

Install-WindowsFeature Data-Center-Bridging

Da

REIN IC IA L IZ A Ç Ã O
ÊXITO N EC ESSÁ RIA C Ó DIGO DE SA ÍDA RESULTA DO DO REC URSO

True Não Êxito {Ponte do Data Center}

2. Defina as políticas de QoS para o SMB – Direct:

Opcional para configurações de rede que usam iWarp.
Necessário para configurações de rede que usam RoCE ( qualquer versão ) para serviços RDMA.
No comando de exemplo abaixo, o valor "3" é arbitrário. Você pode usar qualquer valor entre 1 e 7, desde
que você use consistentemente o mesmo valor em toda a configuração de políticas de QoS.

New-NetQosPolicy "SMB" -NetDirectPortMatchCondition 445 -PriorityValue8021Action 3

Da

PA RÂ M ET RO VA LO R

Nome SMB

Proprietário (Máquina política de grupo)

 PA RÂ M ET RO VA LO R

NetworkProfile Tudo

Precedência 127

JobObject

NetDirectPort 445

Prioridadevalue 3

3. Defina políticas de QoS adicionais para outro tráfego na interface.

New-NetQosPolicy "DEFAULT" -Default -PriorityValue8021Action 0

Da

PA RÂ M ET RO VA LO R

Nome DEFAULT

Proprietário (Máquina política de grupo)

NetworkProfile Tudo

Precedência 127

Modelo Padrão

JobObject

Prioridadevalue 0

4. ative o controle de prioridade Flow para o tráfego SMB, o que não é necessário para iWarp.

Enable-NetQosFlowControl -priority 3
Get-NetQosFlowControl

Da

P RIO RIDA DE H A B IL ITA DA P O L ÍT IC A DE IF IN DEX IFA L IA S

0 Falso Global

1 Falso Global

2 Falso Global

3 True Global

4 Falso Global
 P RIO RIDA DE H A B IL ITA DA P O L ÍT IC A DE IF IN DEX IFA L IA S

5 Falso Global

6 Falso Global

7 Falso Global

Impor tante Se os resultados não corresponderem a esses resultados porque itens diferentes de 3
têm um valor habilitado de true, você deve desabilitar FlowControl para essas classes.

Disable-NetQosFlowControl -priority 0,1,2,4,5,6,7

Get-NetQosFlowControl

Em configurações mais complexas, as outras classes de tráfego podem exigir controle de fluxo, no
entanto, esses cenários estão fora do escopo deste guia.

5. Habilite a QoS para a primeira NIC, Test-40G-1.

Enable-NetAdapterQos -InterfaceAlias "Test-40G-1"

Get-NetAdapterQos -Name "Test-40G-1"

Name: TEST-40G-1
Enabled: True

Recursos :

PA RÂ M ET RO H A RDWA RE C URREN T

MacSecBypass NotSupported NotSupported

DcbxSupport Nenhum Nenhum

NumTCs (Max/ETS/PFC) 8/8/8 8/8/8

OperationalTrafficClasses :

TC T SA L A RGURA DE B A N DA P RIO RIDA DES

0 Rigoroso 0-7

OperationalFlowControl :
Prioridade 3 habilitada
OperationalClassifications :

P ROTO C O LO P O RTA / T IP O P RIO RIDA DE

Padrão 0

NetDirect 445 3
6. Habilite a QoS para a segunda NIC, Test-40G-2.

Enable-NetAdapterQos -InterfaceAlias "Test-40G-2"

Get-NetAdapterQos -Name "Test-40G-2"

Name: TEST-40G-2
Enabled: True

Recursos :

PA RÂ M ET RO H A RDWA RE C URREN T

MacSecBypass NotSupported NotSupported

DcbxSupport Nenhum Nenhum

NumTCs (Max/ETS/PFC) 8/8/8 8/8/8

OperationalTrafficClasses :

TC T SA L A RGURA DE B A N DA P RIO RIDA DES

0 Rigoroso 0-7

OperationalFlowControl :
Prioridade 3 habilitada
OperationalClassifications :

P ROTO C O LO P O RTA / T IP O P RIO RIDA DE

Padrão 0

NetDirect 445 3

7. Reserve metade da largura de banda para o RDMA do SMB Direct ()

New-NetQosTrafficClass "SMB" -priority 3 -bandwidthpercentage 50 -algorithm ETS

Da

L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S

SMB ETS 50 3 Global

8. Exibir as configurações de reserva de largura de banda:

Get-NetQosTrafficClass | ft -AutoSize

Da
 L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S

Os ETS 50 0-2, 4-7 Global

SMB ETS 50 3 Global

9. Adicional Crie duas classes de tráfego adicionais para o tráfego IP de locatário.

TIP
Você pode omitir os valores "IP1" e "IP2".

New-NetQosTrafficClass "IP1" -Priority 1 -bandwidthpercentage 10 -algorithm ETS

Da

L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S

IP1 ETS 10 1 Global

New-NetQosTrafficClass "IP2" -Priority 2 -bandwidthpercentage 10 -algorithm ETS

Da

L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S

IP2 ETS 10 2 Global

10. Exiba as classes de tráfego de QoS.

Get-NetQosTrafficClass | ft -AutoSize

Da

L A RGURA DE
NOME A L GO RIT M O B A N DA ( % ) P RIO RIDA DE P O L ÍT IC A DE IF IN DEX IFA L IA S

Os ETS 30 0, 4-7 Global

SMB ETS 50 3 Global

IP1 ETS 10 1 Global

IP2 ETS 10 2 Global

11. Adicional Substitua o depurador.

Por padrão, o depurador anexado bloqueia NetQos.
 Set-ItemProperty HKLM:"\SYSTEM\CurrentControlSet\Services\NDIS\Parameters"
AllowFlowControlUnderDebugger -type DWORD -Value 1 –Force
Get-ItemProperty HKLM:"\SYSTEM\CurrentControlSet\Services\NDIS\Parameters" | ft
AllowFlowControlUnderDebugger

Da

AllowFlowControlUnderDebugger
-----------------------------
1

Etapa 5. Verifique o modo de configuração RDMA ( 1)

Você deseja garantir que a malha esteja configurada corretamente antes de criar um vSwitch e fazer a transição
para o ( modo RDMA 2 ) .
A imagem a seguir mostra o estado atual dos hosts Hyper-V.

1. Verifique a configuração de RDMA.

Get-NetAdapterRdma | ft -AutoSize

Da

NOME IN T ERFA C EDESC RIP T IO N H A B IL ITA DA

TEST-40G-1 Adaptador de VPI Mellanox True

ConnectX-4 #2

TESTE-40G-2 Adaptador de VPI Mellanox True

ConnectX-4

2. Determine o valor ifIndex de seus adaptadores de destino.

Você usará esse valor em etapas subsequentes ao executar o script baixado.

Get-NetIPConfiguration -InterfaceAlias "TEST*" | ft InterfaceAlias,InterfaceIndex,IPv4Address

Da
 A L IA SDEIN T ERFA C E IN T ERFA C EIN DEX IP V4A DDRESS

TEST-40G-1 14 192.168.1.3

TESTE-40G-2 13 {192.168.2.3}

3. Baixe o utilitárioDiskSpd.exe e extraia-o em C:\test.

4. Baixe o script do PowerShell Test-RDMA para uma pasta de teste em sua unidade local, por exemplo,
C:\test.
5. Execute o Test-Rdma.ps1 script do PowerShell para passar o valor ifIndex para o script, junto com o
endereço IP do primeiro adaptador remoto na mesma VLAN.
Neste exemplo, o script passa o valor ifIndex de 14 no endereço IP do adaptador de rede remoto
192.168.1.5.

C:\TEST\Test-RDMA.PS1 -IfIndex 14 -IsRoCE $true -RemoteIpAddress 192.168.1.5 -PathToDiskspd

C:\TEST\Diskspd-v2.0.17\amd64fre\

Da

VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\diskspd.exe

VERBOSE: The adapter M2 is a physical adapter
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.1.5, is reachable.
VERBOSE: Remote IP 192.168.1.5 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 662979201 RDMA bytes written per second
VERBOSE: 37561021 RDMA bytes sent per second
VERBOSE: 1023098948 RDMA bytes written per second
VERBOSE: 8901349 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior to
sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.1.5

NOTE
Se o tráfego RDMA falhar, para o caso RoCE especificamente, consulte a configuração do comutador ToR para
configurações apropriadas de PFC/ETS que devem corresponder às configurações do host. Consulte a seção QoS
neste documento para obter os valores de referência.

6. Execute o Test-Rdma.ps1 script do PowerShell para passar o valor ifIndex para o script, junto com o
endereço IP do segundo adaptador remoto na mesma VLAN.
Neste exemplo, o script passa o valor ifIndex de 13 no endereço IP do adaptador de rede remoto
192.168.2.5.
 C:\TEST\Test-RDMA.PS1 -IfIndex 13 -IsRoCE $true -RemoteIpAddress 192.168.2.5 -PathToDiskspd
C:\TEST\Diskspd-v2.0.17\amd64fre\

Da

VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\diskspd.exe

VERBOSE: The adapter TEST-40G-2 is a physical adapter
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.2.5, is reachable.
VERBOSE: Remote IP 192.168.2.5 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 541185606 RDMA bytes written per second
VERBOSE: 34821478 RDMA bytes sent per second
VERBOSE: 954717307 RDMA bytes written per second
VERBOSE: 35040816 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior to
sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.2.5

Etapa 6. Criar um vSwitch do Hyper-V em seus hosts Hyper-V

A imagem a seguir mostra o host do Hyper-V 1 com um vSwitch.

1. Crie um vSwitch no modo SET no host do Hyper-V 1.

New-VMSwitch –Name "VMSTEST" –NetAdapterName "TEST-40G-1","TEST-40G-2" -EnableEmbeddedTeaming $true -

AllowManagementOS $true

Disso

N ETA DA P T ERIN T ERFA C EDESC RIP T I

NOME SW ITC H T Y P E ON

VMSTEST Externo Teamed-Interface

2. Exiba a equipe do adaptador físico no conjunto.

Get-VMSwitchTeam -Name "VMSTEST" | fl

 Da

Name: VMSTEST
Id: ad9bb542-dda2-4450-a00e-f96d44bdfbec
NetAdapterInterfaceDescription: {Mellanox ConnectX-3 Pro Ethernet Adapter, Mellanox ConnectX-3 Pro
Ethernet Adapter #2}
TeamingMode: SwitchIndependent
LoadBalancingAlgorithm: Dynamic

3. Exibir duas exibições do host vNIC

Get-NetAdapter

Da

IN T ERFA C EDES
NOME C RIP T IO N IF IN DEX STAT US M A C A DDRESS L IN K SP EED

vEthernet #2 de 28 Up E4-1D-2D-07- 80 Gbps

(VMSTEST) adaptador 40-71
Ethernet virtual
do Hyper-V

4. Exiba as propriedades adicionais do host vNIC.

Get-VMNetworkAdapter -ManagementOS

Da

ISM A N A GEM SW ITC H N A M M A C A DDRES IPA DDRESSE

NOME EN TO S VM N A M E E S STAT US S

VMSTEST True VMSTEST E41D2D074 Problemas

071

5. Teste a conexão de rede com o adaptador remoto VLAN 101.

Test-NetConnection 192.168.1.5

Da

WARNING: Ping to 192.168.1.5 failed -- Status: DestinationHostUnreachable

ComputerName : 192.168.1.5
RemoteAddress : 192.168.1.5
InterfaceAlias : vEthernet (CORP-External-Switch)
SourceAddress : 10.199.48.170
PingSucceeded : False
PingReplyDetails (RTT) : 0 ms

Etapa 7. Remover a configuração de VLAN de acesso

Nesta etapa, você remove a configuração de VLAN de acesso da NIC física e para definir a VLANid usando o
vSwitch.
Você deve remover a configuração de VLAN de acesso para impedir a marcação automática do tráfego de saída
com a ID de VLAN incorreta e a filtragem do tráfego de entrada que não corresponde à ID de VLAN de acesso.
1. Remova a configuração.

Set-NetAdapterAdvancedProperty -Name "Test-40G-1" -RegistryKeyword VlanID -RegistryValue "0"

Set-NetAdapterAdvancedProperty -Name "Test-40G-2" -RegistryKeyword VlanID -RegistryValue "0"

2. Defina a ID da VLAN.

Set-VMNetworkAdapterVlan -VMNetworkAdapterName "VMSTEST" -VlanId "101" -Access -ManagementOS

Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "VMSTEST"

Da

VMName VMNetworkAdapterName Mode VlanList

------ -------------------- ---- --------
VMSTEST Access 101

3. Teste a conexão de rede.

Test-NetConnection 192.168.1.5

Da

ComputerName : 192.168.1.5
RemoteAddress : 192.168.1.5
InterfaceAlias : vEthernet (VMSTEST)
SourceAddress : 192.168.1.3
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms

Impor tante Se os resultados não forem semelhantes aos resultados de exemplo e o ping falhar com
a mensagem "aviso: ping para 192.168.1.5 falhou--status: DestinationHostUnreachable", confirme se
o "vEthernet (VMSTEST)" tem o endereço IP adequado.

Get-NetIPAddress -InterfaceAlias "vEthernet (VMSTEST)"

Se o endereço IP não estiver definido, corrija o problema.

 New-NetIPAddress -InterfaceAlias "vEthernet (VMSTEST)" -IPAddress 192.168.1.3 -PrefixLength 24

IPAddress : 192.168.1.3
InterfaceIndex: 37
InterfaceAlias: vEthernet (VMSTEST)
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Manual
SuffixOrigin : Manual
AddressState : Tentative
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : ActiveStore

4. Renomeie a NIC de gerenciamento.

Rename-VMNetworkAdapter -ManagementOS -Name “VMSTEST” -NewName “MGT”

Get-VMNetworkAdapter -ManagementOS

Da

ISM A N A GEM SW ITC H N A M M A C A DDRES IPA DDRESSE

NOME EN TO S VM N A M E E S STAT US S

CORP- True CORP- 001B785768 Problemas

external- external- AA
switch switch

GERENCIAM True VMSTEST E41D2D074 Problemas

ENTO 071

5. Exibir propriedades adicionais da NIC.

Get-NetAdapter

Da

IN T ERFA C EDES
NOME C RIP T IO N IF IN DEX STAT US M A C A DDRESS L IN K SP EED

vEthernet #2 de 28 Up E4-1D-2D-07- 80 Gbps

(gerenciamento adaptador 40-71
) Ethernet virtual
do Hyper-V

Etapa 8. Testar o RDMA do Hyper-V vSwitch

A imagem a seguir mostra o estado atual dos hosts do Hyper-V, incluindo o vSwitch no host do Hyper-V 1.
1. Defina a marcação de prioridade no host vNIC para complementar as configurações de VLAN anteriores.

Set-VMNetworkAdapter -ManagementOS -Name "MGT" -IeeePriorityTag on

Get-VMNetworkAdapter -ManagementOS -Name "MGT" | fl Name,IeeePriorityTag

Da
Nome: IeeePriorityTag de gerenciamento: ativado
2. Crie dois vNICs de host para RDMA e conecte-os ao VMSTEST vSwitch.

Add-VMNetworkAdapter –SwitchName "VMSTEST" –Name SMB1 –ManagementOS

Add-VMNetworkAdapter –SwitchName "VMSTEST" –Name SMB2 –ManagementOS

3. Exiba as propriedades da NIC de gerenciamento.

Get-VMNetworkAdapter -ManagementOS

Da

ISM A N A GEM SW ITC H N A M M A C A DDRES IPA DDRESSE

NOME EN TO S VM N A M E E S STAT US S

CORP- True CORP- 001B785768 Problemas

external- external- AA
switch switch

Gerenciame True VMSTEST E41D2D074 Problemas

nto 071

SMB1 True VMSTEST 00155D30A Problemas

A00

SMB2 True VMSTEST 00155D30A Problemas

A01

Etapa 9. Atribuir um endereço IP ao host SMB vNICs vEthernet ( SMB1

) e vEthernet ( SMB2)
Os adaptadores físicos TEST-40G-1 e TEST-40G-2 ainda têm uma VLAN de acesso de 101 e 102 configurados.
Por isso, os adaptadores marcam o tráfego e o ping são bem-sucedidos. Anteriormente, você configurou as IDs
de VLAN pNIC para zero e, em seguida, definiu o VMSTEST vSwitch para a VLAN 101. Depois disso, você ainda
poderá executar ping no adaptador remoto VLAN 101 usando o vNIC de gerenciamento, mas atualmente não
há nenhum membro de VLAN 102.
1. Remova a configuração de VLAN de acesso da NIC física para impedi-la de marcar automaticamente o
tráfego de saída com a ID de VLAN incorreta e impedir que ela filtre o tráfego de entrada que não
corresponda à ID de VLAN de acesso.

New-NetIPAddress -InterfaceAlias "vEthernet (SMB1)" -IPAddress 192.168.2.111 -PrefixLength 24

Da

IPAddress : 192.168.2.111
InterfaceIndex: 40
InterfaceAlias: vEthernet (SMB1)
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Manual
SuffixOrigin : Manual
AddressState : Invalid
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : PersistentStore

2. Teste o adaptador remoto VLAN 102.

Test-NetConnection 192.168.2.5

Da

ComputerName : 192.168.2.5
RemoteAddress : 192.168.2.5
InterfaceAlias : vEthernet (SMB1)
SourceAddress : 192.168.2.111
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms

3. Adicione um novo endereço IP para a interface vEthernet ( SMB2 ) .

New-NetIPAddress -InterfaceAlias "vEthernet (SMB2)" -IPAddress 192.168.2.222 -PrefixLength 24

Da
 IPAddress : 192.168.2.222
InterfaceIndex: 44
InterfaceAlias: vEthernet (SMB2)
AddressFamily : IPv4
Type : Unicast
PrefixLength : 24
PrefixOrigin : Manual
SuffixOrigin : Manual
AddressState : Invalid
ValidLifetime : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource : False
PolicyStore : PersistentStore

4. Teste a conexão novamente.

5. Coloque o host RDMA vNICs no VLAN 102 já existente.

Set-VMNetworkAdapterVlan -VMNetworkAdapterName "SMB1" -VlanId "102" -Access -ManagementOS

Set-VMNetworkAdapterVlan -VMNetworkAdapterName "SMB2" -VlanId "102" -Access -ManagementOS

Get-VMNetworkAdapterVlan -ManagementOS

Da

VMName VMNetworkAdapterName Mode VlanList

------ -------------------- ---- --------
SMB1 Access 102
Mgt Access 101
SMB2 Access 102
CORP-External-Switch Untagged

6. Inspecione o mapeamento de SMB1 e SMB2 para as NICs físicas subjacentes na equipe do conjunto de
vSwitch.
A associação do host vNIC a NICs físicas é aleatória e está sujeita a rebalanceamento durante a criação e
a destruição. Nessa circunstância, você pode usar um mecanismo indireto para verificar a associação
atual. Os endereços MAC de SMB1 e SMB2 são associados ao membro da equipe NIC TEST-40G-2. Isso
não é ideal porque Test-40G-1 não tem um host SMB vNIC associado e não permitirá a utilização de
tráfego RDMA pelo link até que um host SMB vNIC seja mapeado para ele.

Get-NetAdapterVPort (Preferred)

Get-NetAdapterVmqQueue

Da

Name QueueID MacAddressVlanID Processor VmFriendlyName

---- ------- ---------------- --------- --------------
TEST-40G-1 1 E4-1D-2D-07-40-71 1010:17
TEST-40G-2 1 00-15-5D-30-AA-00 1020:17
TEST-40G-2 2 00-15-5D-30-AA-01 1020:17

7. Exiba as propriedades do adaptador de rede da VM.

Get-VMNetworkAdapter -ManagementOS
 Da

Name IsManagementOs VMName SwitchName MacAddress Status IPAddresses

---- -------------- ------ ---------- ---------- ------ -----------
CORP-External-Switch True CORP-External-Switch 001B785768AA {Ok}
Mgt True VMSTEST E41D2D074071 {Ok}
SMB1 True VMSTEST 00155D30AA00 {Ok}
SMB2 True VMSTEST 00155D30AA01 {Ok}

8. Exiba o mapeamento de equipe do adaptador de rede.

Os resultados não devem retornar informações porque você ainda não executou o mapeamento.

Get-VMNetworkAdapterTeamMapping -ManagementOS -SwitchName VMSTEST -VMNetworkAdapterName SMB1

Get-VMNetworkAdapterTeamMapping -ManagementOS -SwitchName VMSTEST -VMNetworkAdapterName SMB2

9. Mapeie o SMB1 e o SMB2 para separar membros da equipe NIC física e para exibir os resultados de suas
ações.

IMPORTANT
Verifique se você concluiu esta etapa antes de continuar ou se a sua implementação falha.

Set-VMNetworkAdapterTeamMapping -ManagementOS -SwitchName VMSTEST -VMNetworkAdapterName "SMB1" -

PhysicalNetAdapterName "Test-40G-1"
Set-VMNetworkAdapterTeamMapping -ManagementOS -SwitchName VMSTEST -VMNetworkAdapterName "SMB2" -
PhysicalNetAdapterName "Test-40G-2"

Get-VMNetworkAdapterTeamMapping -ManagementOS -SwitchName VMSTEST

Da

NetAdapterName : Test-40G-1
NetAdapterDeviceId : {BAA9A00F-A844-4740-AA93-6BD838F8CFBA}
ParentAdapter : VMInternalNetworkAdapter, Name = 'SMB1'
IsTemplate : False
CimSession : CimSession: .
ComputerName : 27-3145G0803
IsDeleted : False

NetAdapterName : Test-40G-2
NetAdapterDeviceId : {B7AB5BB3-8ACB-444B-8B7E-BC882935EBC8}
ParentAdapter : VMInternalNetworkAdapter, Name = 'SMB2'
IsTemplate : False
CimSession : CimSession: .
ComputerName : 27-3145G0803
IsDeleted : False

10. Confirme as associações MAC criadas anteriormente.

Get-NetAdapterVmqQueue

Da
 Name QueueID MacAddressVlanID Processor VmFriendlyName
---- ------- ---------------- --------- --------------
TEST-40G-1 1 E4-1D-2D-07-40-71 1010:17
TEST-40G-1 2 00-15-5D-30-AA-00 1020:17
TEST-40G-2 1 00-15-5D-30-AA-01 1020:17

11. Teste a conexão do sistema remoto porque o host vNICs reside na mesma sub-rede e tem a mesma ID de
VLAN ( 102 ) .

Test-NetConnection 192.168.2.111

Da

ComputerName : 192.168.2.111
RemoteAddress : 192.168.2.111
InterfaceAlias : Test-40G-2
SourceAddress : 192.168.2.5
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms

Test-NetConnection 192.168.2.222

Da

ComputerName : 192.168.2.222
RemoteAddress : 192.168.2.222
InterfaceAlias : Test-40G-2
SourceAddress : 192.168.2.5
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms

12. Defina o nome, o nome do comutador e as marcas de prioridade.

Set-VMNetworkAdapter -ManagementOS -Name "SMB1" -IeeePriorityTag on

Set-VMNetworkAdapter -ManagementOS -Name "SMB2" -IeeePriorityTag on
Get-VMNetworkAdapter -ManagementOS -Name "SMB*" | fl Name,SwitchName,IeeePriorityTag,Status

Da

Name: SMB1
SwitchName : VMSTEST
IeeePriorityTag : On
Status : {Ok}

Name: SMB2
SwitchName : VMSTEST
IeeePriorityTag : On
Status : {Ok}

13. Exiba as propriedades do adaptador de rede vEthernet.

Get-NetAdapterRdma -Name "vEthernet*" | sort Name | ft -AutoSize

Da
 Name InterfaceDescription Enabled
---- -------------------- -------
vEthernet (SMB2) Hyper-V Virtual Ethernet Adapter #4 False
vEthernet (SMB1) Hyper-V Virtual Ethernet Adapter #3 False
vEthernet (MGT) Hyper-V Virtual Ethernet Adapter #2 False

14. Habilite os adaptadores de rede vEthernet.

Enable-NetAdapterRdma -Name "vEthernet (SMB1)"

Enable-NetAdapterRdma -Name "vEthernet (SMB2)"
Get-NetAdapterRdma -Name "vEthernet*" | sort Name | fl *

Da

Name InterfaceDescription Enabled

---- -------------------- -------
vEthernet (SMB2) Hyper-V Virtual Ethernet Adapter #4 True
vEthernet (SMB1) Hyper-V Virtual Ethernet Adapter #3 True
vEthernet (MGT) Hyper-V Virtual Ethernet Adapter #2 False

Etapa 10. Validar a funcionalidade RDMA

Você deseja validar a funcionalidade RDMA do sistema remoto para o sistema local, que tem um vSwitch, para
ambos os membros da equipe do conjunto de vSwitch.
Como o host vNICs ( SMB1 e o SMB2 ) são atribuídos à VLAN 102, você pode selecionar o adaptador VLAN 102
no sistema remoto.
Neste exemplo, o NIC Test-40G-2 faz o RDMA para o SMB1 (192.168.2.111) e SMB2 (192.168.2.222).

TIP
Talvez seja necessário desabilitar o firewall neste sistema. Consulte sua política de malha para obter detalhes.

Set-NetFirewallProfile -All -Enabled False

Get-NetAdapterAdvancedProperty -Name "Test-40G-2"

Da

Name DisplayNameDisplayValue RegistryKeyword RegistryValue

---- ----------------------- --------------- -------------
.
.
Test-40G-2VLAN ID102VlanID {102}

1. Exiba as propriedades do adaptador de rede.

Get-NetAdapter

Da
 Name InterfaceDescriptionifIndex Status MacAddress LinkSpeed
---- --------------------------- ------ ---------- ---------
Test-40G-2Mellanox ConnectX-3 Pro Ethernet A...#3 3 Up E4-1D-2D-07-43-D140 Gbps

2. Exiba as informações de RDMA do adaptador de rede.

Get-NetAdapterRdma

Da

Name InterfaceDescription Enabled

---- -------------------- -------
Test-40G-2Mellanox ConnectX-3 Pro Ethernet Adap... True

3. Execute o teste de tráfego RDMA no primeiro adaptador físico.

C:\TEST\Test-RDMA.PS1 -IfIndex 3 -IsRoCE $true -RemoteIpAddress 192.168.2.111 -PathToDiskspd

C:\TEST\Diskspd-v2.0.17\amd64fre\

Da

VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\diskspd.exe

VERBOSE: The adapter Test-40G-2 is a physical adapter
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.2.111, is reachable.
VERBOSE: Remote IP 192.168.2.111 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 34251744 RDMA bytes sent per second
VERBOSE: 967346308 RDMA bytes written per second
VERBOSE: 35698177 RDMA bytes sent per second
VERBOSE: 976601842 RDMA bytes written per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior to
sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.2.111

4. Execute o teste de tráfego RDMA no segundo adaptador físico.

C:\TEST\Test-RDMA.PS1 -IfIndex 3 -IsRoCE $true -RemoteIpAddress 192.168.2.222 -PathToDiskspd

C:\TEST\Diskspd-v2.0.17\amd64fre\

Da
 VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\diskspd.exe
VERBOSE: The adapter Test-40G-2 is a physical adapter
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.2.222, is reachable.
VERBOSE: Remote IP 192.168.2.222 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 485137693 RDMA bytes written per second
VERBOSE: 35200268 RDMA bytes sent per second
VERBOSE: 939044611 RDMA bytes written per second
VERBOSE: 34880901 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior to
sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.2.222

5. Teste o tráfego RDMA do local para o computador remoto.

Get-NetAdapter | ft –AutoSize

Da

Name InterfaceDescriptionifIndex Status MacAddress LinkSpeed

---- --------------------------- ------ ---------- ---------
vEthernet (SMB2) Hyper-V Virtual Ethernet Adapter #4 45 Up 00-15-5D-30-AA-0380 Gbps
vEthernet (SMB1) Hyper-V Virtual Ethernet Adapter #3 41 Up 00-15-5D-30-AA-0280 Gbps

6. Execute o teste de tráfego RDMA no primeiro adaptador virtual.

C:\TEST\Test-RDMA.PS1 -IfIndex 41 -IsRoCE $true -RemoteIpAddress 192.168.2.5 -PathToDiskspd

C:\TEST\Diskspd-v2.0.17\amd64fre\

Da
 VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\diskspd.exe
VERBOSE: The adapter vEthernet (SMB1) is a virtual adapter
VERBOSE: Retrieving vSwitch bound to the virtual adapter
VERBOSE: Found vSwitch: VMSTEST
VERBOSE: Found the following physical adapter(s) bound to vSwitch: TEST-40G-1, TEST-40G-2
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.2.5, is reachable.
VERBOSE: Remote IP 192.168.2.5 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 15250197 RDMA bytes sent per second
VERBOSE: 896320913 RDMA bytes written per second
VERBOSE: 33947559 RDMA bytes sent per second
VERBOSE: 912160540 RDMA bytes written per second
VERBOSE: 34091930 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior to
sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.2.5

7. Execute o teste de tráfego RDMA no segundo adaptador virtual.

C:\TEST\Test-RDMA.PS1 -IfIndex 45 -IsRoCE $true -RemoteIpAddress 192.168.2.5 -PathToDiskspd

C:\TEST\Diskspd-v2.0.17\amd64fre\

Da

VERBOSE: Diskspd.exe found at C:\TEST\Diskspd-v2.0.17\amd64fre\diskspd.exe

VERBOSE: The adapter vEthernet (SMB2) is a virtual adapter
VERBOSE: Retrieving vSwitch bound to the virtual adapter
VERBOSE: Found vSwitch: VMSTEST
VERBOSE: Found the following physical adapter(s) bound to vSwitch: TEST-40G-1, TEST-40G-2
VERBOSE: Underlying adapter is RoCE. Checking if QoS/DCB/PFC is configured on each physical
adapter(s)
VERBOSE: QoS/DCB/PFC configuration is correct.
VERBOSE: RDMA configuration is correct.
VERBOSE: Checking if remote IP address, 192.168.2.5, is reachable.
VERBOSE: Remote IP 192.168.2.5 is reachable.
VERBOSE: Disabling RDMA on adapters that are not part of this test. RDMA will be enabled on them
later.
VERBOSE: Testing RDMA traffic now for. Traffic will be sent in a parallel job. Job details:
VERBOSE: 0 RDMA bytes written per second
VERBOSE: 0 RDMA bytes sent per second
VERBOSE: 385169487 RDMA bytes written per second
VERBOSE: 33902277 RDMA bytes sent per second
VERBOSE: 907354685 RDMA bytes written per second
VERBOSE: 33923662 RDMA bytes sent per second
VERBOSE: Enabling RDMA on adapters that are not part of this test. RDMA was disabled on them prior to
sending RDMA traffic.
VERBOSE: RDMA traffic test SUCCESSFUL: RDMA traffic was sent to 192.168.2.5

A linha final nesta saída, "teste de tráfego RDMA com êxito: o tráfego RDMA foi enviado para 192.168.2.5",
mostra que você configurou com êxito a NIC convergida no adaptador.

Tópicos relacionados
Configuração de NIC convergida com um único adaptador de rede
Configuração de comutador físico para NIC convergida
Solucionando problemas de configurações de NIC convergida
 Configuração do com switch físico para NIC
convergida
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Neste tópico, fornecemos diretrizes para configurar seus comutadores físicos.

Esses são apenas comandos e seus usos; você deve determinar as portas às quais as NICs estão conectadas em
seu ambiente.

IMPORTANT
Verifique se a VLAN e a política sem soltar estão definidas para a prioridade sobre a qual o SMB está configurado.

Arista switch ( dcs - 7050s - 64, EOS - 4.13.7M)

1. en ( ir para o modo de administrador, geralmente solicita uma senha)
2. configuração ( para entrar no modo de configuração)
3. show run ( mostra a configuração atual em execução)
4. descubra as portas de opção às quais suas NICs estão conectadas. Neste exemplo, eles são
14/1,15/1,16/1,17/1.
5. int 14/1,15/1,16/1,17/1 entrar no modo de configuração ( para essas portas)
6. ieee do modo dcbx
7. modo priority-flow-control em
8. switchport trunk nativo vlan 225
9. switchport trunk allowed vlan 100-225
10. switchport mode trunk
11. priority-flow-control priority 3 no-drop
12. qos trust cos
13. mostrar execução ( verifique se a configuração está configurada corretamente nas portas)
14. wr ( para fazer com que as configurações persistam entre a reinicialização da opção)
Dicas:
1. Nenhum #command# nega um comando
2. Como adicionar uma nova VLAN: int vlan 100 Se a rede ( de armazenamento estiver na VLAN 100)
3. Como verificar VLANs existentes: mostrar vlan
4. Para obter mais informações sobre como configurar o Arista Switch, pesquise online por: Manual do Arista
EOS
5. Use este comando para verificar as configurações de PFC: mostrar detalhes dos contadores priority-flow-
control

Opção Dell ( S4810, FTOS 9.9 ( 0.0))

 !
dcb enable
! put pfc control on qos class 3
configure
dcb-map dcb-smb
priority group 0 bandwidth 90 pfc on
priority group 1 bandwidth 10 pfc off
priority-pgid 1 1 1 0 1 1 1 1
exit
! apply map to ports 0-31
configure
interface range ten 0/0-31
dcb-map dcb-smb
exit

Cisco switch ( Nexus 3132, versão 6.0 ( 2 ) U6 ( 1))

Global

class-map type qos match-all RDMA

match cos 3
class-map type queuing RDMA
match qos-group 3
policy-map type qos QOS_MARKING
class RDMA
set qos-group 3
class class-default
policy-map type queuing QOS_QUEUEING
class type queuing RDMA
bandwidth percent 50
class type queuing class-default
bandwidth percent 50
class-map type network-qos RDMA
match qos-group 3
policy-map type network-qos QOS_NETWORK
class type network-qos RDMA
mtu 2240
pause no-drop
class type network-qos class-default
mtu 9216
system qos
service-policy type qos input QOS_MARKING
service-policy type queuing output QOS_QUEUEING
service-policy type network-qos QOS_NETWORK

Específico da porta

switchport mode trunk

switchport trunk native vlan 99
switchport trunk allowed vlan 99,2000,2050 çuse VLANs that already exists
spanning-tree port type edge
flowcontrol receive on (not supported with PFC in Cisco NX-OS)
flowcontrol send on (not supported with PFC in Cisco NX-OS)
no shutdown
priority-flow-control mode on

Tópicos relacionados
Configuração de NIC convergida com um único adaptador de rede
Configuração de NIC em NIC convergida
Solução de problemas de configurações de NIC convergida
 Solucionando problemas de configurações de NIC
convergida
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar o script a seguir para verificar se a configuração de RDMA está correta no host Hyper-V.
Baixar Test-Rdma.ps1de script
você também pode usar os seguintes comandos de Windows PowerShell para solucionar problemas e verificar
a configuração de suas NICs convergidas.

Get-NetAdapterRdma
para verificar a configuração de RDMA do adaptador de rede, execute o seguinte comando Windows PowerShell
no servidor Hyper-V.

Get-NetAdapterRdma | fl *

Você pode usar os seguintes resultados esperados e inesperados para identificar e resolver problemas depois
de executar esse comando no host do Hyper-V.
Get-NetAdapterRdma resultados esperados
O host vNIC e a NIC física mostram recursos RDMA diferentes de zero.
Get-NetAdapterRdma resultados inesperados
Execute as etapas a seguir se você receber resultados inesperados ao executar o comando Get-
NetAdapterRdma .
1. Verifique se os drivers de barramento Mlnx e miniporta Mlnx são mais recentes. Para o Mellanox, use
pelo menos a remoção de 42.
2. Verifique se a miniporta Mlnx e os drivers de barramento correspondem verificando a versão do driver
por meio de Gerenciador de Dispositivos. O driver de barramento pode ser encontrado em dispositivos
do sistema. o nome deve começar com Mellanox Conexão-X 3 PRO VPI, conforme ilustrado na seguinte
captura de tela das propriedades do adaptador de rede.
3. Verifique se a RDMA (rede direta) está habilitada na NIC física e no host vNIC.
4. Verifique se o vSwitch foi criado no adaptador físico correto verificando seus recursos de RDMA.
5. Verifique o log do sistema do visualizador e filtre por origem "Hyper-V-VmSwitch".

Get-SmbClientNetworkInterface verifica a configuração RDMA

como uma etapa adicional para verificar a configuração de RDMA, execute o seguinte comando Windows
PowerShell no servidor Hyper-V.

Get-SmbClientNetworkInterface

Get-SmbClientNetworkInterface resultados esperados

O host vNIC também deve aparecer como RDMA habilitado da perspectiva do SMB.

Get-SmbClientNetworkInterface resultados inesperados

1. Verifique se os drivers de barramento Mlnx e miniporta Mlnx são mais recentes. Para o Mellanox, use pelo
menos a remoção de 42.
2. Verifique se a miniporta Mlnx e os drivers de barramento correspondem verificando a versão do driver por
meio de Gerenciador de Dispositivos. O driver de barramento pode ser encontrado em dispositivos do
sistema. o nome deve começar com Mellanox Conexão-X 3 PRO VPI, conforme ilustrado na seguinte captura
de tela das propriedades do adaptador de rede.
3. Verifique se a RDMA (rede direta) está habilitada na NIC física e no host vNIC.
4. Verifique se o comutador virtual do Hyper-V foi criado no adaptador físico correto, verificando seus recursos
de RDMA.
5. Verifique os logs do visualizador para "cliente SMB" em aplicativos e ser viços | Microsoft | Windows .

Get-NetAdapterQos
você pode exibir a qualidade do adaptador de rede da configuração de QoS do serviço ( ) executando o seguinte
comando Windows PowerShell.

Get-NetAdapterQos

Get-NetAdapterQos resultados esperados

As prioridades e as classes de tráfego devem ser exibidas de acordo com a primeira etapa de configuração que
você realizou usando este guia.
Get-NetAdapterQos resultados inesperados
Se os resultados forem inesperados, execute as etapas a seguir.
1. Verifique se o adaptador de rede física dá suporte a ponte de data center ( DCB ) e QoS
2. Verifique se os drivers do adaptador de rede estão atualizados.

Get-SmbMultiChannelConnection
você pode usar o comando Windows PowerShell a seguir para verificar se o endereço IP do nó remoto é -
compatível com RDMA.

Get-SmbMultiChannelConnection

Get-SmbMultiChannelConnection resultados esperados

O endereço IP do nó remoto é mostrado como habilitado para RDMA.

Get-SmbMultiChannelConnection resultados inesperados

Se os resultados forem inesperados, execute as etapas a seguir.
1. Verifique se o ping funciona de ambas as maneiras.
2. Verifique se o firewall não está bloqueando o início da conexão SMB. Especificamente, habilite a regra de
firewall para a porta SMB Direct 5445 para iWARP e 445 para ROCE.

Get-SmbClientNetworkInterface verifica se a NIC é compatível com

RMDA
Você pode usar o comando a seguir para verificar se a NIC virtual que você habilitou para RDMA é relatada
como compatível com RDMA - pelo SMB.

Get-SmbClientNetworkInterface

Get-SmbClientNetworkInterface resultados esperados

A NIC virtual habilitada para RDMA deve ser vista como compatível com RDMA pelo SMB.
Get-SmbClientNetworkInterface resultados inesperados
Se os resultados forem inesperados, execute as etapas a seguir.
1. Verifique se o ping funciona de ambas as maneiras.
2. Verifique se o firewall não está bloqueando o início da conexão SMB.

específico do VSTA. ( Mellanox)

Se você estiver usando adaptadores de rede Mellanox, poderá usar o comando vstat para verificar a versão de
roce Ethernet RDMA ( ) em convergente nos nós do Hyper-V.
resultados esperados do VSTA
A versão do RoCE em ambos os nós deve ser a mesma. Essa também é uma boa maneira de verificar se a
versão do firmware em ambos os nós é a mais recente.

resultados inesperados do VSTA

Se os resultados forem inesperados, execute as etapas a seguir.
1. Definir a versão correta do RoCE usando o Set-MlnxDriverCoreSetting
2. Instale o firmware mais recente do site da Mellanox.

Contadores Perfmon
Você pode examinar os contadores no monitor de desempenho para verificar a atividade RDMA de sua
configuração.
Tópicos relacionados
Configuração de NIC convergida com um único adaptador de rede
Configuração NIC agrupada NIC convergida
Configuração de comutador físico para NIC convergida
 DCB (Data Center Bridging)
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para obter informações introdutórios sobre Data Center Bridging ( DCB ) .
O DCB é um conjunto de padrões IEEE do Institute of Electrical and Electronics Engineers que habilitam malhas
convergida no data center, em que armazenamento, rede de dados, IPC de comunicação entre processos de
cluster e tráfego de gerenciamento compartilham a mesma infraestrutura de rede ( ) - ( ) Ethernet.

NOTE
Além deste tópico, a documentação do DCB a seguir está disponível
Instalar o DCB Windows Server 2016 ou Windows 10
Gerenciar Data Center Bridging (DCB)

O DCB fornece alocação de largura de banda baseada em hardware para um tipo específico de tráfego de rede e
aprimora a confiabilidade do transporte Ethernet com o uso do controle de fluxo - - baseado em prioridade.
A alocação de largura de banda baseada em hardware é essencial se o tráfego ignora o sistema operacional e é
descarregado para um adaptador de rede convergido, que pode dar suporte ao iSCSI da Interface do Sistema de
Computador Pequeno da Internet, RDMA de Acesso Remoto Direto à Memória via Ethernet ou - Fiber Channel
sobre Ethernet ( ) ( ) ( FCoE ) .
O controle de fluxo baseado em prioridade será essencial se o protocolo de camada superior, como Fiber
Channel, assumir um transporte subjacente - sem perda.

Protocolos DCB e opções de gerenciamento

O DCB consiste no seguinte conjunto de protocolos.
ETS do Serviço de Transmissão Aprimorado ( ) – IEEE 802.1Qaz, que se baseia nos padrões 802.1P e 802.1Q
Priority Flow Control ( PFC ) , IEEE 802.1Qbb
DCB Exchange Protocolo ( DCBX ) , IEEE 802.1AB, conforme estendido no padrão 802.1Qaz.
O protocolo DCBX permite que você configure o DCB em uma opção, que pode configurar automaticamente um
dispositivo final, como um computador executando Windows Server 2016.
Se você preferir gerenciar o DCB de uma opção, não será necessário instalar o DCB como um recurso no
Windows Server 2016, no entanto, essa abordagem inclui algumas limitações.
Como o DCBX só pode informar o adaptador de rede host de tamanhos de classe ETS e a habilitação de PFC, no
entanto, os hosts do servidor Windows geralmente exigem que o DCB seja instalado para que o tráfego seja
mapeado para classes ETS.
Windows aplicativos geralmente não são projetados para participar de trocas DCBX. Por isso, o host deve ser
configurado separadamente dos comutadores de rede, mas com configurações idênticas.
Se você optar por gerenciar o DCB de uma opção, ainda poderá exibir as configurações no Windows Server
2016 usando Windows PowerShell comandos.
Funcionalidade de DCB importante
A lista a seguir resume a funcionalidade fornecida pelo DCB.
1. Fornece interoperabilidade entre adaptadores de rede com capacidade para DCB - e comutadores - com
capacidade para DCB.
2. Fornece um transporte Ethernet sem perda entre um computador que executa Windows Server 2016 e
sua opção de vizinho, a ligar o controle de fluxo baseado - em prioridade no adaptador de rede.
3. Fornece a capacidade de alocar largura de banda a um TC de Controle de Tráfego por percentual, em que
o TC pode consistir em uma ou mais classes de tráfego que são diferenciadas por indicadores de
prioridade de classe de tráfego ( ) 802.1p. ( )
4. Permite que os administradores do servidor ou administradores de rede atribuam um aplicativo a uma
determinada classe de tráfego ou prioridade com base em protocolos bem conhecidos, porta TCP/UDP
bem conhecida ou porta NetworkDirect usada por esse aplicativo.
5. Fornece gerenciamento de DCB por meio Windows Server 2016 Windows WMI de Instrumentação de
Gerenciamento ( ) e Windows PowerShell. Para obter mais informações, consulte a seção Windows
PowerShell comandos para DCB mais adiante neste tópico, além dos tópicos a seguir.
Componentes DCB fornecidos pelo sistema
Requisitos de QoS NDIS para Data Center Bridging
6. Fornece gerenciamento de DCB por meio Windows Server 2016 Política de Grupo.
7. Dá suporte à coexistência de Windows Server 2016 de ( QoS de Qualidade de ) Serviço.

NOTE
Antes de usar qualquer versão RDMA sobre Ethernet RoCE convergida ( ) do RDMA, você deve habilitar o DCB. Embora
não seja necessário para redes iWARP de Protocolo RDMA de Área Larga da Internet, o teste determinou que todas as
tecnologias RDMA baseadas em Ethernet funcionam melhor ( ) com o - DCB. Por isso, você deve considerar o uso de DCB
para implantações de RDMA iWARP. Para obter mais informações, consulte Remote Direct Memory Access (RDMA) e
Switch Embedded Teaming (SET).

Aplicativos práticos do DCB

Muitas organizações têm instalações SAN de rede de área de armazenamento do Fiber Channel ( FC grandes
para o serviço de ) ( ) armazenamento. A SAN em FC exige adaptadores de rede especiais em servidores e
comutadores FC na rede. Essas organizações normalmente também usam adaptadores de rede Ethernet e
comutadores.
Na maioria dos casos, o hardware FC é significativamente mais caro de implantar do que o hardware Ethernet, o
que resulta em grandes despesas de capital. Além disso, o requisito para adaptadores de rede ETHERNET e FC
SAN separados e hardware de comutamento requer capacidade adicional de espaço, energia e resfriamento em
um datacenter, o que resulta em despesas operacionais adicionais e contínuas.
De uma perspectiva de custo, é vantajoso para muitas organizações mesclar sua tecnologia FC com sua solução
de hardware baseada em Ethernet para fornecer serviços de rede de dados e - armazenamento.
Usando dCB para uma malha convergida baseada em Ethernet - para armazenamento e rede de dados
Para organizações que já têm uma SAN fc grande, mas que querem migrar para fora do investimento adicional
na tecnologia FC, o DCB permite que você crie uma malha convergida baseada em Ethernet para
armazenamento e rede de dados. Uma malha convergida de DCB pode reduzir o custo total futuro de TCO de
propriedade ( ) e simplificar o gerenciamento.
Para os hosters que já adotaram ou que planejam adotar o iSCSI como sua solução de armazenamento, o DCB
pode fornecer reserva de largura de banda assistida por hardware para o tráfego iSCSI para garantir o
isolamento de - desempenho. E, ao contrário de outras soluções proprietárias, a DCB é baseada em padrões e,
portanto, relativamente fácil de implantar e gerenciar - em um ambiente de rede heterogêneo.
Uma Windows Server 2016 implementação baseada em DCB alivia muitos dos problemas que podem ocorrer
quando soluções de malha convergida são fornecidas por vários fabricantes originais de - ( equipamentos
OEMs ) .
Implementações de soluções proprietárias fornecidas por vários OEMs podem não interoperar entre si, podem
ser difíceis de gerenciar e normalmente terão diferentes agendamentos de manutenção de software.
Por outro lado, Windows Server 2016 DCB é baseada em padrões e você pode implantar e - gerenciar o DCB
em uma rede heterogênea.

Windows PowerShell Comandos para DCB

Há comandos de Windows PowerShell DCB para Windows Server 2016 e Windows Server 2012 R2. Você pode
usar todos os comandos para Windows Server 2012 R2 em Windows Server 2016.
Windows Server 2016 Windows PowerShell comandos para DCB
O tópico a seguir para Windows Server 2016 fornece Windows PowerShell descrições de cmdlet e sintaxe para
todos os ( ) ( ) cmdlets específicos Data Center Bridging DCB Quality of Service - QoS. Ela lista os cmdlets em
ordem alfabética com base no verbo no início do cmdlet.
Módulo DcbQoS
Windows Server 2012 Comandos de Windows PowerShell R2 para DCB
O tópico Windows Server 2012 R2 fornece Windows PowerShell descrições de cmdlet e sintaxe para todos os ( )
( ) cmdlets específicos Data Center Bridging DCB Quality of Service - QoS. Ela lista os cmdlets em ordem
alfabética com base no verbo no início do cmdlet.
Cmdlets de Qualidade de Serviço (QoS) de Ponte de Datacenter no Windows PowerShell
 instalar o data Center Bridging ( DCB ) em
Windows Server 2016 ou Windows 10
12/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para aprender a instalar o DCB no Windows Server 2016 ou Windows 10.

Pré-requisitos para usar o DCB

A seguir, os pré-requisitos para configurar e gerenciar o DCB.
Instalar um sistema operacional compatível
Você pode usar os comandos DCB deste guia nos sistemas operacionais a seguir.
Windows Server (Canal semestral)
Windows Server 2016
Windows 10 ( todas as versões)
os seguintes sistemas operacionais incluem versões anteriores do DCB que não são compatíveis com os
comandos que são usados na documentação do DCB para Windows Server 2016 e Windows 10.
Windows Server 2012 R2
Windows Server 2012
Requisitos de hardware
A seguir está uma lista de requisitos de hardware para o DCB.
-os s adaptadores de rede Ethernet compatíveis com DCB ( ) devem ser instalados em computadores que
estão fornecendo Windows Server 2016 DCB.
-Os comutadores de hardware compatíveis com DCB devem ser implantados em sua rede.

Instalar o DCB no Windows Server 2016

Você pode usar as seções a seguir para instalar o DCB em um computador que executa o Windows Server 2016.
Credenciais administrativas
Para executar esses procedimentos, você deve ser membro de Administradores .
Instalar o DCB usando o Windows PowerShell
Você pode usar o procedimento a seguir para instalar o DCB usando Windows PowerShell.
1. em um computador que executa o Windows Server 2016, clique em iniciar e clique com o botão direito do
mouse no ícone de Windows PowerShell. Um menu é exibido. No menu, clique em mais e, em seguida,
clique em Executar como administrador . Se solicitado, digite as credenciais para uma conta que tenha
privilégios de administrador no computador. Windows PowerShell é aberto com privilégios de administrador.
2. Digite o comando a seguir e pressione ENTER.

Install-WindowsFeature -Name Data-Center-Bridging -IncludeManagementTools

Instalar o DCB usando o Gerenciador do Servidor
Você pode usar o procedimento a seguir para instalar o DCB usando Gerenciador do Servidor.

NOTE
Depois de executar a primeira etapa neste procedimento, a página antes de começar do assistente para adicionar
funções e recursos não será exibida se você tiver selecionado anteriormente ignorar esta página por padrão quando
o assistente para adicionar funções e recursos for executado. Se a página antes de começar não for exibida, pule da
etapa 1 para a etapa 3.

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 .
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 ser vidor de destino , verifique se Selecionar um ser vidor no pool de ser vidores está
marcada. Em Pool de Ser vidores , verifique se o computador local está selecionado. Clique em Próximo .
5. Em Selecionar funções de ser vidor , clique em Avançar .
6. Em selecionar recursos , em recursos , clique em ponte de data center . Uma caixa de diálogo é aberta
para perguntar se você deseja adicionar os recursos necessários do DCB. Clique em Adicionar Recursos .
7. Em selecionar recursos , clique em Avançar .
8. 7.In 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. Depois que a mensagem for exibida informando que a instalação foi
bem-sucedida, clique em fechar .
Configurar o depurador de kernel para permitir o QoS ( opcional)
Por padrão, os depuradores de kernel bloqueiam NetQos. Independentemente do método usado para instalar o
DCB, se você tiver um depurador de kernel instalado no computador, deverá configurar o depurador para
permitir que o QoS seja habilitado e configurado executando o comando a seguir.

Set-ItemProperty HKLM:"\SYSTEM\CurrentControlSet\Services\NDIS\Parameters" AllowFlowControlUnderDebugger -

type DWORD -Value 1 -Force

Instalar o DCB no Windows 10

você pode executar o procedimento a seguir em um computador Windows 10.
Para executar esse procedimento, você deve ser membro de Administradores .
Instalar DCB
1. clique em iniciar , role para baixo e clique em Windows sistema .
2. Clique em Painel de Controle . A caixa de diálogo painel de controle é aberta.
3. No painel de controle , clique em Exibir por e, em seguida, clique em ícones grandes ou ícones
pequenos .
4. Clique em Programas e Recursos . A caixa de diálogo programas e recursos é aberta.
5. em programas e recursos , no painel esquerdo, clique em Windows ativar ou desativar recursos . a
caixa de diálogo Windows recursos é aberta.
6. em Windows recursos , clique em ponte do data Center e, em seguida, clique em OK .
 Gerenciar a ponte do Data Center (DCB)
13/08/2021 • 11 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

este tópico fornece instruções sobre como usar comandos de Windows PowerShell para configurar a ponte do
data Center ( DCB ) em um - adaptador de rede compatível com DCB que está instalado em um computador que
está executando o Windows Server 2016 ou Windows 10.

instalar o DCB em Windows Server 2016 ou Windows 10

para obter informações sobre os pré-requisitos para usar e como instalar o DCB, consulte instalar a ponte do
data Center (DCB) em Windows Server 2016 ou Windows 10.

Configurações do DCB
antes da Windows Server 2016, todas as configurações de DCB foram aplicadas universalmente a todos os
adaptadores de rede que suportavam DCB.
no Windows Server 2016, você pode aplicar configurações de DCB ao repositório de política Global ou ao
repositório de política individual ( s ) . Quando as políticas individuais são aplicadas, elas substituem todas as
configurações de política global.
As configurações de classe de tráfego, PFC e atribuição de prioridade de aplicativo no nível do sistema não são
aplicadas em adaptadores de rede até que você faça o seguinte.
1. Transforme o bit de DCBX disposto em false
2. Habilite o DCB nos adaptadores de rede. consulte habilitar e exibir DCB Configurações em adaptadores
de rede.

NOTE
Se você quiser configurar o DCB de um comutador por meio de DCBX, consulte configurações de DCBX.

O bit DCBX disposto é descrito na especificação DCB. Se o bit disposto em um dispositivo for definido como
true, o dispositivo estará disposto a aceitar configurações de um dispositivo remoto por meio do DCBX. Se o bit
disposto em um dispositivo for definido como false, o dispositivo rejeitará todas as tentativas de configuração
de dispositivos remotos e impedirá apenas as configurações locais.
se DCB não estiver instalado em Windows Server 2016 o valor do bit disposto é irrelevante no que diz respeito
ao sistema operacional, pois o sistema operacional não tem configurações locais aplicáveis a adaptadores de
rede. Após a instalação do DCB, o valor padrão do bit disposto é true. Esse design permite que os adaptadores
de rede mantenham quaisquer configurações que possam ter recebido de seus colegas remotos.
Se um adaptador de rede não oferecer suporte a DCBX, ele nunca receberá configurações de um dispositivo
remoto. Ele recebe configurações do sistema operacional, mas somente depois que o bit DCBX disposto é
definido como false.

Definir o bit disposto

Para impor as configurações do sistema operacional de classe de tráfego, PFC e atribuição de prioridade de
aplicativo em adaptadores de rede, ou simplesmente substituir as configurações de dispositivos remotos \ — se
houver algum, você pode executar o comando a seguir.

NOTE
DCB Windows PowerShell nomes de comando incluem "QoS" em vez de "DCB" na cadeia de caracteres de nome. isso
ocorre porque o QoS e o DCB são integrados no Windows Server 2016 para fornecer uma experiência de gerenciamento
de QoS direta.

Set-NetQosDcbxSetting -Willing $FALSE

Confirm
Are you sure you want to perform this action?
Set-NetQosDcbxSetting -Willing $false
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):

Para exibir o estado da configuração de bit dedisposta, você pode usar o seguinte comando:

Get-NetQosDcbxSetting

Willing PolicySetIfIndex IfAlias

------- ---------------- -------
False Global

Configuração do DCB em adaptadores de rede

Habilitar o DCB em um adaptador de rede permite que você veja a configuração propagada de um comutador
para o adaptador de rede.
As configurações do DCB incluem as etapas a seguir.
1. Defina as configurações de DCB no nível do sistema, que inclui:
a. Gerenciamento de classe de tráfego
b. Configurações de controle de prioridade Flow (PFC)
c. Atribuição de prioridade de aplicativo
d. Configurações de DCBX
2. Configure o DCB no adaptador de rede.

Gerenciamento de classe de tráfego DCB

veja a seguir um exemplo Windows PowerShell comandos para o gerenciamento de classe de tráfego.
Criar uma classe de tráfego
Você pode usar o comando New-NetQosTrafficClass para criar uma classe de tráfego.

New-NetQosTrafficClass -Name SMB -Priority 4 -BandwidthPercentage 30 -Algorithm ETS

Name Algorithm Bandwidth(%) Priority PolicySetIfIndex IfAlias

---- --------- ------------ -------- ---------------- -------
SMB ETS 30 4Global
Por padrão, todos os valores 802.1 p são mapeados para uma classe de tráfego padrão, que tem 100% da
largura de banda do link físico. O comando New-NetQosTrafficClass cria uma nova classe de tráfego, para a
qual qualquer pacote marcado com o valor 4 de prioridade 802.1 p é mapeado. O algoritmo de seleção de
transmissão ( TSA ) é ETs e tem 30% da largura de banda.
Você pode criar até sete novas classes de tráfego. Incluindo a classe de tráfego padrão, pode haver no máximo
oito classes de tráfego no sistema. No entanto, um adaptador de rede compatível com DCB pode não oferecer
suporte a muitas classes de tráfego no hardware. Se você criar mais classes de tráfego do que o pode ser
acomodado em um adaptador de rede e habilitar o DCB nesse adaptador de rede, o driver de miniporta relatará
um erro ao sistema operacional. O erro é registrado no log de eventos.
A soma das reservas de largura de banda para todas as classes de tráfego criadas não pode exceder 99% da
largura de banda. A classe de tráfego padrão sempre tem pelo menos 1% da largura de banda reservada para si
mesma.
Exibir classes de tráfego
Você pode usar o comando Get-NetQosTrafficClass para exibir classes de tráfego.

Get-NetQosTrafficClass

NameAlgorithm Bandwidth(%) Priority PolicySetIfIndex IfAlias

------------- ------------ -------- ---------------- -------
[Default] ETS 70 0-3,5-7 Global
SMB ETS 30 4Global

Modificar uma classe de tráfego

Você pode usar o comando set-NetQosTrafficClass para criar uma classe de tráfego.

Set-NetQosTrafficClass -Name SMB -BandwidthPercentage 50

Em seguida, você pode usar o comando Get-NetQosTrafficClass para exibir as configurações.

Get-NetQosTrafficClass

NameAlgorithm Bandwidth(%) Priority PolicySetIfIndex IfAlias

------------- ------------ -------- ---------------- -------
[Default] ETS 50 0-3,5-7 Global
SMB ETS 50 4Global

Depois de criar uma classe de tráfego, você pode alterar suas configurações de forma independente. As
configurações que podem ser alteradas incluem:
1. Alocação de largura de banda (-BandwidthPercentage)
2. TSA (-Algorithm)
3. Mapeamento de prioridade (-Priority)
Remover uma classe de tráfego
Você pode usar o comando Remove-NetQosTrafficClass para excluir uma classe de tráfego.

IMPORTANT
Não é possível remover a classe de tráfego padrão.
 Remove-NetQosTrafficClass -Name SMB

You can then use the **Get-NetQosTrafficClass** command to view settings.

Get-NetQosTrafficClass

NameAlgorithm Bandwidth(%) Priority PolicySetIfIndex IfAlias

------------- ------------ -------- ---------------- -------
[Default] ETS 100 0-7 Global

Depois de remover uma classe de tráfego, o valor de 802.1 p mapeado para essa classe de tráfego é remapeado
para a classe de tráfego padrão. Qualquer largura de banda reservada para uma classe de tráfego é retornada
para a alocação de classe de tráfego padrão quando a classe de tráfego é removida.

Políticas de interface de Per-Network

Todos os exemplos acima definem as políticas globais. Veja a seguir exemplos de como você pode definir e
obter políticas por NIC.
O campo "Policyset" muda de global para AdapterSpecific. Quando as políticas AdapterSpecific são mostradas, o
índice de interface ( ifIndex ) e o nome de interface ( ifAlias ) também são exibidos.
 PS C:\> Get-NetQosTrafficClass

Name Algorithm Bandwidth(%) Priority PolicySet IfIndex IfAlias

---- --------- ------------ -------- --------- ------- -------
[Default] ETS 100 0-7 Global

PS C:\> Get-NetQosTrafficClass -InterfaceAlias M1

Name Algorithm Bandwidth(%) Priority PolicySet IfIndex IfAlias

---- --------- ------------ -------- --------- ------- -------
[Default] ETS 100 0-7 AdapterSpecific 4 M1

PS C:\> New-NetQosTrafficClass -Name SMBGlobal -BandwidthPercentage 30 -Priority 4 -Algorithm ETS

Name Algorithm Bandwidth(%) Priority PolicySet IfIndex IfAlias

---- --------- ------------ -------- --------- ------- -------
SMBGlobal ETS 30 4 Global

PS C:\> New-NetQosTrafficClass -Name SMBforM1 -BandwidthPercentage 30 -Priority 4 -Algorithm ETS -Interfac

Name Algorithm Bandwidth(%) Priority PolicySet IfIndex IfAlias

---- --------- ------------ -------- --------- ------- -------
SMBforM1 ETS 30 4 AdapterSpecific 4 M1

PS C:\> Get-NetQosTrafficClass

Name Algorithm Bandwidth(%) Priority PolicySet IfIndex IfAlias

---- --------- ------------ -------- --------- ------- -------
[Default] ETS 70 0-3,5-7 Global
SMBGlobal ETS 30 4 Global

PS C:\> Get-NetQosTrafficClass -InterfaceAlias M1

Name Algorithm Bandwidth(%) Priority PolicySet IfIndex IfAlias

---- --------- ------------ -------- --------- ------- -------
[Default] ETS 70 0-3,5-7 AdapterSpecific 4 M1
SMBforM1 ETS 30 4 AdapterSpecific 4 M1

configurações de controle de prioridade Flow:

a seguir estão exemplos de comando para prioridade Flow configurações de controle. Essas configurações
também podem ser especificadas para adaptadores individuais.
habilitar e exibir o controle de Flow de prioridade para casos de uso globais e específicos da Interface
 PS C:\> Enable-NetQosFlowControl -Priority 4
PS C:\> Enable-NetQosFlowControl -Priority 3 -InterfaceAlias M1
PS C:\> Get-NetQosFlowControl

Priority Enabled PolicySet IfIndex IfAlias

-------- ------- --------- ------- -------
0 False Global
1 False Global
2 False Global
3 False Global
4 True Global
5 False Global
6 False Global
7 False Global

PS C:\> Get-NetQosFlowControl -InterfaceAlias M1

Priority Enabled PolicySet IfIndex IfAlias

-------- ------- --------- ------- -------
0 False AdapterSpecific 4 M1
1 False AdapterSpecific 4 M1
2 False AdapterSpecific 4 M1
3 True AdapterSpecific 4 M1
4 False AdapterSpecific 4 M1
5 False AdapterSpecific 4 M1
6 False AdapterSpecific 4 M1
7 False AdapterSpecific 4 M1

desabilitar o controle de Flow de prioridade (Global e específico da Interface )

PS C:\> Disable-NetQosFlowControl -Priority 4

PS C:\> Disable-NetQosFlowControl -Priority 3 -InterfaceAlias m1
PS C:\> Get-NetQosFlowControl

Priority Enabled PolicySet IfIndex IfAlias

-------- ------- --------- ------- -------
0 False Global
1 False Global
2 False Global
3 False Global
4 False Global
5 False Global
6 False Global
7 False Global

PS C:\> Get-NetQosFlowControl -InterfaceAlias M1

Priority Enabled PolicySet IfIndex IfAlias

-------- ------- --------- ------- -------
0 False AdapterSpecific 4 M1
1 False AdapterSpecific 4 M1
2 False AdapterSpecific 4 M1
3 False AdapterSpecific 4 M1
4 False AdapterSpecific 4 M1
5 False AdapterSpecific 4 M1
6 False AdapterSpecific 4 M1
7 False AdapterSpecific 4 M1

Atribuição de prioridade de aplicativo

Veja a seguir exemplos de atribuição de prioridade.
Criar política de QoS
 PS C:\> New-NetQosPolicy -Name "SMB Policy" -SMB -PriorityValue8021Action 4

Name : SMB Policy

Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
Template : SMB
PriorityValue : 4

O comando anterior cria uma nova política para SMB. – O SMB é um filtro de caixa de entrada que corresponde
à porta TCP 445 (reservada para SMB). Se um pacote for enviado para a porta TCP 445, ele será marcado pelo
sistema operacional com o valor de 4 do 802.1 p antes que o pacote seja passado para um driver de miniporta
de rede.
Além de – SMB, outros filtros padrão incluem – iSCSI (correspondência da porta TCP 3260),-NFS
(correspondência da porta TCP 2049),-LiveMigration (correspondência da porta TCP 6600),-FCOE (Matching
EtherType 0x8906) e – NetworkDirect.
NetworkDirect é uma camada abstrata que criamos sobre qualquer implementação de RDMA em um adaptador
de rede. – NetworkDirect deve ser seguido por uma porta direta da rede.
Além dos filtros padrão, você pode classificar o tráfego pelo nome do executável do aplicativo (como no
primeiro exemplo abaixo) ou por endereço IP, porta ou protocolo (como mostrado no segundo exemplo):
Por nome do executável

PS C:\> New-NetQosPolicy -Name background -AppPathNameMatchCondition "C:\Program files (x86)\backup.exe" -

PriorityValue8021Action 1

Name : background
Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
AppPathName : C:\Program files (x86)\backup.exe
JobObject :
PriorityValue : 1

Por por ta de endereço IP ou protocolo

PS C:\> New-NetQosPolicy -Name "Network Management" -IPDstPrefixMatchCondition 10.240.1.0/24 -

IPProtocolMatchCondition both -NetworkProfile all -PriorityValue8021Action 7

Name : Network Management

Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
JobObject :
IPProtocol : Both
IPDstPrefix : 10.240.1.0/24
PriorityValue : 7

Exibir política de QoS

 PS C:\> Get-NetQosPolicy

Name : background
Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
AppPathName : C:\Program files (x86)\backup.exe
JobObject :
PriorityValue : 1

Name : Network Management

Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
JobObject :
IPProtocol : Both
IPDstPrefix : 10.240.1.0/24
PriorityValue : 7

Name : SMB Policy

Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
Template : SMB
JobObject :
PriorityValue : 4

Modificar política de QoS

Você pode modificar as políticas de QoS, conforme mostrado abaixo.

PS C:\> Set-NetQosPolicy -Name "Network Management" -IPSrcPrefixMatchCondition 10.235.2.0/24 -

IPProtocolMatchCondition both -PriorityValue8021Action 7
PS C:\> Get-NetQosPolicy

Name : Network Management

Owner : Group Policy (Machine)
NetworkProfile : All
Precedence : 127
JobObject :
IPProtocol : Both
IPSrcPrefix : 10.235.2.0/24
IPDstPrefix : 10.240.1.0/24
PriorityValue : 7

Remover política de QoS

PS C:\> Remove-NetQosPolicy -Name "Network Management"

Confirm
Are you sure you want to perform this action?
Remove-NetQosPolicy -Name "Network Management" -Store GPO:localhost
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y

Configuração do DCB em adaptadores de rede

A configuração do DCB em adaptadores de rede é independente da configuração do DCB no nível do sistema
descrito acima.
independentemente de o DCB estar instalado no Windows Server 2016, você sempre poderá executar os
comandos a seguir.
Se você configurar o DCB de um comutador e confiar no DCBX para propagar as configurações para
adaptadores de rede, poderá examinar quais configurações são recebidas e impostas nos adaptadores de rede
do lado do sistema operacional depois de habilitar o DCB nos adaptadores de rede.
habilitar e exibir Configurações DCB em adaptadores de rede

PS C:\> Enable-NetAdapterQos M1
PS C:\> Get-NetAdapterQos

Name : M1
Enabled : True
Capabilities : Hardware Current
-------- -------
MacSecBypass : NotSupported NotSupported
DcbxSupport : None None
NumTCs(Max/ETS/PFC) : 8/8/8 8/8/8

OperationalTrafficClasses : TC TSA Bandwidth Priorities

-- --- --------- ----------
0 ETS 70% 0-3,5-7
1 ETS 30% 4

OperationalFlowControl : All Priorities Disabled

OperationalClassifications : Protocol Port/Type Priority
-------- --------- --------
Default 1

Desabilitar DCB em adaptadores de rede

PS C:\> Disable-NetAdapterQos M1
PS C:\> Get-NetAdapterQos M1

Name : M1
Enabled : False
Capabilities : Hardware Current
-------- -------
MacSecBypass : NotSupported NotSupported
DcbxSupport : None None
NumTCs(Max/ETS/PFC) : 8/8/8 0/0/0

Windows PowerShell Comandos para DCB

há comandos DCB Windows PowerShell para Windows Server 2016 e Windows Server 2012 R2. você pode
usar todos os comandos para Windows Server 2012 R2 no Windows Server 2016.
Windows Server 2016 Windows PowerShell comandos para DCB
o tópico a seguir para Windows Server 2016 fornece descrições de cmdlet Windows PowerShell e sintaxe para
toda a ponte de data Center ( DCB a ) qualidade dos ( ) - cmdlets específicos de QoS de serviço. Ela lista os
cmdlets em ordem alfabética com base no verbo no início do cmdlet.
Módulo DcbQoS
Windows Server 2012 comandos R2 Windows PowerShell para DCB
o tópico a seguir para Windows Server 2012 R2 fornece Windows PowerShell descrições e sintaxe de cmdlets
para toda a ponte de data Center ( DCB a ) qualidade dos ( ) - cmdlets específicos de QoS de serviço. Ela lista os
cmdlets em ordem alfabética com base no verbo no início do cmdlet.
Cmdlets de Qualidade de Serviço (QoS) de Ponte de Datacenter no Windows PowerShell
 VRSS de dimensionamento do lado do (
recebimento virtual)
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Neste tópico, você aprenderá sobre o VRSS (Virtual Receive Side Scaling) e como configurar um adaptador de
rede virtual para balancear a carga do tráfego de rede de entrada em vários núcleos de processador lógico em
uma VM. Você também pode usar o vRSS para configurar vários núcleos físicos para uma vNIC da placa de
interface de rede virtual ( do ) host.
Essa configuração permite que a carga de um adaptador de rede virtual seja distribuída entre vários
processadores virtuais em uma VM de máquina virtual, permitindo que a VM processe mais tráfego de rede
mais rapidamente do que pode com um único processador ( ) lógico.

TIP
Você pode usar o vRSS em VMs em hosts hyper-V que têm vários processadores, um único processador de vários núcleos
ou mais de um vários processadores principais instalados e configurados para uso - de VM.

O vRSS é compatível com todas as outras - tecnologias de rede do Hyper-V. O vRSS depende Fila de Máquina
Virtual VMQ no host Hyper V e RSS na VM ou na ( ) - vNIC do host.
Por padrão, Windows Server habilita o vRSS, mas você pode desabilitá-lo em uma VM usando Windows
PowerShell. Para obter mais informações, consulte Gerenciar comandos vRSS e Windows PowerShell para RSS e
vRSS.

Compatibilidade do sistema operacional

Você pode usar o RSS em qualquer computador multiprocessador ou multicore – ou vRSS em qualquer VM
multiprocessador ou multicore – que está executando Windows Server 2016.
VMs multiprocessador ou multicore que estão executando os seguintes sistemas operacionais da Microsoft
também são suportadas por vRSS.
Windows Server 2016
Windows 10 Pro ou Enterprise
Windows Server 2012 R2
Windows 8.1 Pro ou Enterprise
Windows Server 2012 com os componentes de integração Windows Server 2012 R2 instalados.
Windows 8 com os componentes de integração Windows Server 2012 R2 instalados.
Para obter informações sobre o suporte a vRSS para VMs que executam FreeBSD ou Linux como um sistema
operacional convidado no Hyper-V, consulte Máquinas virtuais Linux e FreeBSD com suporte para Hyper-Vno
Windows .

Requisitos de hardware
A seguir estão os requisitos de hardware para vRSS.
 Os adaptadores de rede física devem dar suporte Fila de Máquina Virtual ( VMQ ) . Se a VMQ estiver
desabilitada ou não tiver suporte, o vRSS será desabilitado para o host Hyper V e todas as - VMs
configuradas no host.
Os adaptadores de rede devem ter uma velocidade de link de 10 Gbps ou mais.
Os - hosts hyper-V devem ser configurados com vários processadores ou pelo menos um processador de
vários - núcleos para usar o vRSS.
As ( VMs de máquinas ) virtuais devem ser configuradas para usar dois ou mais processadores lógicos.

Cenários de caso de uso

Os dois cenários de caso de uso a seguir descrevem o uso comum do vRSS para balanceamento de carga do
processador e balanceamento de carga de software.
Balanceamento de carga do processador
Anthony, um administrador de rede, está configurando um novo host Hyper-V com dois adaptadores de rede
que são compatíveis com o IOV de SR de virtualização de Input-Output raiz ( - ) única. Ele implanta o Windows
Server 2016 para hospedar um servidor de arquivos de VM.
Depois de instalar o hardware e o software, Anthony configura uma VM para usar oito processadores virtuais e
4096 MB de memória. Infelizmente, Anthony não tem a opção de ligar a SR IOV porque suas VMs dependem da
imposição de política por meio do comu switch virtual que ele criou com o Gerenciador de Comudores Virtuais
do - - Hyper-V. Por isso, Anthony decide usar vRSS em vez de SR - IOV.
Inicialmente, Anthony atribui quatro processadores virtuais usando Windows PowerShell estar disponível para
uso com o vRSS. O uso do servidor de arquivos após uma semana parece ser bastante popular, portanto,
Anthony verifica o desempenho da VM. Ele descobre a utilização completa dos quatro processadores virtuais.
Por isso, Anthony decide adicionar processadores à VM para uso pelo vRSS. Ele atribui mais dois processadores
virtuais à VM, que estão automaticamente disponíveis para o vRSS para ajudar a lidar com a carga de rede
grande. Seus esforços resultam em um melhor desempenho para o servidor de arquivos de VM, com os seis
processadores manipulando com eficiência a carga de tráfego de rede.
Balanceamento de carga do software
Ela, uma administradora de rede, está configurando uma única VM de alto desempenho em um de seus
sistemas para atuar como um balanceador de carga de software. Ela atribuiu todos os processadores lógicos
disponíveis a essa única VM.
Depois de instalar Windows Server, ela usa o vRSS para obter processamento de tráfego de rede paralelo em
vários processadores lógicos na VM. Como Windows Server habilita o vRSS, Ela não precisa fazer nenhuma
alteração de configuração.

Tópicos relacionados
Planejar o uso do vRSS
Habilitar o vRSS em um adaptador de rede virtual
Gerenciar vRSS
Perguntas frequentes sobre vRSS
Windows PowerShell Comandos para RSS e vRSS
 Planejar o uso do vRSS
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

No Windows Server 2016, o vRSS está habilitado por padrão, no entanto, você deve preparar seu ambiente
para permitir que o vRSS funcione corretamente em uma VM de máquina virtual ou em um adaptador virtual
host ( ) ( vNIC ) . No Windows Server 2012 R2, o vRSS foi desabilitado por padrão.
Ao planejar e preparar o uso do vRSS, verifique se:
O adaptador de rede física é compatível com Fila de Máquina Virtual VMQ e tem uma velocidade ( ) de link
de 10 Gbps ou mais.
A VMQ está habilitada na NIC física e na porta do Com switch virtual do Hyper - V
Não há nenhuma SR IOV de - virtualização de saída de entrada de raiz ( - única ) configurada para a VM.
O Teaming da NIC está configurado corretamente.
A VM tem vários ( LPs de processadores ) lógicos.

NOTE
O vRSS também é habilitado por padrão para quaisquer vNICs de host que têm o RSS habilitado.

A seguir estão informações adicionais que você precisa para concluir essas etapas de preparação.
1. Capacidade do adaptador de rede. Verifique se o adaptador de rede é compatível com Fila de
Máquina Virtual VMQ e tem uma velocidade ( ) de link de 10 Gbps ou mais. Se a velocidade do link for
menor que 10 Gbps, o Comutadores Virtuais do Hyper-V desabilitará a VMQ por padrão, mesmo que ele
ainda mostre a VMQ como habilitada nos resultados do comando - Windows PowerShell Get-
NetAdapterVmq . Um método que você pode usar para verificar se a VMQ está habilitada ou
desabilitada é usar o comando Get-NetAdapterVmqQueue . Se a VMQ estiver desabilitada, os
resultados desse comando mostrarão que não há QueueID atribuído à VM ou adaptador de rede virtual
do host.
2. Habilitar VMQ . Verifique se a VMQ está ativada no computador host. O vRSS não funcionará se o host
não tiver suporte para VMQ. Você pode verificar se a VMQ está habilitada executando Get-VMSwitch e
encontrando o adaptador que o com switch virtual está usando. Em seguida, execute Get-
NetAdapterVmq e assegure-se de que o adaptador é exibido nos resultados e que possui a VMQ
habilitada.
3. Ausência de SR - IOV . Verifique se um driver VF de VF de Função Virtual de Sr IOV de Virtualização de
Saída de Entrada Única não está anexado ao interface de - rede da ( - ) ( ) VM. Você pode verificar isso
usando o comando Get-NetAdapterSriov. Se um driver VF for carregado, o RSS usará as
configurações de dimensionamento desse driver em vez das configuradas pelo vRSS. Se o driver VF não
for suportado pelo RSS, o vRSS será desabilitado.
4. Configuração de NIC Teaming . Se você estiver usando o NIC Teaming, é importante que você
configure corretamente a VMQ para trabalhar com as configurações de NIC Teaming. Para obter
informações detalhadas sobre a implantação e o gerenciamento do NIC Teaming, consulte NIC Teaming.
5. Número de LPs . Verifique se a VM tem mais de um LP de processador ( ) lógico. O vRSS depende do
 RSS na VM ou no host Hyper-V para balancear a carga do tráfego recebido para vários LPs para
processamento paralelo. Você pode observar quantos LPs sua VM tem executando o comando Windows
PowerShell Get-VMProcessor no host. Depois de executar o comando, você pode observar a entrada
da coluna Contagem para o número de LPs.
A vNIC do host sempre tem acesso a todos os processadores físicos; para configurar a vNIC do host para usar
um número específico de processadores, use as configurações -BaseProcessorNumber e -MaxProcessors
ao executar o comando Set-NetAdapterRss Windows PowerShell.
 Habilitar o vRSS em um adaptador de rede virtual
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

O ( VRSS virtual RSS ) requer Fila de Máquina Virtual suporte à ( VMQ ) do adaptador físico. Se a VMQ estiver
desabilitada ou não tiver suporte, o dimensionamento virtual do lado do recebimento será desabilitado.
Para obter mais informações, consulte Planejar o uso do vRSS.

Habilitar o vRSS em uma VM

Use os procedimentos a seguir para habilitar o vRSS usando Windows PowerShell ou Gerenciador de
Dispositivos.
Gerenciador de Dispositivos
Windows PowerShell
Gerenciador de Dispositivos
Você pode usar esse procedimento para habilitar o vRSS usando Gerenciador de Dispositivos.

NOTE
A primeira etapa neste procedimento é específica para VMs que estão executando Windows 10 ou Windows Server 2016.
Se sua VM estiver executando um sistema operacional diferente, você poderá abrir o Gerenciador de Dispositivos primeiro
abrindo o Painel de Controle, em seguida, localizando e abrindo Gerenciador de Dispositivos.

1. Na barra de tarefas da VM, em Digite aqui para pesquisar , digite dispositivo .

2. Nos resultados da pesquisa, clique em Gerenciador de Dispositivos .
3. No Gerenciador de Dispositivos, clique para expandir adaptadores de rede .
4. Clique com o botão direito do mouse no adaptador de rede que você deseja configurar e clique em
Propriedades .
A caixa de diálogo Propriedades do adaptador de rede é aberta.
5. Em Propriedades do adaptador de rede, clique na guia Avançado.
6. Em Propriedade , role para baixo até e clique em Dimensionamento do lado do recebimento.
7. Verifique se a seleção em Valor está Habilitada.
8. Clique em OK .

NOTE
Na guia Avançado, alguns adaptadores de rede também exibem o número de filas RSS com suporte pelo adaptador.

Windows PowerShell
Use o procedimento a seguir para habilitar o vRSS usando Windows PowerShell.
1. Na máquina virtual, abra Windows PowerShell .
2. Digite o comando a seguir, garantindo que você substitua o valor AdapterName para o parâmetro -
Name pelo nome do adaptador de rede que você deseja configurar e pressione ENTER.

Enable-NetAdapterRSS -Name "AdapterName"

TIP
Como alternativa, você pode usar o comando a seguir para habilitar o vRSS.

Set-NetAdapterRSS -Name "AdapterName" -Enabled $True

Para obter mais informações, consulte Windows PowerShell comandos para RSS e vRSS.
 Gerenciar vRSS
12/08/2021 • 2 minutes to read

neste tópico, você usa os comandos de Windows PowerShell para gerenciar o vRSS em VMs de máquinas
virtuais ( ) e em - hosts Hyper V.

NOTE
para obter mais informações sobre os comandos mencionados neste tópico, consulte Windows PowerShell comandos
para RSS e vRSS.

VMQ em hosts Hyper-V

No host Hyper-V, você deve usar as palavras-chave que controlam os processadores de VMQ.
Exibir as configurações atuais:

Get-NetAdapterVmq

Defina as configurações de VMQ:

Set-NetAdapterVmq

vRSS em portas de comutador Hyper-V

No host Hyper-V, você também deve habilitar o vRSS na porta do - comutador virtual Hyper-v.
Exibir as configurações atuais:

Get-VMNetworkAdapter <vm-name> | fl

Get-VMNetworkAdapter -ManagementOS | fl

As duas configurações a seguir devem ser verdadeiras .

VrssEnabledRequested: true
VrssEnabled: true

IMPORTANT
Em algumas condições de limitação de recursos, uma - porta de comutador virtual Hyper-V pode não ser capaz de
habilitar esse recurso. Essa é uma condição temporária e o recurso pode estar disponível em um momento subsequente.
Se VrssEnabled for true , o recurso será habilitado para essa porta do - comutador virtual do Hyper-V, ou seja, para essa
VM ou vNIC.

Defina as configurações de vRSS da por ta do comutador :

 Set-VMNetworkAdapter <vm-name> -VrssEnabled $TRUE

Set-VMNetworkAdapter -ManagementOS -VrssEnabled $TRUE

vRSS em VMs e host vNICs

Você pode usar os mesmos comandos usados para RSS nativo para definir configurações de vRSS em VMs e
host vNICs, que também é a maneira de habilitar o RSS no host vNICs.
Exibir as configurações atuais:

Get-NetAdapterRSS

Definir configurações de vRSS:

Set-NetAdapterRss

NOTE
Definir o perfil dentro da VM não afeta o agendamento do trabalho. O Hyper - V faz todas as decisões de agendamento e
ignora o perfil dentro da VM.

Desabilitar vRSS
Você pode desabilitar o vRSS para desabilitar qualquer uma das configurações mencionadas anteriormente.
Desabilite a VMQ para a NIC física ou para a VM.
Cau t i on

Desabilitar a VMQ na NIC física afeta seriamente a capacidade de seu host Hyper- - V de lidar com os
pacotes de entrada.
Desabilite o vRSS para uma VM na - porta do comutador virtual Hyper-v no host Hyper- - v.

Set-VMNetworkAdapter <vm-name> -VrssEnabled $FALSE

Desabilite o vRSS para um host vNIC na - porta do comutador virtual Hyper-v no host Hyper- - v.

Set-VMNetworkAdapter -ManagementOS -VrssEnabled $FALSE

Desabilitar RSS na VM ( ou no host vNIC ) dentro da VM ( ou no host)

Disable-NetAdapterRSS *
 Windows PowerShell Comandos para RSS e vRSS
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

neste tópico, você aprenderá a localizar rapidamente informações de referência técnica sobre Windows
PowerShell comandos para receber o rss de escala lateral e o rss ( ) virtual ( vRSS ) .
Use os comandos RSS a seguir para configurar o RSS em um computador físico com vários processadores ou
vários núcleos. Você pode usar os mesmos comandos para configurar o vRSS em uma VM de máquina virtual (
) que esteja executando um sistema operacional com suporte. Para obter mais informações, consulte cmdlets do
adaptador de rede em Windows PowerShell.

Configurar a VMQ
o vRSS requer que a VMQ esteja habilitada e configurada. você pode usar os seguintes comandos de Windows
PowerShell para gerenciar as configurações de VMQ.
Desabilitar-NetAdapterVmq
Habilitar-NetAdapterVmq
Get-NetAdapterVmq
Set-NetAdapterVmq

Habilitar e configurar o RSS em um host nativo

Use os comandos do PowerShell a seguir para configurar o RSS em um host nativo, bem como gerenciar o RSS
em uma VM ou em uma NIC virtual do host (vNIC). Alguns dos parâmetros desses comandos também podem
afetar Fila de Máquina Virtual ( VMQ ) no host Hyper-V.

IMPORTANT
Habilitar o RSS em uma VM ou em um host vNIC é um pré-requisito para habilitar e usar o vRSS.

Desabilitar-NetAdapterRss
Habilitar-NetAdapterRss
Get-NetAdapterRss
Set-NetAdapterRss

Habilitar o vRSS na - porta do comutador virtual Hyper-V

Além de habilitar o RSS na VM, o vRSS exige que você habilite o vRSS na - porta do comutador virtual Hyper-V.
Determine as configurações atuais para vRSS e habilite ou desabilite o recurso para uma VM.
Exibir as configurações atuais:

Get-VMNetworkAdapter <vm-name> | fl

Habilitado o recurso:
 Set-VMNetworkAdapter <vm-name> -VrssEnabled [$True|$False]

Habilitar ou desabilitar o vRSS em um host vNIC

Determine as configurações atuais para vRSS e habilite ou desabilite o recurso para um host vNIC.
Exibir as configurações atuais:

Get-VMNetworkAdapter -ManagementOS | fl

Habilitar ou desabilitar o recurso:

Set-VMNetworkAdapter -ManagementOS -VrssEnabled [$True|$False]

Configurar o modo de agendamento na porta do comutador virtual

do Hyper-V
aplica-se a: Windows server 2022, Windows server 2019

no Windows Server 2019, o vRSS pode atualizar os processadores lógicos usados para processar o tráfego de
rede dinamicamente. Os dispositivos com drivers com suporte têm esse modo de agendamento habilitado por
padrão.
Determine o modo de agendamento atual em um sistema ou modifique o modo de agendamento de uma VM.
Exibir as configurações atuais:

Get-VMNetworkAdapter <vm-name> | Select 'VRSSQueue'

Definir ou modificar o modo de agendamento:

Set-VMNetworkAdapter <vm-name> -VrssQueueSchedulingMode [Dynamic|$StaticVrss|StaticVMQ]

Configurar o modo de agendamento em um host vNIC

aplica-se a: Windows server 2022, Windows server 2019

para determinar o modo de agendamento atual ou para modificar o modo de agendamento de um host vNIC,
use os seguintes comandos de Windows PowerShell:
Exibir as configurações atuais:

Get-VMNetworkAdapter -ManagementOS | Select 'VRSSQueue'

Definir ou modificar o modo de agendamento:

Set-VMNetworkAdapter -ManagementOS -VrssQueueSchedulingMode -VrssQueueSchedulingMode

[Dynamic|$StaticVrss|StaticVMQ]
Tópicos relacionados
Para obter mais informações, consulte os tópicos de referência a seguir.
Get-VMNetworkAdapter
Set-VMNetworkAdapter
Para obter mais informações, consulte vRSS (recepção virtual).
 Resolver problemas de vRSS
13/08/2021 • 2 minutes to read

Se você tiver concluído todas as etapas de preparação e ainda não vir o tráfego de balanceamento de carga
vRSS para a VM LPs, haverá possíveis problemas diferentes.
1. Antes de executar as etapas de preparação, o vRSS foi desabilitado-e agora deve ser habilitado. Você
pode executar set-VMNetworkAdapter para habilitar o vRSS para a VM.

Set-VMNetworkAdapter <VMname> -VrssEnabled $TRUE

Set-VMNetworkAdapter -ManagementOS -VrssEnabled $TRUE

2. O RSS foi desabilitado na VM ou no host vNIC. o Windows Server 2016 habilita RSS por padrão; Alguém
pode tê-lo desabilitado.
Habilitado = verdadeiro
Exibir as configurações atuais:
Execute o seguinte cmdlet do PowerShell na VM ( para vrss em uma VM ) ou no host ( para o vrss vNIC
do host ) .

Get-NetAdapterRss

Habilite o recurso:
Para alterar o valor de false para true, execute o seguinte cmdlet do PowerShell.

Enable-NetAdapterRss *

Outra maneira em todo o sistema de configurar o RSS é usar o netsh. Use

netsh int tcp show global

para garantir que o RSS não seja desabilitado globalmente. E habilitá-lo se necessário. Essa configuração
não é coberta por *-NetAdapterRSS.
3. Se você achar que o VMMQ não está habilitado depois de configurar o vRSS, verifique as seguintes
configurações em cada adaptador anexado ao comutador virtual:
VmmqEnabled = false
VmmqEnabledRequested = true
 Exibir as configurações atuais:

Get-NetAdapterAdvancedProperty -Name NICName -DisplayName 'Virtual Switch RSS'

Habilite o recurso:

Set-NetAdapterAdvancedProperty -Name NICName -DisplayName 'Virtual Switch RSS' -DisplayValue Enabled”

4. (Windows Server 2019) Não é possível habilitar VMMQ (VmmqEnabled = false) ao definir
VrssQueueSchedulingMode como dinâmico . O VrssQueueSchedulingMode não é alterado para
dinâmico quando VMMQ está habilitado.
O VrssQueueSchedulingMode de dinâmico requer suporte de driver quando o VMMQ está
habilitado. VMMQ é um descarregamento do posicionamento de pacotes em processadores lógicos e,
como tal, requer suporte de driver para aproveitar o algoritmo dinâmico. Instale o driver e o firmware do
fornecedor da NIC que dá suporte a VMMQ dinâmicos.
 API de serviço HCN (rede de computação de host)
para VMs e contêineres
13/08/2021 • 6 minutes to read

aplica-se a: Windows server 2022, Windows server 2019

A API de serviço HCN (rede de computação de host) é uma API Win32 voltada para o público que fornece
acesso em nível de plataforma para gerenciar redes virtuais, pontos de extremidade de rede virtual 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 HCN funciona em Ponte de Desktop (também conhecido como Centennial) aplicativos em execução
nos serviços do sistema. A API verifica a ACL recuperando o token do usuário do chamador.

TIP
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;
};

TIP
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",
 "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 nível superior IPAM & objeto de sub-rede.
exemplo de código Go gerado para o nível superior IPAM & objeto de sub-rede. 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 HCN. Arquivo schemas. Mars
Conforme mencionado acima, você pode encontrar o esquema do documento para documentos usados pelas
APIs HCN em um conjunto de arquivos. Mars em: onecore/VM/DV/net/HNS/Schema/Mars/esquema
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
11/08/2021 • 10 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019

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 NICS Virtuais a Máquinas Virtuais ou
Contêineres.

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))
{
// UnMarshal the result Json
THROW_HR(result);
}
}

Excluir um HCN
Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para Abrir & Excluir uma
Rede de Computação de Host

wil::unique_cotaskmem_string errorRecord;
GUID networkGuid; // Initialize it to appropriate network guid value
HRESULT hr = HcnDeleteNetwork(networkGuid, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Enumerar todas as redes

Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para enumerar todas as
redes de computação do host.
 wil::unique_cotaskmem_string resultNetworks;
wil::unique_cotaskmem_string errorRecord;
// Filter to select Networks based on properties
std::wstring filter [] = LR"(
{
"Name" : "WDAG",
})";
HRESULT result = HcnEnumerateNetworks(filter.c_str(), &resultNetworks, &errorRecord);
if (FAILED(result))
{
// UnMarshal the result Json
THROW_HR(result);
}

Consultar propriedades de rede

Este exemplo mostra como usar a API de Serviço de Rede de Computação do Host para consultar propriedades
de rede.

unique_hcn_network hcnnetwork;
wil::unique_cotaskmem_string errorRecord;
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))
{
// UnMarshal the result Json
THROW_HR(hr);
}
hr = HcnQueryNetworkProperties(hcnnetwork.get(), query.c_str(), &properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Cenário: ponto de extremidade HCN

Criar um ponto de extremidade HCN
Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para 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.
 using unique_hcn_endpoint = wil::unique_any<
HCN_ENDPOINT,
decltype(&HcnCloseEndpoint),
HcnCloseEndpoint>;
void CreateAndHotAddEndpoint()
{
unique_hcn_endpoint hcnendpoint;
unique_hcn_network hcnnetwork;
wil::unique_cotaskmem_string errorRecord;
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
settings.c_str(), // Compute system settings document
&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))
{
// UnMarshal the result Json
THROW_HR(result);
}
}

Excluir um ponto de extremidade

Este exemplo mostra como usar a API de Serviço de Rede de Computação do Host para excluir um ponto de
extremidade de rede de computação de host.
 wil::unique_cotaskmem_string errorRecord;
GUID endpointGuid; // Initialize it to appropriate endpoint guid value
HRESULT hr = HcnDeleteEndpoint(endpointGuid, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Modificar e ponto de extremidade

Este exemplo mostra como usar a API de Serviço de Rede de Computação do Host para modificar um ponto de
extremidade de rede de computação de host.

unique_hcn_endpoint hcnendpoint;
GUID endpointGuid; // Initialize it to appropriate endpoint guid value
HRESULT hr = HcnOpenEndpoint(endpointGuid, &hcnendpoint, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
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))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Enumerar todos os pontos

Este exemplo mostra como usar a API de Serviço de Rede de Computação do Host para enumerar todos os
pontos de extremidade de rede de computação do host.

wil::unique_cotaskmem_string errorRecord;
wil::unique_cotaskmem_string resultEndpoints;
wil::unique_cotaskmem_string errorRecord;
// Filter to select Endpoint based on properties
std::wstring filter [] = LR"(
{
"Name" : "sampleNetwork",
})";
result = HcnEnumerateEndpoints(filter.c_str(), &resultEndpoints, &errorRecord);
if (FAILED(result))
{
THROW_HR(result);
}

Consultar propriedades do ponto de extremidade

Este exemplo mostra como usar a API de Serviço de Rede de Computação do Host para consultar todas as
propriedades de um ponto de extremidade de rede de computação do host.
 unique_hcn_endpoint hcnendpoint;
wil::unique_cotaskmem_string errorRecord;
GUID endpointGuid; // Initialize it to appropriate endpoint guid value
HRESULT hr = HcnOpenEndpoint(endpointGuid, &hcnendpoint, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string properties;
std:wstring query = LR"(
{
// Future
})";
hr = HcnQueryEndpointProperties(hcnendpoint.get(), query.c_str(), &properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the errorRecord Json
THROW_HR(hr);
}

Cenário: namespace hcn

Criar um namespace hcn
Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para criar um Namespace de
Rede de Computação de Host no host que pode ser usado para conectar o ponto de extremidade e contêineres.
 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;
wil::unique_cotaskmem_string errorRecord;
std::wstring settings = LR"(
{
"SchemaVersion": {
"Major": 2,
"Minor": 0
},
"Owner" : "Sample",
"Flags" : 0,
"Type" : 0,
})";
GUID namespaceGuid;
HRESULT result = CoCreateGuid(&namespaceGuid);
result = HcnCreateNamespace(
namespaceGuid, // Unique ID
settings.c_str(), // Compute system settings document
&handle,
&errorRecord
);
if (FAILED(result))
{
// UnMarshal the result Json
// ErrorSchema
// {
// "ErrorCode" : <uint32>,
// "Error" : <string>,
// "Success" : <bool>,
// }
// Failed to create network
THROW_HR(result);
}
result = HcnCloseNamespace(handle.get());
if (FAILED(result))
{
// UnMarshal the result Json
THROW_HR(result);
}
}

Excluir um namespace hcn

Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para excluir um Namespace
de Rede de Computação do Host.

wil::unique_cotaskmem_string errorRecord;
GUID namespaceGuid; // Initialize it to appropriate namespace guid value
HRESULT hr = HcnDeleteNamespace(namespaceGuid, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Modificar um namespace hcn

Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para modificar um
Namespace de Rede de Computação do Host.
 unique_hcn_namespace handle;
GUID namespaceGuid; // Initialize it to appropriate namespace guid value
HRESULT hr = HcnOpenNamespace(namespaceGuid, &handle, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string errorRecord;
static std::wstring ModifySettingAddEndpointJson = LR"(
{
"ResourceType" : 1,
"ResourceType" : 0,
"Settings" : {
"EndpointId" : "87fdcf16-d210-426e-959d-2a1d4f41d6d1"
}
}
)";
hr = HcnModifyNamespace(handle.get(), ModifySettingAddEndpointJson.c_str(), &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
hr = HcnCloseNamespace(handle.get());
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Enumerar todos os namespaces

Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para enumerar todos os
Namespaces de Rede de Computação do Host.

wil::unique_cotaskmem_string resultNamespaces;
wil::unique_cotaskmem_string errorRecord;
std::wstring filter [] = LR"(
{
// Future
})";
HRESULT hr = HcnEnumerateNamespace(filter.c_str(), &resultNamespaces, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Propriedades do namespace de consulta

Este exemplo mostra como usar a API de Serviço de Rede de Computação do Host para consultar as
propriedades do namespace de rede de computação do host
 unique_hcn_namespace handle;
GUID namespaceGuid; // Initialize it to appropriate namespace guid value
HRESULT hr = HcnOpenNamespace(namespaceGuid, &handle, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string errorRecord;
wil::unique_cotaskmem_string properties;
std:wstring query = LR"(
{
// Future
})";
HRESULT hr = HcnQueryNamespaceProperties(handle.get(), query.c_str(), &properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Cenário: balanceador de carga HCN

Criar um balanceador de carga HCN
Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para criar uma rede de
computação de host Load Balancer no host que pode ser usada para balancear a carga do ponto de extremidade
em toda a computação.
 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;
wil::unique_cotaskmem_string errorRecord;
std::wstring settings = LR"(
{
"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))
{
// UnMarshal the result Json
// ErrorSchema
// {
// "ErrorCode" : <uint32>,
// "Error" : <string>,
// "Success" : <bool>,
// }
// Failed to create network
THROW_HR(hr);
}
hr = HcnCloseLoadBalancer(handle.get());
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
}

Excluir um balanceador de carga HCN

Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para excluir um
LoadBalancer de Rede de Computação do Host.
 wil::unique_cotaskmem_string errorRecord;
GUID lbGuid; // Initialize it to appropriate loadbalancer guid value
HRESULT hr = HcnDeleteLoadBalancer(lbGuid , &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Modificar um balanceador de carga HCN

Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para modificar um
Namespace de Rede de Computação do Host.

unique_hcn_loadbalancer handle;
GUID lbGuid; // Initialize it to appropriate loadbalancer guid value
HRESULT hr = HcnOpenLoadBalancer(lbGuid, &handle, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string errorRecord;
static std::wstring ModifySettingAddEndpointJson = LR"(
{
"ResourceType" : 1,
"ResourceType" : 0,
"Settings" : {
"EndpointId" : "87fdcf16-d210-426e-959d-2a1d4f41d6d1"
}
}
)";
hr = HcnModifyLoadBalancer(handle.get(), ModifySettingAddEndpointJson.c_str(), &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
hr = HcnCloseLoadBalancer(handle.get());
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Enumerar todos os balanceadores de carga

Este exemplo mostra como usar a API do Serviço de Rede de Computação do Host para enumerar todos os
recursos de Rede de Computação do Host Load Balancer.

wil::unique_cotaskmem_string resultLoadBalancers;
wil::unique_cotaskmem_string errorRecord;
std::wstring filter [] = LR"(
{
// Future
})";
HRESULT result = HcnEnumerateLoadBalancers(filter.c_str(), & resultLoadbalancers, &errorRecord);
if (FAILED(result))
{
// UnMarshal the result Json
THROW_HR(result);
}
Consultar propriedades do balanceador de carga
Este exemplo mostra como usar a API de Serviço de Rede de Computação do Host para consultar as
propriedades do LoadBalancer de Rede de Computação do Host.

unique_hcn_loadbalancer handle;
GUID lbGuid; // Initialize it to appropriate loadbalancer guid value
HRESULT hr = HcnOpenLoadBalancer(lbGuid, &handle, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}
wil::unique_cotaskmem_string errorRecord;
wil::unique_cotaskmem_string properties;
std:wstring query = LR"(
{
"ID" : "",
"Type" : 0,
})";
hr = HcnQueryNProperties(handle.get(), query.c_str(), &properties, &errorRecord);
if (FAILED(hr))
{
// UnMarshal the result Json
THROW_HR(hr);
}

Cenário: notificações de HCN

Registrar e não registrar notificações em todo o serviço
Este exemplo demonstra como usar a API do Serviço de Rede de Computação do Host para registrar e não
registrar 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 ocorrer uma operação em todo o
serviço, como um novo evento de criação de rede.
 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 os alças de contexto RPC para HCN.
Saiba mais sobre os esquemas de documento JSON do HCN.
 Identificadores de contexto de RPC para HCN
11/08/2021 • 12 minutes to read

aplica-se a: Windows server 2022, Windows server 2019

HCN_Network
Uma rede HCN é uma entidade que é usada para representar uma rede de computação de host e seus recursos
e políticas de sistema associados. Por exemplo, uma rede HCN normalmente consistirá em um conjunto de
metadados (por exemplo, ID, nome, tipo), um comutador virtual, um adaptador de rede virtual do host (que atua
como um gateway padrão para a rede), uma instância de NAT (se exigido pelo tipo de rede), um conjunto de
pools de sub-rede e de MAC e qualquer política de toda a rede a ser aplicada (
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 with extended result
/// information. The caller must release the buffer using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCreateNetwork(
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_NETWORK Network,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Opens a handle to an existing Network.
///
/// \param Id Unique ID of the existing Network.
/// \retval Network Receives a handle to the Network.
/// \retval ErrorRecord Optional, receives a JSON document on failure with extended result
/// \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
HcnOpenNetwork(
_In_ REFGUID Id,
_Out_ PHCN_NETWORK Network,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Modify the settings of a Network
///
/// \param Network Handle to a Network.
/// \param Settings JSON document specifying the new settings of the Network.
/// \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
HcnModifyNetwork(
_In_ HCN_NETWORK Network,
_In_ PCWSTR Settings,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Query Network properties
///
/// \param Network Handle to a Network.
/// \param Query Optionally specifies a JSON document for a query
/// containing specific properties of the Network
/// return. By default all properties are returned.
/// \retval Properties Receives a JSON document with Network properties.
/// \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
HcnQueryNetworkProperties(
_In_ HCN_NETWORK Network,
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Delete a Network
///
/// \param Id Unique ID of the existing Network.
/// \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
HcnDeleteNetwork(
_In_ REFGUID Id,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Close a handle to a Network
///
/// \param Network Handle to a Network.
///
 ///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCloseNetwork(
_In_ HCN_NETWORK Network
);

HCN_Endpoint
Um ponto de extremidade HCN é uma entidade que é usada para representar um ponto de extremidade de IP
em uma rede HCN e seus recursos e políticas de sistema associados. Por exemplo, um ponto de extremidade
HCN geralmente consiste em um conjunto de metadados (por exemplo, ID, nome, ID de rede pai), sua
identidade de rede (por exemplo, endereço IP, endereço MAC) e quaisquer políticas específicas de ponto de
extremidade a serem aplicadas (por exemplo, ACLs, rotas). As entidades de ponto de extremidade HCN são
representadas usando HCN_ENDPOINT identificadores de contexto RPC.

/// Handle to an operation

DECLARE_HANDLE(HCN_ENDPOINT);
/// Return a list of existing Endpoints
///
/// \param Query Optionally specifies a JSON document for a query
/// 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.
/// \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
HcnEnumerateEndpoints(
_In_ PCWSTR Query,
_Outptr_ PWSTR* Endpoints,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// 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.
/// \param Settings JSON document specifying the settings of the new Endpoint.
/// \retval Endpoint Receives a handle to the new Endpoint.
/// \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
HcnCreateEndpoint(
_In_ HCN_NETWORK Network,
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_ENDPOINT Endpoint,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Opens a handle to an existing Endpoint.
///
/// \param Id Unique ID of the existing Endpoint.
/// \retval Endpoint Receives a handle to the Endpoint.
/// \retval ErrorRecord Optional, receives a JSON document on failure with extended result
/// \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
HcnOpenEndpoint(
_In_ REFGUID Id,
_Out_ PHCN_ENDPOINT Endpoint,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Modify the settings of an Endpoint
///
/// \param Endpoint Handle to an Endpoint.
/// \param Settings JSON document specifying the new settings of the Endpoint.
/// \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
HcnModifyEndpoint(
_In_ HCN_ENDPOINT Endpoint,
_In_ PCWSTR Settings,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Query Endpoint properties
///
/// \param Endpoint Handle to an Endpoint.
/// \param Query Optionally specifies a JSON document for a query
/// containing specific properties of the Endpoint
/// return. By default all properties are returned.
/// \retval Properties Receives a JSON document with Endpoint properties.
/// \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
HcnQueryEndpointProperties(
_In_ HCN_ENDPOINT Endpoint,
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Delete an Endpoint
///
/// \param Id Unique ID of the existing Endpoint.
/// \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
HcnDeleteEndpoint(
_In_ REFGUID Id,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Close a handle to an Endpoint
///
/// \param Endpoint Handle to an Endpoint.
///
 ///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCloseEndpoint(
_In_ HCN_ENDPOINT Endpoint
);

HCN_Namespace
Um namespace HCN é uma entidade que é usada para representar um namespace de rede de computação do
host. Os namespaces permitem que você tenha ambientes de rede isolados em um único host, em que cada
namespace tem suas próprias interfaces de rede e tabela de roteamento, separados de outros namespaces.
As entidades de namespace HCN são representadas usando HCN_NAMESPACE identificadores de contexto RPC.

/// Handle to an operation

DECLARE_HANDLE(HCN_NAMESPACE);
/// Return a list of existing Namespaces
///
/// \param Query Optionally specifies a JSON document for a query
/// 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.
/// \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
HcnEnumerateNamespaces(
_In_ PCWSTR Query,
_Outptr_ PWSTR* Namespaces,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Create a Namespace
///
/// \param Id Specifies the unique ID for the new Namespace.
/// \param Settings JSON document specifying the settings of the new Namespace.
/// \retval Namespace Receives a handle to the new Namespace.
/// \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
HcnCreateNamespace(
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_NAMESPACE Namespace,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Opens a handle to an existing Namespace.
///
/// \param Id Unique ID of the existing Namespace.
/// \retval Namespace Receives a handle to the Namespace.
/// \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
HcnOpenNamespace(
_In_ REFGUID Id,
_Out_ PHCN_NAMESPACE Namespace,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Modify the settings of a Namespace
///
/// \param Namespace Handle to a Namespace.
/// \param Settings JSON document specifying the new settings of the Namespace.
/// \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
HcnModifyNamespace(
_In_ HCN_NAMESPACE Namespace,
_In_ PCWSTR Settings,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Query Namespace properties
///
/// \param Namespace Handle to a Namespace.
/// \param Query Optionally specifies a JSON document for a query
/// containing specific properties of the Namespace
/// return. By default all properties are returned.
/// \retval Properties Receives a JSON document with Namespace properties.
/// \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
HcnQueryNamespaceProperties(
_In_ HCN_NAMESPACE Namespace,
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Delete a Namespace
///
/// \param Id Unique ID of the existing Namespace.
/// \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
HcnDeleteNamespace(
_In_ REFGUID Id,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Close a handle to a Namespace
///
/// \param Namespace Handle to a Namespace.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
 WINAPI
HcnCloseNamespace(
_In_ HCN_NAMESPACE Namespace
);

HCN_LoadBalancer
Um HCN Balancer é uma entidade que é usada para representar uma rede de computação do host balanceador
de carga. Os Load balancers permitem que você tenha pontos de extremidade de rede de computação de host
com balanceamento de carga. As entidades do balanceador HCN são representadas usando
HCN_LOADBALANCER identificadores de contexto RPC.

/// Handle to an operation

DECLARE_HANDLE(HCN_LOADBALANCER);
//////
/// LoadBalancer Methods
/// Return a list of existing LoadBalancers
///
/// \param Query Optionally specifies a JSON document for a query
/// containing properties of the specific LoadBalancers to
/// return. By default all LoadBalancers are returned.
/// \retval LoadBalancers Receives a JSON document with the list of LoadBalancers.
/// \retval ErrorRecord Optional, receives a JSON document with extended errorCode
/// information. The caller must release the buffer using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnEnumerateLoadBalancers(
_In_ PCWSTR Query,
_Outptr_ PWSTR* LoadBalancer,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Create a LoadBalancer
///
/// \param Id Specifies the unique ID for the new LoadBalancer.
/// \param Settings JSON document specifying the settings of the new LoadBalancer.
/// \retval LoadBalancer Receives a handle to the new LoadBalancer.
/// \retval ErrorRecord Optional, receives a JSON document with extended errorCode
/// information. The caller must release the buffer using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCreateLoadBalancer(
_In_ REFGUID Id,
_In_ PCWSTR Settings,
_Out_ PHCN_LOADBALANCER LoadBalancer,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Opens a handle to an existing LoadBalancer.
///
/// \param Id Unique ID of the existing LoadBalancer.
/// \retval LoadBalancer Receives a handle to the LoadBalancer.
/// \retval ErrorRecord Optional, receives a JSON document with extended errorCode
/// information. The caller must release the buffer using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
WINAPI
HcnOpenLoadBalancer(
_In_ REFGUID Id,
_Out_ PHCN_LOADBALANCER LoadBalancer,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Modify the settings of a PolcyList
///
/// \param PolcyList Handle to a PolcyList.
/// \param Settings JSON document specifying the new settings of the PolcyList.
/// \retval ErrorRecord Optional, receives a JSON document with extended errorCode
/// information. The caller must release the buffer using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnModifyLoadBalancer(
_In_ HCN_LOADBALANCER LoadBalancer,
_In_ PCWSTR Settings,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Query LoadBalancer properties
///
/// \param LoadBalancer Handle to a LoadBalancer.
/// \param Query Optionally specifies a JSON document for a query
/// containing specific properties of the LoadBalancer
/// return. By default all properties are returned.
/// \retval Properties Receives a JSON document with LoadBalancer properties.
/// \retval ErrorRecord Optional, receives a JSON document with extended errorCode
/// information. The caller must release the buffer using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnQueryLoadBalancerProperties(
_In_ HCN_LOADBALANCER LoadBalancer,
_In_ PCWSTR Query,
_Outptr_ PWSTR* Properties,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Delete a LoadBalancer
///
/// \param Id Unique ID of the existing LoadBalancer.
/// \retval ErrorRecord Optional, receives a JSON document with extended errorCode
/// information. The caller must release the buffer using
/// CoTaskMemFree.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnDeleteLoadBalancer(
_In_ REFGUID Id,
_Outptr_opt_ PWSTR* ErrorRecord
);
/// Close a handle to a LoadBalancer
///
/// \param LoadBalancer Handle to a LoadBalancer.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT
WINAPI
HcnCloseLoadBalancer(
_In_ HCN_LOADBALANCER LoadBalancer
HCN_Notification_Callback
Há funções que fornecem acesso a operações em 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.
///
/// \returns S_OK if successful; HResult error code on failures.
///
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.
///
/// \returns S_OK if successful; HResult error code on failures.
///
HRESULT WINAPI
HcnUnregisterServiceCallback(
_In_ HCN_CALLBACK CallbackHandle
);
 Esquemas de documento JSON de HCN
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019

Esquema HCN
 // 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>,
// AsString; Values:
// "NAT" (0),
// "ICS" (1),
// "Transparent" (2)
"Ipams" : [ {
"Type" : <enum>,
// AsString; Values:
// "Static" (0),
// "Dhcp" (1)
"Subnets" : [ {
"IpAddressPrefix" : <ip prefix in CIDR>,
"Policies" : [ {
"Type" : <enum>,
// AsString; Values:
// "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>,
// AsString; Values:
// "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

 // Endpoint
{
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"Flags" : <enum bit mask>,
// AsString; Values:
// "None" (0),
// "DisableInterComputeCommunication" (2)
"HostComputeNetwork" : <string>,
"MacAddress" : <string>,
"Policies" : [ {
"Type" : <enum>,
// AsString; Values:
// "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

// VlanPolicy
{
"Type" : "VLAN",
"IsolationId" : <uint32>,
}
// PortMappingPolicy
{
"Type" : "PortMapping",
"Protocol" : <enum>,
// AsString; Values:
// "Unknown" (0),
// "ICMPv4" (1),
// "IGMP" (2),
// "TCP" (6),
// "UDP" (17),
// "ICMPv6" (58)
"InternalPort" : <uint16>,
"ExternalPort" : <uint16>,
}

Esquema do balanceador de carga HCN

 // Host Compute LoadBalancer
{
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"Flags" : <enum bit mask>,
// AsString; Values:
// "None" (0),
// "EnableDirectServerReturn" (1)
// "EnableInternalLoadBalancer" (2)
"HostComputeEndpoints" : [<Host compute Endpoint id>],
"VirtualIPs" : [<Virtual IpAddress>],
"PortMappings" : [ {
"Type" : "PortMapping",
"Protocol" : <enum>,
// AsString; Values:
// "Unknown" (0),
// "ICMPv4" (1),
// "IGMP" (2),
// "TCP" (6),
// "UDP" (17),
// "ICMPv6" (58)
"InternalPort" : <uint16>,
"ExternalPort" : <uint16>,
} ],
"Policies" : [ {
"Type" : <enum>,
// AsString; Values:
// "SourceVirtualIp" (0),
"Data" : <any>
} ],
}

Esquema de namespace hcn

// Namespace
{
"Id" : <string>,
"Owner" : <string>,
"SchemaVersion" : {
"Major" : <uint32>,
"Minor" : <uint32>
},
"NamespaceId" : <uint32>,
"NamespaceGuid" : <guid>,
"Type" : <enum>,
// AsString; Values:
// "Host" (0),
// "HostDefault" (1),
// "Guest" (2),
// "GuestDefault" (3)
"Resources" : [ {
"Type" : <enum>,
// AsString; Values:
// "Container" (0),
// "Endpoint" (1)
"Data" : <any>
} ],
}
Esquema de notificação do HCN
// Notification
{
"ID" : Guid,
"Flags" : <uint32>,
};

Esquema de erro de resultado

// ErrorSchema
{
"ErrorCode" : <uint32>,
"Error" : <string>,
"Success" : <bool>,
}
 Exemplo de código gerado por C#
13/08/2021 • 4 minutes to read

aplica-se a: Windows server 2022, Windows server 2019

/*
* 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>
/// </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>
/// <returns>Boolean</returns>
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
*
* 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>
/// 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>
/// <returns>Boolean</returns>
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>
/// <returns>Boolean</returns>
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 != 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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019

/*
* HCN API
*
* No description provided (generated by Swagger Codegen https://github.com/swagger-api/swagger-codegen)
*
* 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
*
* No description provided (generated by Swagger Codegen https://github.com/swagger-api/swagger-codegen)
*
* 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
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico fornece uma visão geral do Comutadores Virtuais do Hyper-V, que fornece a capacidade de conectar
VMs de máquinas virtuais 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 de Rede Definida pelo Software ( ) .

NOTE
Além deste tópico, a documentação do Com switch 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 no Windows Server 2016.

O Com switch virtual hyper-V é um comando de rede Ethernet de camada 2 baseado em software que está
disponível no Gerenciador do Hyper V quando você instala a função de - - servidor - Hyper-V.
O Comutr Virtual hyper-V inclui funcionalidades gerenciadas e extensíveis de forma programática 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.

NOTE
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 Com switch 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 da Especificação de Interface de Dispositivo de Rede e drivers
de saída WFP da Plataforma de Filtragem do Windows, o Comutamento Virtual hyper-V permite que isVs
independentes de fornecedores de software criem ( ) ( ) ( ) plug-ins extensíveis, chamados extensões de
comutadores virtuais, 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 que está conectada ao Com switch virtual do Hyper-V por
meio de uma porta switch.
Os recursos do Com switch virtual do Hyper-V fornecem mais opções para impor isolamento de locatário,
modelar e controlar o tráfego de rede e empregar medidas de proteção contra VMs mal-intencionadas.

NOTE
No Windows Server 2016, uma VM com uma NIC virtual exibe com precisão a produtividade máxima para a NIC virtual.
Para exibir a velocidade de 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.

Usos para o Com switch virtual do Hyper-V

A seguir estão alguns cenários de caso de uso para o Com switch 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 computação 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á vender serviços de hospedagem com
preço 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 (filas de máquinas virtuais) atribuídas à máquina virtual
(VMQ) 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 opção: uma empresa instalou extensões em seu host Hyper-V para
monitorar o tráfego e relatar a detecção de intrusão. 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 VL AN: uma empresa de mudança principal está criando uma
extensão de encaminhamento que aplica todas as políticas de 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 switch chama programaticamente uma API (interface de
programação de aplicativo) WMI (Instrumentação de Gerenciamento de Windows) que liga a transparência,
dizendo ao Comutamento Virtual hyper-V para passar e não tomar nenhuma ação em marcas de VLAN.

Funcionalidade do com switch virtual do Hyper-V

Estes são alguns dos principais recursos incluídos no Comutador Virtual Hyper-V:
 Proteção contra spoofing (spoofing) de ARP/ND: fornece proteção contra uma VM mal-intencionada
usando a spoofing do Protocolo de Resolução de Endereço (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 contra 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 do MAC (Controle de
Acesso de Mídia) ou IP (Protocolo IP), o que permite configurar o isolamento de rede virtual.
Modo tronco para uma VM: permite que os administradores configurarem uma VM específica como
uma dispositivo virtual e, em seguida, direcionar o tráfego de várias VLANs para essa VM.
Monitoramento de tráfego de rede: permite que os administradores revisem o tráfego que está
atravessando o com switch de rede.
VL AN isolada (privada) : permite que os administradores separem o tráfego em várias vlans para
estabelecer com mais facilidade as comunidades de locatário isoladas.
A seguir está uma lista de funcionalidades que melhoram a capacidade de uso do Comutador Virtual Hyper-V:
Limite de largura de banda e supor te a estouro: 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.
A marcação ECN (Notificação de Congestionamento Explícito) permite que a marcação ECN, também
conhecida como DCTCP (Data CenterTCP), habilita o comutador físico e o sistema operacional a regular o
fluxo de tráfego, de modo que os recursos de buffer do comutador não sejam inundados, o que resulta
em maior 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 com switch virtual.
 IPAM (Gerenciamento de Endereços IP)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

NOTE
Além deste tópico, o conteúdo IPAM conteúdo está disponível.
Novidades no IPAM
Gerenciar IPAM
Gerenciamento de Endereço IP (IPAM) cmdlets de servidor no Windows PowerShell
Vídeo: Windows Server 2016: gerenciamento de DNS no IPAM
 Novidades no IPAM
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 CSP (provedor de serviços de nuvem) ou Enterprise 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.

REC URSO / F UN C IO N A L IDA DE N O VO O U M EL H O RA DO DESC RIÇ Ã O

Gerenciamento de endereço IP Melhoria de IPAM recursos são aprimorados para

aprimorado cenários como 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ços
IP.

Gerenciamento de serviço DNS Novo IPAM dá suporte ao registro de

aprimorado recursos DNS, encaminhador
condicional e gerenciamento de zona
DNS para servidores DNS integrados
ao Active Directory e com suporte a
arquivos ingressados no domínio.

Gerenciamento integrado de DNS, Melhoria de Várias novas experiências e operações

DHCP e endereço IP (DDI) integradas de gerenciamento do ciclo
de vida estão habilitadas, como
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 do Active
Directory
Novo 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 de
duas vias entre a floresta em que o
IPAM está instalado e cada uma das
florestas remotas.
 REC URSO / F UN C IO N A L IDA DE N O VO O U M EL H O RA DO DESC RIÇ Ã O

Limpar dados de utilização Novo Agora você pode reduzir o tamanho

IPAM banco de dados por meio da
redução dos dados de utilização do
endereço IP mais antigos do que uma
data especificada.

Windows PowerShell suporte para Novo Você pode usar Windows PowerShell
controle de acesso baseado em função para definir escopos de acesso em
IPAM objetos.

Gerenciamento de endereço IP aprimorado

Os recursos a seguir melhoram as funcionalidades IPAM gerenciamento de endereços.

NOTE
Para a IPAM Windows PowerShell de comando, consulte cmdlets Gerenciamento de Endereço IP (IPAM) server no
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.

NOTE
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.

NOTE
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 em domínio e
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:
Zonas DNS e coleta de 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 ou Transferir 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
Descober ta 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 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 PowerShell and
Gerenciamento de Endereço IP (IPAM) Server Cmdlets in Windows PowerShell.
 Gerenciar o IPAM
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este guia fornece informações de administração e solução de problemas para o recurso 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 ingressados no domínio e
com suporte a arquivos. 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 DNS
Gerenciamento de zona DNS
Gerenciar recursos em várias florestas do Active Directory
Limpar dados de utilização
Controle de acesso baseado em função

Consulte Também
Gerenciamento de Endereço IP (IPAM)
 Gerenciamento de registro de recursos de DNS
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico fornece informações sobre como gerenciar registros de recursos DNS usando IPAM.

NOTE
Além deste tópico, os tópicos de gerenciamento de registro 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 o IPAM no Windows Server 2016, você pode executar a descoberta de servidor para adicionar
servidores DHCP e DNS ao console de gerenciamento IPAM servidor. O 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 em que ele armazena esses dados DNS. IPAM fornece uma notificação do dia e da hora em que os
dados do servidor foram coletados, bem como o próximo dia e 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 IPAM notificações.

Os dados DNS coletados incluem informações de zona DNS e registro de recurso. Você pode configurar o IPAM
para coletar informações de zona de seu servidor DNS preferencial. IPAM coleta as zonas do Active Directory e
baseadas em arquivo.

NOTE
IPAM coleta dados exclusivamente de servidores DNS da Microsoft ingressados no domínio. Não há suporte para
servidores DNS de terceiros e servidores não ingressados no domínio IPAM.

Veja a seguir uma lista de tipos de registro de recurso DNS 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
Roteá-lo
Local do Serviço
SOA
SRV
Texto
Serviços conhecidos
WINS
WINS-R
X.25
No Windows Server 2016, o IPAM fornece integração entre o inventário de endereços IP, zonas DNS e registros
de recursos DNS:
Você pode usar o IPAM para criar automaticamente um inventário de endereços IP de registros de
recursos DNS.
Você pode criar manualmente um inventário de endereços 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 Look up
Inversa do DNS.
IPAM cria endereços IP para os registros PTR que estão presentes na zona de busca 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 executar 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 dns.
Consulte Também
Gerenciar IPAM
 Adicionar um registro de recursos de DNS
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para adicionar um ou mais novos registros de recursos DNS usando o console IPAM
cliente.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para adicionar um registro de recurso DNS
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 painel de navegação inferior.
3. No painel de navegação inferior, clique em For ward Lookup . Todas as IPAM de pesquisa de
encaminhamento de DNS gerenciadas pelo DNS 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 Recurso DNS é aberta. Em Propriedades do registro

de recurso , clique em Servidor DNS e selecione o servidor DNS no qual você deseja adicionar um ou
mais novos registros de recurso. Em Configurar registros de recursos DNS, clique em Novo.
5. A caixa de diálogo expande para revelar Novo Registro de Recurso. Clique em Tipo de registro de
recurso .

6. A lista de tipos de registro de recurso é 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. Em 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 registros de recursos adicionais, clique em OK. Se você quiser criar registros de
recursos adicionais, clique em Novo .
 9. A caixa de diálogo expande para revelar Novo Registro de Recurso. Clique em Tipo de registro de
recurso . A lista de tipos de registro de recurso é 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. Em 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 recurso, clique em Aplicar .
12. A caixa de diálogo Adicionar Registro de Recurso exibe um resumo de registros de recursos enquanto
IPAM os registros de recurso 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 registros de recursos DNS Gerenciar IPAM
 Excluir registros de recursos de DNS
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para excluir um ou mais registros de recursos DNS usando o console do cliente do
IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para excluir registros de recursos de DNS
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em zonas DNS . O painel de navegação
divide-se em um painel de navegação superior e em um painel de navegação inferior.
3. Clique para expandir a pesquisa direta e o domínio no qual os registros de zona e de recursos que você
deseja excluir estão localizados. Clique na zona e, no painel de exibição, clique em exibição atual . Clique
em registros de recursos .
4. No painel de exibição, localize e selecione os registros de recursos 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 em ser vidor DNS e selecione o servidor do qual você deseja excluir
os registros de recursos. Clique em OK . IPAM exclui os registros de recursos do servidor DNS.

Consulte Também
Gerenciamento de registros de recursos de DNS Gerenciar IPAM
 Filtrar a exibição de registros de recursos de DNS
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para filtrar a exibição de registros de recursos DNS no console IPAM cliente.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para filtrar a exibição de registros de recursos DNS
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 painel de navegação inferior.
3. No painel de navegação inferior, clique em For ward Lookup . Todas as IPAM de pesquisa de
encaminhamento de DNS gerenciadas pelo DNS 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 em Exibição atual e, em seguida, clique em Registros de Recursos . Os
registros de recurso para a 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 lista listada. 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 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
Gerenciamento de registros de recursos DNS Gerenciar IPAM
 Exibir registros de recurso de DNS para um
endereço IP específico
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para exibir os registros de recursos de DNS que estão associados ao endereço IP que
você escolher.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para exibir registros de recursos para um endereço IP
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em espaço de endereço IP , clique em inventário de endereço 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 recursos DNS você
deseja exibir.

3. No modo de exibição detalhes do painel de exibição, clique em registros de recursos DNS . Os

registros de recursos associados ao endereço IP selecionado são exibidos.
Consulte Também
Gerenciamento de registros de recursos de DNS Gerenciar IPAM
 Gerenciamento de zonas DNS
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

este tópico fornece informações sobre como gerenciar zonas DNS usando o console do cliente do IPAM.

NOTE
além deste tópico, os tópicos de IPAM de gerenciamento de zona DNS a seguir estão disponíveis nesta seção.
Criar uma zona DNS
Editar uma zona DNS
Exibir registros de recurso DNS para uma zona DNS
Exibir Zonas DNS

ao implantar IPAM no Windows Server 2016, você pode usar IPAM para gerenciar as zonas DNS.
no console do IPAM, você pode exibir os registros de recurso 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 os registros de recursos de DNS para zonas específicas

Consulte Também
Gerenciar IPAM
 Criar uma zona DNS
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para criar uma zona DNS usando o console do cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para criar uma zona DNS
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em ser vidores DNS e DHCP . No painel
de exibição, clique em tipo de ser vidor e, em seguida, clique em DNS . todos os servidores DNS
gerenciados pelo IPAM são listados nos resultados da pesquisa.
3. Localize o servidor no qual 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 em nome da zona . Selecione também os valores apropriados
para sua implantação em Propriedades avançadas e clique em OK .
Consulte Também
Gerenciamento de zona DNS Gerenciar IPAM
 Editar uma zona DNS
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para editar uma zona DNS no console do cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para editar uma zona DNS
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em zonas DNS . O painel de navegação
divide-se em um painel de navegação superior e em um painel de navegação inferior.
3. No painel de navegação inferior, faça uma das seguintes seleções:
Pesquisa direta
Pesquisa inversa de IPv4
Pesquisa inversa de IPv6
4. Por exemplo, selecione pesquisa inversa de 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: ser vidor DNS , categoria de zona e tipo de zona e, em seguida, 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 avançadas de
zona é aberta. Se necessário, edite as propriedades que você deseja alterar e, em seguida, 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 em OK . Para revisar todas as
edições de zona, clique em Resumo e em OK .

Consulte Também
Gerenciamento de zona DNS Gerenciar IPAM
 Exibir registros de recurso de DNS para uma zona
DNS
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para exibir registros de recursos de dns para uma zona dns no console do cliente do
IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para exibir registros de recursos de DNS para uma zona
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em zonas DNS . O painel de navegação
divide-se em um painel de navegação superior e em um painel de navegação inferior.
3. No painel de navegação inferior, clique em pesquisa direta e, em seguida, expanda a lista domínio e
zona 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 da zona. Para alterar a exibição, clique em
modo de exibição atual e em registros de recursos .
5. Os registros de recursos de DNS para a zona são exibidos. Para filtrar os registros, digite o texto que você
deseja localizar 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 faça seleções na lista critérios e clique em Adicionar .

Consulte Também
Gerenciamento de zona DNS Gerenciar IPAM
 Exibir zonas DNS
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para exibir as zonas DNS no console do cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
para exibir as zonas DNS no console do cliente do IPAM
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, em monitorar e gerenciar , clique em zonas DNS . O painel de navegação
divide-se em um painel de navegação superior e em um painel de navegação inferior.
3. No painel de navegação inferior, faça uma das seguintes seleções:
Pesquisa direta
Pesquisa inversa de IPv4
Pesquisa inversa de IPv6
Encaminhador condicional

Consulte Também
Gerenciamento de zona DNS Gerenciar IPAM
 Gerenciar recursos em várias florestas do Active
Directory
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para aprender a usar o IPAM para gerenciar controladores de domínio, servidores
DHCP e servidores DNS em várias florestas de Active Directory.
para usar IPAM para gerenciar recursos em florestas de Active Directory remotas, cada floresta que você deseja
gerenciar deve ter uma relação de confiança bidirecional com a floresta onde IPAM está instalado.
Para iniciar o processo de descoberta para diferentes Active Directory florestas, abra Gerenciador do Servidor e
clique em IPAM. no console do cliente do IPAM, clique em configurar descober ta de ser vidor e 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 descober ta de ser vidor , que abre a caixa de
diálogo a seguir.
 NOTE
para o - provisionamento baseado em Política de Grupo para um cenário de Active Directory entre florestas, certifique-se
de executar o cmdlet Windows PowerShell a seguir no servidor IPAM e não nos controladores de domínio confiantes. por
exemplo, se o seu servidor de IPAM estiver ingressado na floresta corp.contoso.com e a floresta confiante for
fabrikam.com, você poderá executar o seguinte cmdlet Windows PowerShell no servidor IPAM no corp.contoso.com para -
o provisionamento baseado em Política de Grupo na floresta fabrikam.com. Para executar esse cmdlet, você deve ser
membro do grupo Admins. do domínio na floresta fabrikam.com.

Invoke-IpamGpoProvisioning -Domain fabrikam.COM -GpoPrefixName IPAMSERVER -IpamServerFqdn

IPAM.CORP.CONTOSO.COM

Na caixa de diálogo Configurar descober ta de ser vidor , 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 ser vidor para descobrir , para cada domínio que você deseja gerenciar,
especifique o tipo de servidores a serem descobertos. As opções são controlador de domínio , ser vidor
DHCP e ser vidor DNS .
Por padrão, os controladores de domínio, servidores DHCP e 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 dessa opção.
na ilustração de exemplo acima, o servidor de 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 é concluída, você pode gerenciar recursos na floresta local e remota.
 Limpar dados de utilização
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 IP ou grupos de
inter valos de endereços IP .
3. Clique em tarefas e, 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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico fornece informações sobre como usar o controle de acesso baseado em função no IPAM.

NOTE
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 o Gerenciador do servidor Gerenciar o controle de
acesso baseado em função com o Windows PowerShell Gerenciar IPAM
 Gerenciar controle de acesso baseado em função
com o Gerenciador do Servidor
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para criar uma nova função de usuário de controle de acesso no console do cliente
do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.

NOTE
Depois de criar uma função, você pode criar uma política de acesso para atribuir a função a um usuário ou grupo de
Active Directory específico. Para obter mais informações, consulte criar uma política de acesso.

Para criar uma função

1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
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 recurso SRV DNS, você pode nomear a função IPAMSr v . 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 de DNS .

5. Expanda operações de gerenciamento de registro de recurso DNS e localize operações de

registro SRV .

6. Expanda e selecione as operações de registro SRV e clique em OK .

7. no console do cliente do IPAM, clique na função que você acabou de criar. Na exibição de detalhes, as
operações permitidas para a função são exibidas.

Consulte Também
Controle de acesso baseado em função Gerenciar IPAM
 Criar uma política de acesso
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para criar uma política de acesso no console do cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.

NOTE
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 as funções personalizadas, consulte criar uma função de usuário para o controle
de acesso.

Para criar uma política de acesso

1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
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. em Configurações de usuário , 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 é fechada.
6. Na caixa de diálogo Selecionar usuário ou grupo , em digite o nome do objeto a ser
selecionado , digite o nome da conta de usuário para a qual você deseja criar uma política de acesso.
Clique em OK .
7. em adicionar política de acesso , no usuário Configurações , o alias de usuário agora contém a
conta de usuário à qual a política se aplica. em Configurações de acesso , clique em novo .

8. em adicionar política de acesso , acesse Configurações alterações para 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 que você criou. Por exemplo, se você criou
a função IPAMSrv para aplicar ao usuário, clique em IPAMSr v .
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 essas 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
Controle de acesso baseado em função Gerenciar IPAM
 Definir escopo de acesso para uma zona DNS
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para definir o escopo de acesso para uma zona DNS usando o console IPAM cliente.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para definir o escopo de acesso para uma zona DNS
1. No Gerenciador do Servidor, clique em IPAM . O IPAM do cliente é exibido.
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. Em seguida, 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 escopo de acesso do pai. Em Selecionar o escopo de acesso, selecione um
item e clique em OK.
4. No painel IPAM de exibição do console do cliente, verifique se o escopo de acesso para a zona foi
alterado.

Consulte Também
Controle de acesso baseado em função Gerenciar IPAM
 Definir escopo de acesso para registros de recurso
DNS
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para definir o escopo de acesso para registros de recursos DNS usando o console do
cliente do IPAM.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para definir o escopo de acesso para registros de recursos de DNS
1. Em Gerenciador do Servidor, clique em IPAM . o console do cliente do IPAM é exibido.
2. No painel de navegação, clique em zonas DNS . No painel de navegação inferior, expanda pesquisa
direta e navegue até e selecione a zona que contém os registros de recursos cujo escopo de acesso você
deseja alterar.
3. No painel de exibição, localize e selecione os registros de recursos 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
anular a seleção de herdar o escopo de acesso do pai . Em selecionar o escopo de acesso ,
selecione um item e clique em OK .

Consulte Também
Controle de acesso baseado em função Gerenciar IPAM
 Exibir funções e permissões de função
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para exibir as funções de usuário do Controle de Acesso no console IPAM cliente.
A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.
Para exibir funções de Controle de Acesso
1. No Gerenciador do Servidor, clique em IPAM . O IPAM do cliente é exibido.
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 baseado em função Gerenciar IPAM
 Gerenciar controle de acesso baseado em função
com o Windows PowerShell
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para aprender a usar o IPAM gerenciar o controle de acesso baseado em função com
Windows PowerShell.

NOTE
Para a IPAM Windows PowerShell de comando, consulte os cmdlets IpamServer no Windows PowerShell.

Os novos Windows PowerShell IPAM novos 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.

IPA M O B JETO C O M A N DO DESC RIÇ Ã 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 DNS Get-IpamResourceRecord Esse cmdlet retorna o objeto de

registro de recurso DNS IPAM

Encaminhador Condicional dns Get-IpamDnsConditionalForwarder Esse cmdlet retorna o objeto de

encaminhador condicional DNS IPAM

Servidor DHCP Get-IpamDhcpServer Esse cmdlet retorna o objeto de

servidor DHCP IPAM

Superescopo do DHCP Get-IpamDhcpSuperscope Esse cmdlet retorna o objeto de

superescopo DHCP IPAM

Escopo do DHCP Get-IpamDhcpScope Esse cmdlet retorna o objeto de

escopo DHCP em IPAM

No exemplo a seguir de saída de comando, o Get-IpamDnsZone cmdlet recupera a zona

DUBLIN.CONTOSO.COM 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 em 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[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDhcpServer] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDhcpSuperscope] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDhcpScope] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDnsConditionalForwarder] -InputObject <ciminstance[]> [-AccessScopePath

<string>] [-IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob]
[-WhatIf] [-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDnsResourceRecord] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamDnsZone] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamAddressSpace] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm]
[<CommonParameters>]

Set-IpamAccessScope [-IpamSubnet] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm] [<CommonParameters>]

Set-IpamAccessScope [-IpamBlock] -InputObject <ciminstance[]> [-AccessScopePath <string>] [-

IsInheritedAccessScope] [-PassThru] [-CimSession <CimSession[]>] [-ThrottleLimit <int>] [-AsJob] [-WhatIf]
[-Confirm] [<CommonParameters>]

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 -ZoneName dublin.contoso.com

ZoneName : dublin.contoso.com
ZoneType : Forward
AccessScopePath : \Global\Dublin
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False

PS C:\Users\Administrator.CONTOSO> $a = Get-IpamDnsZone -ZoneType Forward -ZoneName dublin.contoso.com

PS C:\Users\Administrator.CONTOSO> Set-IpamAccessScope -IpamDnsZone -InputObject $a -AccessScopePath
\Global\Europe -PassThru

ZoneName : dublin.contoso.com
ZoneType : Forward
AccessScopePath : \Global\Europe
IsSigned : False
DynamicUpdateStatus : None
ScavengeStaleRecords : False
 Network Load Balancing
12/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Neste tópico, fornecemos uma visão geral do recurso NLB de 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 de Internet, como aqueles usados
em Web, FTP, firewall, proxy, VPN de rede privada virtual ( ) e outros servidores de missão - crítica.

NOTE
a Windows Server 2016 inclui um novo Software inspirado pelo Azure Load Balancer ( SLB ) como um componente da
infraestrutura de SDN de rede definida pelo Software ( ) . Use SLB em vez de NLB se você estiver usando o SDN, usando
cargas de trabalho não Windows, precisar de NAT de conversão de endereços de rede ( ) de saída ou necessidade de
balanceamento de carga de camada 3 ( L3 ) ou 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 SLB, consulte balanceamento de carga de
software (SLB) para Sdn.

O recurso NLB de balanceamento de carga de rede ( ) distribui o tráfego entre vários servidores usando o /
protocolo de rede IP TCP. Ao combinar dois ou mais computadores que estão executando aplicativos em um
único cluster virtual, o NLB fornece confiabilidade e desempenho para servidores Web e outros - servidores de
missão crítica.
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 é redistribuída automaticamente entre
os computadores que ainda estão operando. 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 aplicativos sem estado, como servidores web que executam Serviços de
Informações da Internet ( IIS ) , estejam disponíveis com tempo de inatividade mínimo e que sejam escalonáveis
( adicionando mais 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 fornecer 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:
Equilibre solicitações de carga no cluster NLB para serviços IP individuais de TCP / .
Dar suporte para até 32 computadores em um único cluster.
Equilibre várias solicitações ( de carga de servidor do mesmo cliente ou de vários clientes em ) vários
hosts no 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
Gerenciador NLB ou os cmdlets NLB (balanceamento de carga de rede) no 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 serão baseadas no endereço
IP virtual de destino ( usando clusters virtuais ) .
Encaminhe todas as solicitações de cliente para um único host usando regras de host único opcionais - .
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.
Habilite o suporte IGMP do protocolo de gerenciamento de grupo da Internet ( ) nos hosts do cluster
para controlar a saturação da porta do comutador ( em que os pacotes de rede de entrada são enviados
para todas as portas no comutador ) ao operar no 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 de driver de rede do Windows Server padrão. Suas operações são
transparentes para a / pilha de rede IP TCP. A figura a seguir mostra a relação entre o 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 único nome de Internet lógico e um endereço IP
virtual, que é conhecido como o endereço IP do cluster, ( ele retém os nomes individuais de cada
computador ) . O NLB permite vários endereços IP virtuais para servidores multihomed.

NOTE
Quando você implanta VMs como clusters virtuais, o NLB não exige que os servidores sejam de hospedagem múltipla
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 - manipular - o cliente para o tráfego
de cluster deve dar suporte à alteração do seu endereço MAC de controle de acesso à mídia ( ) .

Requisitos de software
A seguir estão os requisitos de software para executar um cluster NLB.
Somente TCP / IP pode ser usado no adaptador para o qual o NLB está habilitado em cada host. Não
adicione nenhum outro protocolo ( , por exemplo, IPX ) a esse adaptador.
Os endereços IP dos servidores no cluster devem ser estáticos.

NOTE
O NLB não dá suporte ao DHCP do protocolo de configuração de host dinâmico ( ) . 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 do NLB.
Instalação com o Gerenciador do Servidor
No Gerenciador do Servidor, você pode usar o assistente para adicionar funções e recursos para adicionar o
recurso de balanceamento de carga de rede . Quando você concluir o assistente, o NLB será instalado e não
será necessário reiniciar o computador.
Instalação com o Windows PowerShell
para instalar o NLB usando Windows PowerShell, execute o comando a seguir em um prompt de Windows
PowerShell elevado no computador em que você deseja instalar o NLB.

Install-WindowsFeature NLB -IncludeManagementTools

Após a conclusão da instalação, não é necessário reiniciar o computador.

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.

T IP O DE C O N T EÚDO REF ERÊN C IA S

Implantação Guia de implantação de balanceamento de carga de rede |

configurar o balanceamento de carga de rede com serviços
de terminal
T IP O DE C O N T EÚDO REF ERÊN C IA S

Operations Gerenciar clusters de balanceamento de carga de rede |

definir parâmetros de balanceamento de carga de rede |
controlar hosts em clusters de balanceamento de carga de
rede

Solução de problemas Solucionando problemas de clusters de balanceamento de

carga de rede | eventos e erros de cluster NLB

Ferramentas e configurações Cmdlets do Windows PowerShell para Balanceamento de

Carga de Rede

Recursos da comunidade Fórum de ( clustering de alta disponibilidade )

 NPS (Servidor de Políticas de Rede)
12/08/2021 • 14 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2016 e Windows Server 2019

Você pode usar este tópico para uma visão geral do Servidor de Políticas de Rede no Windows Server 2016 e
Windows Server 2019. O NPS é instalado quando você instala o recurso NPAS (Network Policy e Serviços do
Access) no Windows Server 2016 Server 2019.

NOTE
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íticas de Rede) Windows PowerShell para Windows Server 2016 e Windows 10
Cmdlets do NPS (Servidor de Políticas de Rede) Windows PowerShell para Windows Server 2012 R2 e Windows 8.1
Cmdlets NPS no 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 (Remote Authentication Dial-In User Service) para
encaminhar solicitações de conexão para um NPS remoto ou outro servidor RADIUS para que você possa
balancear a carga de solicitações de conexão e encaminhá-las para o domínio correto para autenticação e
autorização.
O NPS permite configurar e gerenciar centralmente a autenticação, a autorização e a contabilidade de acesso à
rede com os seguintes recursos:
Ser vidor RADIUS . O NPS executa autenticação centralizada, autorização e contabilização de comutadores
sem fio, autenticação, discagem de acesso remoto e conexões 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 Servidor RADIUS.
Proxy RADIUS . Ao usar o NPS como um proxy RADIUS, você configura políticas de solicitação de conexão
que dizem 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 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 Registro
 em log do NPS.

IMPORTANT
NAP da Proteção de Acesso à Rede, HRA da Autoridade de Registro de Saúde e Protocolo de Autorização de Credencial do
Host foram preterido 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 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 a membros de um grupo de servidores RADIUS remoto para autenticação e
autorização em outro domínio.

Windows Edições de servidor e NPS

O NPS fornece funcionalidades diferentes, dependendo da edição do Windows Server instalado.
Windows Server 2016 ou Windows Server 2019 Standard/Datacenter Edition
Com o NPS no 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.

NOTE
O recurso política de rede e Serviços do Access WIndows não está disponível em sistemas instalados com uma opção de
instalação 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
NPS é a implementação da Microsoft do padrão RADIUS especificado pelo IETF da Força de Tarefa de
Engenharia da Internet nas ( ) RFCs 2865 e 2866. Como um servidor RADIUS, o NPS executa autenticação de
conexão centralizada, autorização e contabilização de muitos tipos de acesso à rede, incluindo conexões sem fio,
comutadores de autenticação, acesso remoto vpn de rede privada e discagem e rede virtual privada e conexões
de roteador para ( ) roteador.

NOTE
Para obter informações sobre como implantar o NPS como um servidor RADIUS, consulte Deploy Network Policy Server.

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 no Windows Server 2016.
O NPS usa um Active Directory Domain Services AD DS ou o banco de dados de contas de usuário SAM
(Gerenciador de Contas de Segurança) local para autenticar credenciais de usuário para ( ) tentativas de
conexão. Quando um servidor que executa o NPS é membro de um domínio 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 autenticação e autorização de acesso de controle de acesso de rede a uma
rede e para fazer logoff em um ( ) AD DS domínio.

NOTE
O NPS usa as propriedades discadas da conta de usuário e das políticas de rede para autorizar uma conexão.

IsPs de provedores de serviços de Internet e organizações que mantêm o acesso à rede têm o maior desafio 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 são autenticadas e a tentativa de conexão é
autorizada, o servidor RADIUS autoriza o acesso do usuário com base nas condições especificadas e, em
seguida, registra 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 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 clientes de acesso.
Você está usando o Acesso Remoto em vários servidores discados, servidores VPN ou roteadores discados
por demanda e deseja centralizar a configuração de políticas de rede e registro em log de conexão e
contabilidade.
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 de 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 um 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 de usuário, autorização e contabilização para a tentativa ( ) de conexão.
Quando usado como um proxy RADIUS, o NPS é um ponto central de troca ou roteamento por meio do qual o
acesso RADIUS e as mensagens de contabilidade fluem. O NPS registra informações em um log de
contabilidade sobre as mensagens encaminhadas.
Usando 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 acesso à rede discada, VPN ou sem fio
para vários clientes. Seus NASs enviam solicitações de conexão para o proxy RADIUS do NPS. Com base na
parte do 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 relação de confiança de duas vias com o
domínio no qual o NPS é membro. Isso inclui contas em domínios não confiáveis, domínios confiáveis e
outras florestas. Em vez de configurar seus servidores de acesso para enviar suas solicitações de conexão
para um servidor NPS RADIUS, você pode configurá-los para enviar suas solicitações de conexão para um
proxy NPS RADIUS. 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. As 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 é um banco de
dados Windows conta. Nesse caso, as solicitações de conexão que corresponderem 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 o 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 RADIUS NPS balanceia dinamicamente a carga de solicitações de conexão e
contabilidade em vários servidores RADIUS e aumenta o processamento de grandes números de clientes
RADIUS e autenticações por segundo.
Você deseja fornecer autenticação RADIUS e autorização 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 na 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 para um provedor de
serviços, mantendo o controle sobre autenticação, autorização e contabilidade do usuário.
As configurações do NPS podem ser criadas para os seguintes cenários:
Acesso sem fio
Acesso remoto de rede virtual privada (VPN) ou dial-up da organização
Dial-up ou acesso sem fio terceirizado
Acesso à Internet
Acesso autenticado a recursos de extranet para parceiros de negócios

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 ser vidor RADIUS . Neste exemplo, o NPS é configurado como um servidor RADIUS, a diretiva
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 estejam 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 remotos RADIUS 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 ser vidor RADIUS e proxy RADIUS . Além da diretiva de solicitação de conexão padrão, que
designa que as solicitações de conexão são processadas localmente, é criada uma nova política de solicitação de
conexão que encaminha as 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 de proxy. Neste exemplo, a política de proxy aparece
primeiro na lista ordenada de políticas. Se a solicitação de conexão corresponder à política de proxy, a
solicitação de conexão será encaminhada para o servidor RADIUS no grupo de servidores remotos RADIUS. 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 política, ela será descartada.
NPS como um ser vidor RADIUS com ser vidores de contabilidade remoto . 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 contabilização RADIUS sejam encaminhadas para um NPS ou outro servidor RADIUS em
um grupo de servidores remotos RADIUS. Embora as mensagens de contabilização 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 Windows local 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 tem 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 dial-up 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 de
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, a política de rede e a
contabilização 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 proxy RADIUS
Para configurar o NPS como um proxy RADIUS, você deve configurar clientes RADIUS, grupos de servidores
remotos RADIUS 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 clientes RADIUS
Configurar grupos de servidores RADIUS remotos
Configurar políticas de solicitação de conexão

Log do NPS
O log do NPS também é chamado de contabilidade RADIUS. Configure o 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 log do NPS, você deve configurar os eventos que deseja que sejam registrados e exibidos com
Visualizador de Eventos e, em seguida, determinar quais outras informações deseja registrar em log. além disso,
você deve decidir se deseja registrar em log as informações de autenticação e estatísticas de 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 Configure Network Policy Server Accounting.
 Práticas recomendadas do Servidor de Políticas de
Rede
13/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber mais sobre as práticas recomendadas para implantar e gerenciar o NPS
do 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:
Abile 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 nas.
Para obter mais informações, consulte Configure Network Policy Server Accounting.
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écnica e 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 PROTOCOLO PEAP de Autenticação Extensível
Protegido e EAP de 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 o 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 Deploy Password-Based 802.1X Authenticated Wireless Access.
Implante sua própria AC de autoridade de certificação com os Serviços de Certificados do Active Directory
AD CS quando você usar métodos de autenticação fortes baseados em certificado, como PEAP e EAP, que
exigem o uso de um certificado de servidor ( ) em ® ( ) 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 nps e servidores de acesso remoto, consulte Deploy Server
Certificates for 802.1X Wired and Wireless Deployments.

IMPORTANT
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çãode 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.
Cau t i on

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 nomes de entidade de domínio ( universais ) UPNs 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 serão enviados ao servidor de acesso
à rede nas mensagens de notificação de início e ( ) parada. 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 do 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 o 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.

IMPORTANT
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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar os tópicos desta seção para saber mais sobre recursos e funcionalidades do servidor de
diretivas de rede.

NOTE
Para obter a documentação adicional do servidor de políticas de rede, você pode usar as seções de biblioteca a seguir.
Planejar Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede
Gerenciar o Servidor de Políticas de Rede

Esta seção contém os seguintes tópicos.

Processamento de solicitação de conexão
Políticas de rede
Modelos de NPS
Clientes RADIUS
 Processamento de solicitações de conexão
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber mais sobre o processamento de solicitação de conexão no servidor de
políticas de rede no Windows Server 2016.

NOTE
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 territórios
Grupos de servidores RADIUS remotos

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
de servidores RADIUS remoto.
Se desejar que o servidor local que está executando o NPS (servidor de diretivas de rede) execute a autenticação
para solicitações de conexão, você 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 as solicitações de conexão para um NPS remoto ou outro servidor RADIUS, crie um
grupo de servidores remotos RADIUS e configure uma política de solicitação de conexão que encaminhe
solicitações para esse grupo de servidores remotos 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 de Access-Request de um servidor de acesso à rede
para um proxy RADIUS e, em seguida, para um servidor RADIUS em um grupo de servidores 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.

NOTE
Os servidores de acesso à rede que você usa com o NPS podem ser dispositivos de gateway em conformidade com o
protocolo RADIUS, como pontos de acesso sem fio 802.1 X e comutadores de autenticação, servidores que executam
acesso remoto que são configurados como servidores VPN ou dial-up ou outros dispositivos compatíveis com RADIUS.

Se você quiser que o NPS processe algumas solicitações de autenticação localmente ao encaminhar outras
solicitações para um grupo de servidores RADIUS remotos, 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 qual NPS ou grupo de servidores RADIUS
processa solicitações de autenticação, consulte políticas de solicitação de conexão.
Para especificar o NPS ou outros servidores RADIUS aos quais as solicitações de autenticação são
encaminhadas, consulte grupos de servidores remotos RADIUS.

NPS como um processamento de solicitação de conexão de 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 dial-up, 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 o RADIUS como o protocolo de autenticação, autorização e
contabilização, cria uma mensagem de Access-Request e a envia para o NPS.
3. O NPS avalia a mensagem de Access-Request.
4. Se necessário, o NPS envia uma mensagem de Access-Challenge para o servidor de acesso. O servidor
de acesso processa o desafio e envia um Access-Request atualizado 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 das diretivas
de rede.
7. Se a tentativa de conexão for autenticada e autorizada, o NPS enviará uma mensagem de Access-Accept
para o servidor de acesso. Se a tentativa de conexão não for autenticada ou não autorizada, o NPS
enviará uma mensagem de Access-Reject para o servidor de acesso.
8. O servidor de acesso conclui o processo de conexão com o cliente de acesso e envia uma mensagem de
Accounting-Request para o NPS, onde a mensagem é registrada.
9. O NPS envia um Accounting-Response ao servidor de acesso.

NOTE
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 interrompido.

NPS como um processamento de solicitação de conexão 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 dial-up, servidores de rede virtual privada (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 o RADIUS como o protocolo de autenticação, autorização e
contabilização, cria uma mensagem de Access-Request e a envia para o NPS que está sendo usado como
o proxy RADIUS do NPS.
 3. O proxy RADIUS do NPS recebe a mensagem de Access-Request e, com base nas políticas de solicitação
de conexão configuradas localmente, determina para onde encaminhar a mensagem de Access-Request.
4. O proxy RADIUS do NPS encaminha a mensagem de Access-Request para o servidor RADIUS apropriado.
5. O servidor RADIUS avalia a mensagem de Access-Request.
6. Se necessário, o servidor RADIUS envia uma mensagem de Access-Challenge para o proxy RADIUS do
NPS, onde 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 RADIUS do NPS, no qual 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 de
Access-Accept para o proxy RADIUS do NPS, onde ele será encaminhado para o servidor de acesso. Se a
tentativa de conexão não for autenticada ou não autorizada, o servidor RADIUS enviará uma mensagem
de Access-Reject para o proxy RADIUS do NPS, onde ele será 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 de
Accounting-Request para o proxy RADIUS do NPS. O proxy RADIUS do NPS registra os dados de
estatísticas e encaminha a mensagem para o servidor RADIUS.
10. O servidor RADIUS envia um Accounting-Response ao proxy RADIUS do NPS, no qual ele é encaminhado
para o servidor de acesso.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Políticas de solicitação de conexão
13/08/2021 • 17 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para aprender a usar as políticas de solicitação de conexão do NPS para configurar o
NPS como um servidor RADIUS, um proxy RADIUS ou ambos.

NOTE
Além deste tópico, a documentação da política de solicitação de conexão a seguir está disponível.
Configurar políticas de solicitação de conexão
Configurar grupos de servidores RADIUS remotos

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 do serviço RADIUS (RADIUS) executam a autenticação e a
autorização de solicitações de conexão que o servidor que executa o NPS (servidor de diretivas 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 contabilização 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 são encaminhados para outro servidor RADIUS (o NPS é usado como um proxy
RADIUS).
Com as políticas de solicitação de conexão, você pode usar o NPS como um servidor RADIUS ou 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 mensagens de Access-Request RADIUS serã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 forem correspondentes 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 forem correspondentes 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 a um servidor RADIUS remoto para
processamento.
Se as configurações de uma mensagem de Access-Request RADIUS de entrada não corresponderem a pelo
menos uma das políticas de solicitação de conexão, uma mensagem de 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 as 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 estejam 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 está configurado
como um proxy RADIUS. O NPS não processa nenhuma solicitação de conexão no servidor local. Em vez disso,
ele encaminha as solicitações de conexão para o 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 as solicitações de conexão para um NPS ou outro servidor RADIUS em um domínio não confiável.
Neste exemplo, a política de proxy aparece primeiro na lista ordenada de políticas. Se a solicitação de conexão
corresponder à política de proxy, a solicitação de conexão será encaminhada para o servidor RADIUS no grupo
de servidores remotos RADIUS. 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 política, ela será descartada.
NPS como servidor RADIUS com servidores de contabilidade remoto
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 contabilização RADIUS sejam encaminhadas para um
NPS ou outro servidor RADIUS em um grupo de servidores remotos RADIUS. Embora as mensagens de
contabilização 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 Windows local 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 que tenha 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 de política de solicitação de conexão são um ou mais atributos RADIUS que são comparados aos
atributos da mensagem de Access-Request RADIUS de 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 em políticas de solicitação de
conexão.
Grupo de atributos de propriedades de conexão
O grupo de atributos propriedades de conexão contém os atributos a seguir.
Protocolo Framed . Usado para designar o tipo de enquadramento de pacotes de entrada. Os exemplos são
protocolo PPP (PPP), protocolo de Internet de linha serial (SLIP), retransmissão de quadros e X. 25.
Tipo de ser viço . Usado para designar o tipo de serviço que está sendo solicitado. Os exemplos incluem
Framed (por exemplo, conexões PPP) e logon (por exemplo, conexões Telnet). Para obter mais informações
sobre os tipos de serviço RADIUS, consulte RFC 2865, "Remote Authentication Dial-in User Service
 (RADIUS)".
Tipo de Encapsulamento . Usado para designar o tipo de túnel que está sendo criado pelo cliente
solicitante. os tipos de Tunnel incluem o PPTP (protocolo de encapsulamento ponto a ponto) e o L2TP
(protocolo de encapsulamento de camada dois).
Grupo de atributos de restrições de dia e hora
O grupo de atributos restrições de dia e hora contém o atributo de 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.
ID da estação chamada . 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 de NAS.
Endereço IPv4 do nas . Usado para designar o endereço IPv4 (protocolo IP versão 4) 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 (protocolo IP 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 por ta nas . Usado para designar o tipo de mídia usado pelo cliente de acesso. Os exemplos são
linhas telefônicas analógicas (conhecidas como Async), 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 de identidade do computador
O grupo de atributos de identidade do computador 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 de propriedades do cliente RADIUS
O grupo de atributos propriedades do cliente RADIUS contém os seguintes atributos.
ID da estação de chamada . 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.1 x, o endereço MAC é normalmente preenchido e
pode ser correspondido 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 está 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 a 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 a autenticação. Um computador que executa o serviço de roteamento e acesso remoto é o
 fabricante do NAS da Microsoft. 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 de 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 de 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. As configurações consistem nos seguintes grupos de propriedades.
Autenticação
Contabilidade
Manipulação de atributos
Encaminhando a solicitação
Avançado
As seções a seguir fornecem detalhes adicionais sobre essas configurações.
Autenticação
Ao usar essa configuração, você pode substituir as configurações de autenticação definidas em todas as políticas
de rede e pode designar os métodos e tipos de autenticação necessários para se conectar à sua rede.

IMPORTANT
Se você configurar um método de autenticação na diretiva de solicitação de conexão que seja menos segura do que o
método de autenticação configurado na diretiva 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 de autenticação extensível
protegida Protocol-Microsoft protocolo de autenticação de handshake de desafio versão 2 ( PEAP-MS-CHAP v2 ) , que é
um método de autenticação baseado em senha para sem fio seguro e também configurar uma política de solicitação de
conexão para permitir acesso não autenticado, o resultado é que nenhum cliente é solicitado a autenticar usando PEAP-
MS Neste exemplo, todos os clientes que se conectam à sua rede recebem acesso não autenticado.

Contabilidade
Ao usar essa configuração, você pode configurar a política de solicitação de conexão para encaminhar
informações de estatísticas para um NPS ou outro servidor RADIUS em um grupo de servidores remotos
RADIUS para que o grupo de servidores remotos RADIUS execute a contabilidade.

NOTE
Se você tiver vários servidores RADIUS e quiser informações de estatísticas para todos os servidores armazenados em um
banco de dados de contabilidade RADIUS central, poderá usar a configuração contabilidade de política de solicitação de
conexão em uma política em cada servidor RADIUS para encaminhar dados contábeis de todos os servidores para um
NPS ou outro servidor RADIUS designado como um servidor de contabilidade.

As configurações de contabilidade de 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 contabilização RADIUS em um arquivo local ou em um Microsoft SQL Server banco de dados,
isso fará isso, independentemente de você configurar uma política de solicitação de conexão para encaminhar
mensagens contábeis para um grupo de servidores remotos RADIUS.
Se você quiser que as informações de contabilidade sejam registradas remotamente, mas não localmente, você
deve configurar o NPS local para não executar a contabilidade, enquanto também configura a contabilidade em
uma política de solicitação de conexão para encaminhar dados contábeis para um grupo de servidores remotos
RADIUS.
Manipulação de atributos
Você pode configurar um conjunto de regras de localização e substituição que manipulam as cadeias de
caracteres de texto de um dos atributos a seguir.
Nome do Usuário
ID da estação chamada
ID da estação de chamada
O processamento da regra localizar e substituir ocorre para um dos atributos anteriores antes que a mensagem
RADIUS esteja sujeita às configurações de estatísticas e autenticação. As regras de manipulação de atributos se
aplicam apenas a um único atributo. Você não pode 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.

NOTE
Se você estiver usando o protocolo de autenticação MS-CHAP v2, não poderá manipular o atributo de 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
uma barra invertida ( ) caractere é usada e a manipulação só afeta as informações à esquerda dela. Um caractere de barra
invertida normalmente é usado para indicar um nome de domínio (as informações à esquerda do caractere de barra
invertida) e um nome de conta de usuário dentro do domínio (as informações à direita do caractere de barra invertida).
Nesse caso, somente as regras de manipulação de atributos que modificam ou substituem o nome de domínio são
permitidas.

Para obter exemplos de como manipular o nome de realm no atributo de nome de usuário, consulte a seção
"exemplos de manipulação do nome de realm no atributo de nome de usuário" no tópico usar expressões
regulares no NPS.
Encaminhando a solicitação
Você pode definir as seguintes opções de solicitação de encaminhamento que são usadas para mensagens de
Access-Request RADIUS:
Autenticar solicitações neste ser vidor . Usando essa configuração, o NPS usa um domínio do
Windows NT 4,0, Active Directory ou o banco de dados de contas de usuário do SAM (Gerenciador de
contas de segurança) local para autenticar a solicitação de conexão. Essa configuração também especifica
que a diretiva de rede correspondente configurada no NPS, juntamente com as propriedades de
discagem da conta de usuário, são usadas pelo NPS para autorizar a solicitação de conexão. Nesse caso, o
NPS é configurado para executar como um servidor RADIUS.
Encaminhe solicitações para o seguinte grupo de ser vidores remotos RADIUS . Ao usar essa
configuração, o NPS encaminha as solicitações de conexão para o grupo de servidores remotos RADIUS
que você especificar. Se o NPS receber uma mensagem de Access-Accept válida que corresponde à
mensagem de 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 . Ao usar 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 o acesso não
autenticado e recebe uma solicitação de conexão, o NPS envia imediatamente uma mensagem de Access-
Accept para o cliente RADIUS, e o usuário ou computador recebe acesso à rede. Essa configuração é
usada para alguns tipos de encapsulamento compulsório em que o cliente de acesso é encapsulado antes
de as credenciais do usuário serem autenticadas.

NOTE
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 (autenticação extensível Protocol-Transport segurança de camada), ambos fornecendo autenticação mútua.
Na autenticação mútua, o cliente de acesso comprova que se trata de um cliente de acesso válido para o servidor de
autenticação (o NPS), e o servidor de autenticação comprova que é um servidor de autenticação válido para o cliente de
acesso. Quando essa opção de autenticação é usada, a mensagem de Access-Accept é 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 obter 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 remotos,
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
autenticação ou contabilização RADIUS. Quando há atributos especificados em uma diretiva de rede e na
política de solicitação de conexão, os atributos que são 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 um proxy de autenticação ou
estatísticas RADIUS. Se o atributo já existir na mensagem que é 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 de diretiva de
solicitação de conexão na categoria avançado fornecem funcionalidade especializada. Por exemplo, você pode
configurar o atributo RADIUS remoto para mapeamento de usuário do Windows quando desejar 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 atributo RADIUS remoto para o mapeamento de usuários do Windows especifica que a autorização
do Windows ocorre para usuários que são 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 com 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, usam uma conta de usuário do Windows em sua organização para
acessar uma rede local de convidado (LAN) 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 a implantação de VPN de roteamento e
acesso remoto.
Passpor t-User-Mapping-UPN-sufixo . Esse atributo permite que você autentique solicitações de conexão
com as credenciais da conta de usuário do Windows Live™ ID.
Tunnel-Tag . Esse atributo designa o número de ID de VLAN para o qual a conexão deve ser atribuída pelo
NAS quando você implanta redes locais virtuais (VLANs).
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. Esta 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 remotos.
O atributo não está configurado com regras de manipulação de atributos que encaminham solicitações de
conexão para grupos de servidores remotos RADIUS.
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 o 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
remotos RADIUS. Você pode criar um novo grupo de servidores remotos RADIUS enquanto estiver criando uma
nova política de solicitação de conexão usando o assistente de 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.

NOTE
se o NPS e o serviço de acesso remoto estiverem instalados no mesmo computador e o serviço de acesso remoto estiver
configurado para Windows autenticação e contabilização, é possível que as solicitações de autenticação e contabilização
de acesso remoto sejam encaminhadas para um servidor RADIUS. Isso pode ocorrer quando as solicitações de
autenticação e contabilização de acesso remoto correspondem a uma política de solicitação de conexão configurada para
encaminhá-las a um grupo de servidores remotos RADIUS.
 Nomes de realm
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para obter uma visão geral do uso de nomes de territórios no processamento de
solicitação de conexão do servidor de políticas de rede.
O User-Name atributo RADIUS é 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 realm ou nome
realm, e é sinônimo do conceito de domínio, incluindo domínios DNS, domínios de® 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 de usuário user1@example.com , 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:
Example\user1 . Neste exemplo, o exemplo de nome de realm é um prefixo; e também é o nome de um
domínio de AD DS do 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 AD DS.
Você pode usar nomes de território configurados em políticas de solicitação de conexão ao criar e implantar sua
infraestrutura RADIUS para garantir que as solicitações de conexão sejam roteadas de clientes RADIUS, também
chamadas 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 as 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 de nome de usuário com o nome de realm que será contido no
atributo de 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
remotos RADIUS com base na parte de 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 CM (Gerenciador de conexões) no computador do
usuário é configurado para fornecer o nome do Realm automaticamente.
Você pode designar que os usuários da sua rede forneçam seu nome de realm ao digitar suas credenciais
durante as 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 do realm, em nome de usuário na caixa de diálogo Conexão ao fazer uma conexão dial-up
ou VPN (rede virtual privada).
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 que estão 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 precise
apenas especificar o nome da conta de usuário ao digitar as credenciais. Nessa circunstância, o usuário não
precisa saber ou lembrar o 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 User-Name RADIUS na
mensagem Access-Request que é enviada para o proxy ou servidor RADIUS.
Se o servidor RADIUS for um NPS, a mensagem de 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 que são específicas para o nome do
Realm dentro do 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 atributos

Antes que a mensagem RADIUS seja processada localmente (quando o NPS está sendo usado como um
servidor RADIUS) ou encaminhado 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
atributos. Você pode configurar regras de manipulação de atributos 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 atributos do NPS usam a sintaxe de expressão regular.
Você pode configurar regras de manipulação de atributo para o atributo User-Name para alterar o seguinte:
Remova o nome de realm do nome de usuário ( também conhecido como remoção de realm ) . Por
exemplo, o nome de usuário user1@example.com é alterado para Usuário1.
Altere o nome do Realm, mas não sua sintaxe. Por exemplo, o nome de usuário user1@example.com é
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 é modificado de acordo com as regras de manipulação de atributo que você
define, as configurações adicionais da primeira política de solicitação de conexão correspondente são usadas
para determinar se:
O NPS processa a mensagem de 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 contiver um nome de domínio, o NPS fornecerá 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\ControlProtocols\BuiltIn\DefaultDomain

Cau t i on

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 os 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
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

NOTE
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 solicitações de
conexão.
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
07/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para obter uma visão geral das políticas de rede no NPS.

NOTE
Além deste tópico, a seguinte documentação de política de rede está disponível.
Permissão de acesso
Configurar políticas de rede

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 sob as quais 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 que são configuradas no console do NPS. O NPS
também examina as propriedades de discagem 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 de solicitações de conexão. Se
ocorrer uma correspondência 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 o segundo, e assim por diante,
até que uma correspondência 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.

NOTE
Se desejar que o NPS avalie uma política de rede ao executar a autorização para solicitações de conexão, você deverá
configurar a configuração de 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 o tipo de servidor de acesso à rede (NAS) é
necessário para solicitações de conexão. As propriedades de visão geral também permitem que você especifique
se as propriedades de discagem das contas de usuário no 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 para a conexão. Por exemplo, se você
especificar o endereço IPv4 do NAS como uma condição da diretiva de rede e o NPS receber uma solicitação de
conexão de um NAS que tem o endereço IP especificado, a condição na política corresponderá à 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 correspondida pela solicitação de conexão, o NPS rejeitará automaticamente a
solicitação. Ao contrário da resposta do NPS a condições não correspondentes na diretiva de rede, se uma
restrição não for correspondida, o NPS negará a solicitação de conexão sem avaliar diretivas 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 da política de rede para a política forem correspondidas.
Ao adicionar uma nova política de rede usando o console do NPS, você deve usar o assistente de 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 obter exemplos de sintaxe de correspondência de padrões para especificar atributos de política de rede,
consulte usar expressões regulares no NPS.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Permissões de acesso
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 à solicitação de conexão.
As configurações de permissão de acesso têm o seguinte efeito:
Conceda acesso a . 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.

NOTE
As contas de usuário e suas propriedades, como propriedades discadas, são configuradas no snap-in usuários e grupos
locais do Usuários e Computadores do Active Directory Console de Gerenciamento Microsoft MMC, dependendo se você
tiver 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.

NOTE
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 solicitação de conexão.
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 de 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 do 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, não definindo 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 para desabilitar o processamento de propriedades discadas em outros
cenários, como sem fio ( ) ( 802.1X 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.
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede (NPS).
 Modelos NPS
10/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

(Os modelos NPS do servidor ) de políticas de rede permitem que você crie elementos de configuração, como
serviço RADIUS ( ) clientes 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 ser vidores 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 IP e 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 ser vidores
e clientes RADIUS , abra as propriedades do cliente RADIUS. Em selecionar um modelo de segredos
compar tilhados existente , selecione o modelo que você criou anteriormente na lista de modelos disponíveis.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Clientes RADIUS
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Um nas do 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 contabilização para um servidor RADIUS para autenticação, autorização e contabilidade.

NOTE
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.1 X, servidores VPN de rede privada virtual ( ) e servidores dial-up, pois usam o
protocolo RADIUS para se comunicar com servidores RADIUS, como servidores NPS de 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 clientes RADIUS

Os 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 de acesso remoto de VPN (rede virtual privada) ou dial-up
tradicional para uma intranet da organização.
Pontos de acesso sem fio que fornecem acesso de camada física a uma rede de organização usando
tecnologias de recepção e transmissão baseadas em sem fio.
Opções que fornecem acesso à camada física para a 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 remotos que são configurados no proxy RADIUS.

Mensagens de Access-Request RADIUS

Os clientes RADIUS criam mensagens Access-Request RADIUS e as encaminham para um proxy RADIUS ou
servidor RADIUS, ou encaminham Access-Request mensagens a um servidor RADIUS recebido de outro cliente
RADIUS, mas não foram criadas por conta própria.
Os clientes RADIUS não processam Access-Request mensagens executando autenticação, autorização e
contabilidade. Somente os servidores RADIUS executam essas funções.
No entanto, o NPS pode ser configurado como um proxy RADIUS e um servidor RADIUS simultaneamente, para
que ele processe algumas mensagens de Access-Request 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 gerais de configuração 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 servidor de autenticação. Isso
permite que os servidores de acesso à rede, que criam Access-Request mensagens com base nas
informações recebidas de 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 elas 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 a serem encaminhadas 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 remotos 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

quando você adiciona um cliente RADIUS à configuração do nps por meio do console do nps ou usando os
comandos netsh para comandos do nps ou do Windows PowerShell, você está configurando o NPS para
receber mensagens de Access-Request radius 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 torna mais fácil identificar ao usar o snap-in do NPS ou os
comandos netsh para NPS.
Endereço IP
O endereço IPv4 do protocolo IP versão 4 ( ) ou o ( ) nome DNS do sistema de nome 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 o fornecedor do
cliente.
Segredo compartilhado
Uma cadeia de texto que é usada como uma senha entre clientes RADIUS, servidores RADIUS e proxies RADIUS.
quando o atributo de Authenticator de mensagem é 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 do NPS.
atributo de Authenticator de mensagem
Descrito na RFC 2869, "extensões RADIUS", um hash Message Digest 5 ( MD5 ) de toda a mensagem RADIUS. se
o atributo Authenticator de mensagem RADIUS estiver presente, ele será verificado. Se a verificação falhar, a
mensagem RADIUS será descartada. se as configurações do cliente exigirem a mensagem Authenticator
atributo e não estiver presente, a mensagem RADIUS será descartada. é recomendável usar o atributo de
Authenticator de mensagem.
 NOTE
o atributo de Authenticator de mensagem é necessário e habilitado por padrão quando você usa a autenticação EAP do
protocolo de autenticação extensível ( ) .

Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Planejar Servidor de Políticas de Rede
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico fornece links para informações sobre como planejar implantações de NPS e proxy.

NOTE
Para obter documentação adicional do Servidor de Políticas de Rede, você pode usar as seções de biblioteca a seguir.
Introdução ao Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede
Gerenciar o Servidor de Políticas de Rede

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
13/08/2021 • 18 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Quando você implanta o NPS do servidor de políticas de rede ( ) como um servidor serviço RADIUS (RADIUS), 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 a
implantação do 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 as 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 é membro e para todos os domínios que
confiam no domínio local do NPS. Para permitir que o NPS Leia as propriedades de discagem 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.
Principais etapas
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 portas 1813 e
1646 para mensagens de contabilização 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 um backup. Cada cliente RADIUS é então configurado em
ambos os NPSs. Se o NPS primário ficar indisponível, os clientes RADIUS enviarão Access-Request
mensagens para o NPS alternativo.
Planeje o script usado para copiar uma configuração NPS para outras NPSs para economizar na
sobrecarga administrativa e para evitar o configuração incorreto de um servidor. O NPS fornece os
comandos netsh que permitem copiar toda ou parte de uma configuração NPS para importação em
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 de rede virtual
privada (VPN), comutadores compatíveis com 802.1 X e servidores dial-up. 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 na RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)" e
RFC 2866, "RADIUS Accounting".

IMPORTANT
Clientes de acesso, como computadores cliente, não são clientes RADIUS. Somente os servidores de acesso à rede e os
servidores proxy que dão suporte ao protocolo RADIUS são clientes RADIUS.

Além disso, os pontos de acesso sem fio e os comutadores devem ser compatíveis com a autenticação 802.1 X.
Se você quiser implantar o protocolo ( EAP ) ou ( PEAP ) , os pontos de acesso e os comutadores de autenticação
extensíveis devem oferecer 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 o PEAP, até que você tenha testado aqueles que pretende usar
para acesso à rede.
Principais etapas
Durante o planejamento para clientes RADIUS, você pode usar as etapas a seguir.
Documente os atributos específicos do fornecedor (VSAs) que você deve configurar no NPS. Se os
servidores de acesso à rede exigirem VSAs, registre as informações de VSA para uso posterior ao
configurar as políticas de rede no NPS.
Documente os endereços IP de clientes RADIUS e seu 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 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 também será inserido no
snap-in do 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 em certificado. No entanto, nem todos os
servidores de acesso à rede oferecem suporte aos 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, você pode desejar implantar o acesso sem fio e VPN para sua organização, mas usar 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 segurança de camada de transporte (EAP-TLS) fornece e PEAP-MS-CHAP v2 para conexões sem fio
802.1 X.
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 que é 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 sempre que eles 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
pontos de acesso sem precisar digitar novamente suas credenciais. Devido à reconexão rápida e à segurança
fornecida pelo PEAP-MS-CHAP v2, 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
domésticos ou móveis 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 forte segurança; e eles têm a
desvantagem de serem mais difíceis de implantar do que os métodos de autenticação baseados em senha.
O PEAP-MS-CHAP v2 e o 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 de servidor e requer que você implante uma
infraestrutura de chave pública (PKI) 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 de servidor de uma AC de autoridade de certificação ( ) e o
certificado é salvo no computador local no repositório de certificados. Durante o processo de autenticação, a
autenticação do servidor ocorre quando o NPS envia seu certificado de servidor ao 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 que
o cliente de acesso confia, o NPS será autenticado com êxito pelo cliente.
Da mesma forma, a autenticação de 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 atender aos requisitos mínimos de certificado do cliente e for emitido por uma
autoridade de certificação que o NPS confia, o cliente de acesso será autenticado com êxito pelo NPS.
Embora seja necessário que o certificado do servidor seja armazenado no repositório de certificados no NPS, o
cliente ou o certificado do usuário podem ser armazenados no repositório 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 de sua organização no repositório de certificados das autoridades
confiáveis para o computador local e o usuário atual.
PEAP-MS -CHAP v2
O 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, não é
necessário implantar uma PKI para usar o PEAP-MS-CHAP v2. Ao implantar o PEAP-MS-CHAP v2, você pode
obter um certificado de servidor para o NPS de uma das duas maneiras a seguir:
Você pode instalar Active Directory serviços de certificados (AD CS) e, em seguida, registrar certificados
automaticamente no NPSs. Se você usar esse método, também deverá registrar o certificado de
autoridade de certificação nos computadores cliente que se conectam à sua rede para que eles confiem
no certificado emitido para o NPS.
Você pode comprar um certificado de servidor de uma CA pública, como a VeriSign. Se você usar esse
método, certifique-se de selecionar uma autoridade de certificação que já seja confiável em
computadores cliente. Para determinar se os computadores cliente confiam em uma autoridade de
certificação, abra o snap-in do MMC (console de gerenciamento Microsoft) de certificados em um
computador cliente e, em seguida, exiba o repositório de autoridades de certificação raiz confiáveis para
o computador local e para o usuário atual. Se houver um certificado da autoridade de certificação nesses
repositórios de certificados, o computador cliente confiará na autoridade de certificação e, portanto,
confiará em qualquer certificado emitido pela autoridade de certificação.
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
que o cliente de acesso confia, o NPS será autenticado com êxito pelo cliente.
A autenticação de usuário ocorre quando um usuário tenta se conectar à rede digita credenciais baseadas em
senha e tenta fazer logon. O NPS recebe as credenciais e executa a autenticação e a 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.
Principais etapas
Durante o planejamento para o 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, comutador com
capacidade 802.1 X e acesso dial-up.
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, talvez não seja prático implantar uma PKI, para que outros métodos de
autenticação possam fornecer um equilíbrio melhor 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 de 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 compatível 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. 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
13/08/2021 • 10 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Quando você implanta o NPS (Servidor de Políticas de Rede) como um proxy RADIUS do 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 de 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 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 a 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 solicitação de conexão.
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 contabilidade 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para obter informações sobre como implantar o servidor de políticas de rede.

NOTE
Para obter a documentação adicional do servidor de políticas de rede, você pode usar as seções de biblioteca a seguir.
Introdução ao Servidor de Políticas de Rede
Planejar Servidor de Políticas de Rede
Gerenciar o Servidor de Políticas de Rede

o guia de rede do Windows Server 2016 Core inclui uma seção sobre como planejar e instalar o nps do servidor
de políticas de rede ( ) , e as tecnologias apresentadas no guia servem como pré-requisitos para implantar o
NPS em um domínio de Active Directory. para obter mais informações, consulte a seção "implantar NPS1" no
guia de rededo Windows Server 2016 Core.

Implantar certificados NPS para acesso VPN e 802.1 X

Se você quiser implantar métodos de autenticação como EAP do protocolo de autenticação extensível ( ) e 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 e sem fio 802.1 x.

Implantar NPS para acesso sem fio 802.1 X

Para implantar o NPS para acesso sem fio, você pode usar o guia implantar Password-Based acesso sem fio
autenticado 802.1 x.

implantar o NPS para acesso Windows 10 VPN

Você pode usar o NPS para processar solicitações de conexão para Always On ( conexões VPN da rede virtual
privada ) para funcionários remotos que estão usando computadores e dispositivos que executam o Windows
10.
para obter mais informações, consulte o guia de implantação de VPN Always On acesso remoto para Windows
Server 2016 e Windows 10.
 Gerenciar servidor de políticas de rede (NPS)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar os tópicos desta seção para gerenciar o servidor de políticas de rede.

NOTE
Para obter a documentação adicional do servidor de políticas de rede, você pode usar as seções de biblioteca a seguir.
Introdução ao Servidor de Políticas de Rede
Planejar Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede

Esta seção contém os seguintes tópicos.

Gerenciamento de Servidor de Políticas de Rede com Ferramentas de Administração
Configurar políticas de solicitação de conexão
Configurar firewalls para tráfego RADIUS
Configurar políticas de rede
Configurar a contabilização do Servidor de Políticas de Rede
Configurar clientes RADIUS
Configurar grupos de servidores RADIUS remotos
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
12/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber mais sobre as ferramentas que podem ser usadas para gerenciar seus
NPSs.
Depois de instalar o NPS, você pode administrar NPSs:
Localmente, usando o snap-in nps Console de Gerenciamento Microsoft MMC, o console NPS estático em
Ferramentas Administrativas, Windows PowerShell comandos ou os comandos Netsh do Shell de Rede para
( ) ( ) NPS.
Em um NPS remoto, usando o snap-in do NPS MMC, 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 Conexão de Área de Trabalho Remota em combinação com
outras ferramentas, como o NPS MMC ou Windows PowerShell.

NOTE
No 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 do NPS - MMC.

As seções a seguir fornecem instruções sobre como gerenciar seus NPSs locais e remotos.

Configurar o NPS local usando o console nps

Depois de instalar o NPS, você pode usar esse procedimento para gerenciar o NPS local usando o NPS MMC.
Credenciais administrativas
Para concluir este procedimento, é preciso ser um membro do grupo Administradores.
Para configurar o NPS local usando o console NPS
1. No Gerenciador do Servidor, clique em Ferramentas e, em seguida, clique em Ser vidor de Políticas
de Rede . O console 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, em seguida, faça um dos seguintes 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, em seguida, revise e configure as opções disponíveis com base na funcionalidade NPS
que você deseja – 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 NPS MMC, 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 NPS. Verifique se sua rede está
fisicamente segura e se os usuários mal-intencionados não têm acesso a esse tráfego de rede.
Credenciais administrativas
Para concluir este procedimento, é preciso ser um membro do grupo Administradores.
Para gerenciar vários NPSs usando o snap-in NPS -
1. Para abrir o MMC, execute Windows PowerShell como administrador. No Windows PowerShell, digite mmc e
pressione ENTER. O Console de Gerenciamento Microsoft será aberto.
2. No MMC, no menu Arquivo, clique em Adicionar/Remover Snap - no . A caixa de diálogo Adicionar
ou Remover - Snap-ins é aberta.
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 Computador local o computador no qual este ( ) console está
sendo executado 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 de nome de
domínio totalmente qualificado do NPS remoto que você deseja gerenciar usando o ( ) snap-in - NPS.
Opcionalmente, você pode clicar em Procurar para usar 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 nps para uso posterior, clique em Arquivo e, em seguida, clique em Salvar . Na caixa
de diálogo Salvar como, navegue até o local do disco rígido em que você deseja salvar o arquivo, digite um
nome para o arquivo .msc do Console de Gerenciamento Microsoft e clique em ( ) Salvar .

Gerenciar um NPS usando Conexão de Área de Trabalho Remota

Você pode usar esse procedimento para gerenciar um NPS remoto usando Conexão de Área de Trabalho
Remota.
Usando o Conexão de Área de Trabalho Remota, você pode gerenciar remotamente seus NPSs em execução
Windows Server 2016. Você também pode gerenciar remotamente NPSs de um computador executando
Windows 10 ou sistemas operacionais Windows cliente anteriores.
Você pode usar Área de Trabalho Remota para gerenciar vários NPSs usando um dos dois métodos.
1. Crie uma Área de Trabalho Remota conexão com cada um de seus NPSs individualmente.
2. Use Área de Trabalho Remota para se conectar a um NPS e, em seguida, use o NPS MMC nesse servidor para
gerenciar outros servidores remotos. Para obter mais informações, consulte a seção anterior Manage
Multiple NPSs by Using the NPS MMC Snap - in .
Credenciais administrativas
Para concluir este procedimento, você deve ser um membro do grupo Administradores no NPS.
Para gerenciar um NPS usando Conexão de Área de Trabalho Remota
1. Em cada NPS que você deseja gerenciar remotamente, em Gerenciador do Servidor, selecione Ser vidor
Local . No painel Gerenciador do Servidor detalhes, veja a Área de Trabalho Remota configuração e faça
um dos seguintes.
a. Se o valor da configuração Área de Trabalho Remota for Habilitado, você não precisará executar
algumas das etapas neste procedimento. Pule para a Etapa 4 para iniciar a configuração Área de
Trabalho Remota Permissões de usuário.
b. Se a configuração Área de Trabalho Remota for Desabilitada, clique na palavra Desabilitado. A
caixa de diálogo Propriedades do Sistema é aberta na guia Remoto.
2. No Área de Trabalho Remota , clique em Permitir conexões remotas com este computador. A
Conexão de Área de Trabalho Remota caixa de diálogo é aberta. Execute uma delas.
a. Para personalizar as conexões de rede permitidas, clique Windows Firewall com Segurança
Avançada e, em seguida, de configurar as configurações que você deseja permitir.
b. Para habilitar Conexão de Área de Trabalho Remota todas as conexões de rede no computador, clique
em OK.
3. Em Propriedades do Sistema , Área de Trabalho Remota , decida se deve habilitar Permitir conexões
somente de computadores que executam Área de Trabalho Remota com Autenticação no Nível da Rede e
faça sua seleção.
4. Clique em Selecionar Usuários . A caixa Área de Trabalho Remota caixa de diálogo Usuários é aberta.
5. No Área de Trabalho Remota Usuários , 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 o qual 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 Área de Trabalho
Remota Usuários e OK novamente para fechar a caixa de diálogo Propriedades do Sistema.
7. Para se conectar a um NPS remoto que você configurou usando as etapas anteriores, clique em Iniciar , role
para baixo na lista alfabética e clique em Acessórios Windows e clique em Conexão de Área de Trabalho
Remota . A Conexão de Área de Trabalho Remota caixa de diálogo é aberta.
8. Na caixa Conexão de Área de Trabalho Remota de diálogo, em Computador, digite o nome 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 Conexão 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 netsh NPS 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 netsh NPS 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 Windows.
Exporte a configuração de um NPS (o servidor de origem), incluindo chaves do Registro e o armazenamento
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 Windows Server 2016 ou no Windows PowerShell. Você
também pode executar comandos netsh nps em scripts e arquivos em lotes.
Credenciais administrativas
Para executar esse procedimento, você deve ser membro do grupo Administradores no computador local.
Para inserir o contexto netsh NPS 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íticas
de Rede no Windows Server 2008ou baixe toda a Referência Técnica 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 é Windows Ajuda ( *.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 para gerenciar NPSs. Para obter mais informações, consulte os tópicos
Windows PowerShell referência de comando a seguir.
Cmdlets do NPS (Servidorde Políticas de Rede) no Windows PowerShell . Você pode usar esses comandos
netsh no Windows Server 2012 R2 ou 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 NPS (Servidorde Políticas de
Rede).
 Configurar políticas de solicitação de conexão
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 Remote Authentication Dial-In User Service (RADIUS)
executam a autenticação e a autorização de solicitações de conexão que o servidor que executa o NPS do
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

A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
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 Ser vidor 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 Manage Network Policy Server.
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede (NPS).
 Configurar firewalls para tráfego RADIUS
13/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 estiverem 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 servidor de diretivas
de rede (NPS).
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 1812, 1813, 1645 e 1646 do
protocolo de datagrama do usuário. Windows Defender O firewall no NPS é configurado automaticamente com
exceções, durante a instalação do NPS, para permitir que esse tráfego RADIUS seja enviado e recebido.
portanto, se você estiver usando as portas UDP padrão, não será necessário alterar a configuração Windows
Defender Firewall para permitir o tráfego RADIUS de e para o 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 o tráfego RADIUS em portas que não sejam os
padrões, deverá fazer o seguinte:
Remova as exceções que permitem o tráfego RADIUS nas portas padrão.
Crie novas exceções que permitam o tráfego RADIUS nas novas portas.
Para obter mais informações, consulte Configure NPS UDP Port Information.

Outros firewalls
Na configuração mais comum, o firewall está conectado à Internet e o NPS é um recurso de intranet que está
conectado à rede de perímetro.
Para acessar 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 de IP não está habilitado).
Uma única interface na rede de perímetro. Nessa configuração, o NPS se comunica com os controladores de
domínio por meio de outro firewall que conecta a rede de perímetro à intranet.

Configurando o firewall da Internet

O firewall que está 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 pacotes de entrada e saída separados podem ser configurados na interface da Internet e na interface
de rede de perímetro.
Configurar filtros de entrada na interface de 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 da 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 de porta para 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 contabilização RADIUS de clientes RADIUS baseados na Internet para o NPS.
Essa é a porta UDP padrão usada pelo NPS, conforme definido no RFC 2866. Se você estiver usando uma
porta diferente, substitua esse número de porta para 1813.
()Endereço IP de destino opcional 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.
()Endereço IP de destino opcional da interface de rede de perímetro e porta de destino UDP de 1646 ( 0X66E
) do NPS. Esse filtro permite o tráfego de contabilização 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 de 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 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 de porta para 1812.
Endereço IP de origem da interface de rede de perímetro e porta de origem UDP 1813 (0x715) do NPS. Esse
filtro permite o tráfego de contabilização RADIUS do NPS para clientes RADIUS baseados na Internet. Essa é
a porta UDP padrão usada pelo NPS, conforme definido no RFC 2866. Se você estiver usando uma porta
diferente, substitua esse número de porta para 1813.
()Endereço IP de origem opcional da interface de rede de perímetro e porta de origem UDP 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 usada por clientes RADIUS mais antigos.
()Endereço IP de origem opcional da interface de rede de perímetro e porta de origem UDP 1646 ( 0X66E )
do NPS. Esse filtro permite o tráfego de contabilização RADIUS do NPS para clientes RADIUS baseados na
Internet. Essa é a porta UDP usada por clientes RADIUS mais antigos.
Configurar filtros de entrada na interface de rede de perímetro
Configure os seguintes filtros de entrada na interface de rede de perímetro 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 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 de porta para 1812.
Endereço IP de origem da interface de rede de perímetro e porta de origem UDP 1813 (0x715) do NPS. Esse
filtro permite o tráfego de contabilização RADIUS do NPS para clientes RADIUS baseados na Internet. Essa é
a porta UDP padrão usada pelo NPS, conforme definido no RFC 2866. Se você estiver usando uma porta
diferente, substitua esse número de porta para 1813.
 ()Endereço IP de origem opcional da interface de rede de perímetro e porta de origem UDP 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 usada por clientes RADIUS mais antigos.
()Endereço IP de origem opcional da interface de rede de perímetro e porta de origem UDP 1646 ( 0X66E )
do NPS. Esse filtro permite o tráfego de contabilização RADIUS do NPS para clientes RADIUS baseados na
Internet. Essa é a porta UDP usada por clientes RADIUS mais antigos.
Configurar filtros de saída na interface de rede de perímetro
Configure os seguintes filtros de pacotes de saída na interface de rede de perímetro do firewall para permitir os
seguintes tipos de tráfego:
Endereço IP de destino da 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 de porta para 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 contabilização RADIUS de clientes RADIUS baseados na Internet para o NPS.
Essa é a porta UDP padrão usada pelo NPS, conforme definido no RFC 2866. Se você estiver usando uma
porta diferente, substitua esse número de porta para 1813.
()Endereço IP de destino opcional 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.
()Endereço IP de destino opcional da interface de rede de perímetro e porta de destino UDP de 1646 ( 0X66E
) do NPS. Esse filtro permite o tráfego de contabilização 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 para o tráfego entre o cliente e o endereço IP do NPS na rede de perímetro.
Filtros na interface de rede de perímetro
Configure os seguintes filtros de pacote de entrada na interface de rede de perímetro do firewall da intranet
para permitir os seguintes tipos de tráfego:
Endereço IP de origem da 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 na interface de rede de perímetro do firewall da intranet para permitir os
seguintes tipos de tráfego:
Endereço IP de destino da 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 da 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 pacotes de saída na interface de intranet do firewall para permitir os seguintes
tipos de tráfego:
Endereço IP de origem da interface de rede de perímetro do NPS. Esse filtro permite o tráfego do NPS na
rede de perímetro.
Para obter mais informações sobre como gerenciar o NPS, consulte gerenciar o servidor de políticas de rede.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Configurar políticas de rede
07/08/2021 • 13 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para configurar políticas de rede no NPS.

Adicionar uma política de rede

(O NPS do servidor de políticas de rede ) usa políticas de rede e as propriedades de discagem de contas de
usuário para determinar se uma solicitação de conexão está autorizada a se conectar à rede.
Você pode usar este 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 pela primeira política e, em seguida, movendo a lista de
políticas configuradas. Se o NPS encontrar uma política cujas condições correspondam à solicitação de conexão,
o NPS usará a política de correspondência e as propriedades de discagem da conta de usuário para executar a
autorização. Se as propriedades de discagem da conta de usuário estiverem configuradas para conceder acesso
ou controlar o acesso por meio da diretiva de rede e a solicitação de conexão for autorizada, o NPS aplicará as
configurações definidas na política de rede para a conexão.
Se o NPS não encontrar uma política de rede que corresponda à solicitação de conexão, a solicitação de conexão
será rejeitada, a menos que as propriedades de discagem na conta de usuário estejam definidas para conceder
acesso.
Se as propriedades de discagem da conta de usuário estiverem definidas para negar acesso, a solicitação de
conexão será 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 que você
especifica no método de conexão de rede é usado para configurar automaticamente a condição de tipo de
política :
Se você mantiver 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 diretiva de rede somente se a
solicitação de conexão for proveniente do tipo de servidor de acesso à rede que você especificar.
Na página permissão de acesso , você deve selecionar acesso concedido se desejar 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 de discagem da conta de
usuário no Active Directory ® serviços de domínio ( AD DS ) , você poderá marcar a caixa de seleção o acesso
é determinado pelas propriedades de discagem do usuário .
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
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 de nova política de rede para criar uma política.

Criar políticas de rede para dial-up ou VPN com um assistente

Você pode usar este procedimento para criar políticas de solicitação de conexão e diretivas de rede necessárias
para implantar servidores dial-up ou ( servidores VPN de rede virtual privada ) como serviço RADIUS ( ) clientes
RADIUS para o servidor RADIUS NPS.

NOTE
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.1 X, servidores VPN de rede privada virtual ( ) e servidores dial-up — porque esses
dispositivos usam o protocolo RADIUS para se comunicar com servidores RADIUS, como NPSs.

Este procedimento explica como abrir o novo assistente de conexões de rede virtual privada ou dial-up no NPS.
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
Você pode executar o novo assistente de conexões de rede virtual privada ou dial-up toda vez que precisar criar
novas políticas para servidores de conexão discada e servidores VPN.
A execução do novo assistente de conexões de rede virtual privada ou dial-up não é a única etapa necessária
para implantar servidores VPN ou discadas como clientes RADIUS para o NPS. Os dois métodos de acesso à
rede exigem que você implante componentes de hardware e software adicionais.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para criar políticas para dial-up ou VPN com um assistente
1. Abra o console do NPS. Se ainda não estiver selecionado, clique em NPS ( local ) . Se você quiser criar
políticas em um NPS remoto, selecione o servidor.
2. Em introdução e configuração padrão , selecione ser vidor RADIUS para conexões dial-up ou
VPN . O texto e os links sob o texto são alterados para refletir sua seleção.
3. Clique em Configurar VPN ou dial-up com um assistente . O novo assistente para conexão discada
ou rede virtual privada é 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.1 X 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 que são
necessárias para implantar comutadores de autenticação 802.1 X ou pontos de acesso sem fio 802.1 X como
clientes RADIUS (serviço RADIUS) para o servidor RADIUS NPS.
Este procedimento explica como iniciar o novo assistente de conexões sem fio e com fio IEEE 802.1 X seguro no
NPS.
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
Você pode executar o novo assistente de conexões com fio e sem fio IEEE 802.1 X seguras toda vez que precisar
criar novas políticas para acesso 802.1 X.
A execução do novo assistente de conexões com e sem fio IEEE 802.1 X seguro não é a única etapa necessária
para implantar comutadores de autenticação 802.1 X e pontos de acesso sem fio como clientes RADIUS para o
NPS. Os dois métodos de acesso à rede exigem que você implante componentes de hardware e software
adicionais.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para criar políticas para 802.1 X com ou sem fio com um assistente
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
2. Se ainda não estiver selecionado, clique em NPS ( local ) . Se você quiser criar políticas em um NPS
remoto, selecione o servidor.
3. Em introdução e configuração padrão , selecione ser vidor RADIUS para conexões 802.1 x sem
fio ou com fio . O texto e os links sob o texto são alterados para refletir sua seleção.
4. Clique em Configurar 802.1 x usando um assistente . O novo assistente de conexões com e sem fio
IEEE 802.1 X seguro é aberto.
5. Siga as instruções no Assistente para concluir a criação de suas novas políticas.

Configurar o NPS para ignorar as propriedades de discagem da conta

de usuário
Use este procedimento para configurar uma política de rede NPS para ignorar as propriedades de discagem de
contas de usuário no Active Directory durante o processo de autorização. As contas de usuário no Active
Directory usuários e computadores têm propriedades de discagem 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
para controlar o acesso por meio da política de rede do NPS .
Há duas circunstâncias em que você pode desejar configurar o NPS para ignorar as propriedades de discagem
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 de permissão de acesso à rede definida para controlar o acesso
por meio da política de rede do NPS . Por exemplo, algumas contas de usuário podem ter a
propriedade permissão de acesso à rede da conta de usuário definida para negar acesso ou
permitir acesso .
Quando outras propriedades de discagem de contas de usuário não são aplicáveis ao tipo de conexão
que está 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 dial-in ou VPN, mas a política de rede
que você está criando é para conexões de comutador sem fio ou de autenticação.
Você pode usar este procedimento para configurar o NPS para ignorar as propriedades de discagem da conta
de usuário. Se uma solicitação de conexão corresponder à política de rede em que essa caixa de seleção está
marcada, o NPS não usará as propriedades de discagem 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 requisito mínimo necessário para concluir este
procedimento.
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
2. Clique duas vezes em políticas , em políticas de rede e, 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 de discagem da conta de usuário e clique em OK .
Para configurar o NPS para ignorar as propriedades de discagem da conta de usuário

Configurar NPS para VLANs

ao usar servidores de acesso à rede com reconhecimento de VLAN e NPS no Windows Server 2016, você pode
fornecer grupos de usuários com acesso apenas 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 acesso à rede
da sua organização.
Além disso, as VLANs permitem que você agrupe logicamente os recursos de rede que existem em diferentes
locais físicos ou em sub-redes físicas diferentes. Por exemplo, os membros do seu departamento de vendas e
seus recursos de rede, como computadores cliente, servidores e impressoras, podem estar localizados em
vários prédios diferentes da sua organização, mas você pode posicionar todos esses recursos em uma VLAN
que usa o mesmo intervalo de endereços IP. A VLAN, em seguida, 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 Active
Directory usuários e computadores e, em seguida, adicionar membros aos grupos.
Configurar uma política de rede para VLANs
Você pode usar este procedimento para configurar uma política de rede que atribui usuários a uma VLAN. Ao
usar o hardware de rede com reconhecimento de VLAN, como roteadores, comutadores e controladores de
acesso, você pode configurar a política de rede para instruir os servidores de acesso a inserir membros de
grupos de Active Directory específicos 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 , Tunnel-Pvt-Group-ID , Tunnel-type e Tunnel-Tag .
Esse procedimento é fornecido como uma diretriz; sua configuração de rede pode exigir configurações
diferentes das descritas abaixo.
A associação em Administradores , ou equivalente, é o requisito mínimo necessário para concluir este
procedimento.
Para configurar uma política de rede para VLANs
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
2. Clique duas vezes em políticas , em políticas de rede e, no painel de detalhes, clique duas vezes na
política que você deseja configurar.
3. na caixa de diálogo propriedades da política, clique na guia Configurações .
4. em propriedades da política, em Configurações , em atributos RADIUS , verifique se padrão está
selecionado.
5. No painel de detalhes, em atributos , o atributo Ser vice-Type é configurado com um valor padrão de
Framed . Por padrão, para políticas com métodos de acesso de VPN e dial-up, 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 e adicione os seguintes
atributos:
Tunnel-tipo médio . Selecione um valor apropriado para as seleções anteriores que você fez 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 mídias 802 e formato canônico Ethernet) .
Tunnel-Pvt-Group-ID . Insira o inteiro que representa o número de VLAN ao qual os membros
do grupo serão atribuídos.
tipo de Tunnel . Selecione redes vir tuais (VL AN) .
7. Em Adicionar atributo RADIUS padrão , clique em fechar .
8. se o seu 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 o adicione à política. Se necessário, adicione os atributos da seguinte maneira:
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, em seguida, clique em adicionar . A
caixa de diálogo informações de atributo é aberta.
Em valor do atributo , digite o valor que você obteve da documentação do hardware.

Configurar o tamanho da carga EAP

Em alguns casos, roteadores ou firewalls descartam pacotes porque eles são configurados para descartar
pacotes que exigem fragmentação.
Quando você implanta o NPS com políticas de rede que usam o EAP do protocolo de autenticação extensível ( )
com TLS de segurança de camada de transporte ( ) , ou EAP-TLS, como um método de autenticação, a MTU de
unidade de transmissão máxima padrão ( usada pelo ) NPS para cargas de EAP é de 1500 bytes.
Esse tamanho máximo para a carga 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 pode descartar silenciosamente alguns fragmentos, resultando em falha de
autenticação e a incapacidade do cliente de acesso para se conectar à rede.
Use o procedimento a seguir para reduzir o tamanho máximo que o NPS usa para cargas de EAP, ajustando o
atributo frame-MTU em uma política de rede para um valor não maior que 1344.
A associação em Administradores , ou equivalente, é o requisito mínimo necessário para concluir este
procedimento.
Para configurar o atributo frame -MTU
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
2. Clique duas vezes em políticas , em políticas de rede e, no painel de detalhes, clique duas vezes na
política que você deseja configurar.
3. na caixa de diálogo propriedades da política, clique na guia Configurações .
4. em 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 e clique em frame-MTU e, em seguida, 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 , em fechar e em OK .
Para obter mais informações sobre diretivas de rede, consulte Network Policies.
Para obter exemplos de sintaxe de correspondência de padrões para especificar atributos de política de rede,
consulte usar expressões regulares no NPS.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Configurar a contabilização do Servidor de Políticas
de Rede
13/08/2021 • 11 minutes to read

Há três tipos de registro em log para NPS do 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 Ser ver 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 somente . 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 ao servidor 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 nps SQL log do servidor.
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 do arquivo de texto para que o NPS seja logs
simultaneamente para o arquivo de texto e o SQL Server banco de 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 servidor e
enquanto estiver executando o 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 Console de Gerenciamento Microsoft NPS (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 Remote Authentication Dial-In User
Service (RADIUS) contabilização de 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
1. Abra o console nps ou o snap-in Console de Gerenciamento Microsoft NPS (MMC).
2. Na árvore de console, clique em Contabilidade .
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 ,
verifique se você 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 registro em 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, no 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 ( Herdado ) ODBC ou ( Herdado ) de IAS.
Os tipos de arquivo herdados 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 SQL Server banco de dados. Portanto, o formato
de arquivo compatível 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 Semanal ou 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 em execução Microsoft SQL Server.

NOTE
O NPS formatará os 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 repor t_event no banco de dados SQL Server que possa receber e analisar
os documentos XML do NPS.

A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para configurar o SQL Server registro em log no NPS
1. Abra o console nps ou o snap-in Console de Gerenciamento Microsoft NPS (MMC).
2. Na árvore de console, clique em Contabilidade .
3. No painel de detalhes, em Propriedades SQL Server registro em log, clique em Alterar SQL Ser ver
propriedades de log. A caixa de SQL Ser ver 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 dados, no log SQL Ser ver, 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 ser vidor .
Para especificar o método de autenticação com o qual fazer logoff no servidor, clique em Usar
Windows NT segurança integrada. Ou clique em Usar um nome de usuário e senha específicos
e 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 a qual banco de dados se conectar no computador que executa SQL Server, clique em
Selecionar o banco de dados no servidor e selecione um nome de banco de dados na lista.
7. Para testar a conexão entre NPS e SQL Server, clique em Testar Conexão . Clique em OK para fechar
Propriedades do Link de Dados .
8. Em Ação de falha de registro em log, selecione Habilitar registro em log do arquivo de texto para failover
se quiser que o NPS continue com o registro em log do arquivo de texto se SQL Server registro em log
falhar.
9. Em Ação de falha de registro em log , selecione Se o registro em 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.

Nome de usuário de ping

Alguns servidores proxy RADIUS e servidores de acesso à rede enviam periodicamente solicitações de
autenticação e contabilidade (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 são preenchidos com os registros de rejeição de acesso, dificultando o
controle de registros válidos.
Quando você configura uma entrada do Registro para ping de nome de usuário, o NPS corresponde ao valor de
entrada do Registro em relação ao valor de nome de usuário em solicitações de ping de outros servidores. Uma
entrada de registro ping de nome de usuário 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 ping que corresponderem ao valor de entrada
do registro de nome de usuário ping, o NPS rejeita as solicitações de autenticação sem processar a solicitação.
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.
O nome de usuário ping não está instalado por padrão. Você deve adicionar o nome de usuário ping ao
Registro. Você pode adicionar uma entrada ao Registro usando o Editor do Registro.
Cau t i on

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 o nome de usuário ping ao Registro
O nome de usuário ping pode ser adicionado à seguinte chave do Registro como um valor de cadeia de
caracteres por um membro do grupo Administradores local:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IAS\Parameters

Nome : ping user-name

 Tipo : REG_SZ
Dados : nome de usuário

TIP
Para indicar mais de um nome de usuário para um valor de nome de usuário ping, insira um padrão de nome, como
um nome DNS, incluindo caracteres curinga, em Dados .
 Configurar clientes RADIUS
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para configurar servidores de acesso à rede como clientes RADIUS no NPS.
Ao adicionar um novo servidor VPN do servidor de acesso à rede ( , ponto de acesso sem fio, comutador de
autenticação ou servidor dial-up ) à 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.

IMPORTANT
Os computadores e dispositivos cliente, como computadores laptop, 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 compatíveis com 802.1 X, servidores de rede virtual privada (VPN) e
servidores dial-up, porque eles usam o protocolo RADIUS para se comunicar com servidores RADIUS, como servidores
NPS de servidor de políticas de rede ( ) .

Essa etapa também é necessária quando o NPS é membro de um grupo de servidores RADIUS remotos
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 contenha o NPS.
No NPS remoto, configure o proxy NPS como um cliente RADIUS.
Para executar os procedimentos deste tópico, você deve ter pelo menos um servidor VPN do servidor de acesso
à rede ( , ponto de acesso sem fio, comutador de autenticação ou servidor de conexão discada ) ou proxy do
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
servidores de acesso à rede (NASs) como clientes RADIUS, você deve configurar os clientes para se
comunicarem com o NPSs onde os NASs sã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, em configurações de RADIUS , selecione autenticação RADIUS na porta UDP (User datagram
Protocol) 1812 e contabilização RADIUS na porta UDP 1813 .
2. No ser vidor de autenticação ou ser vidor 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 compar tilhado , digite uma senha forte. Ao configurar o NAS como um cliente
RADIUS no NPS, você usará a mesma senha, portanto, não a esqueça.
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 identificador de
 conjunto de serviços ( SSID ) , que é uma cadeia de caracteres alfanumérica 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 (
hotspots Wi-Fi sem fio de fidelidade ) .
6. Se você estiver configurando um ponto de acesso sem fio, no 802.1 x e no WPA , habilite a autenticação
IEEE 802.1 x se desejar 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 este procedimento para configurar um NAS como um cliente RADIUS usando o console do NPS.
Para concluir este procedimento, é preciso ser um membro do grupo Administradores .
Para adicionar um servidor de acesso à rede como um cliente RADIUS no NPS
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
2. No console do NPS, clique duas vezes em clientes e ser vidores 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 se 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 RADIUS padrão .
6. Em novo cliente RADIUS , em segredo compar tilhado , siga um destes procedimentos:
Verifique se a seleção manual está selecionada e, em segredo compar tilhado , digite a senha forte
que também é inserida no nas. Digite novamente o segredo compartilhado em confirmar segredo
compar tilhado .
Selecione gerar e, em seguida, clique em gerar para gerar automaticamente um segredo
compartilhado. Salve o segredo compartilhado gerado para a 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 qualquer método de
autenticação diferente de EAP e PEAP, e se o seu NAS der suporte ao uso do atributo autenticador de
mensagem, selecione as mensagens de solicitação de acesso devem conter a mensagem
Authenticator atributo .
8. Clique em OK . Seu NAS aparece na lista de clientes RADIUS configurados no NPS.

configurar clientes RADIUS por intervalo de endereços IP em

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 que você adicione um grande número de clientes RADIUS (como pontos
de acesso sem fio) ao console do 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 no
Windows Server 2016 Standard.
Use este procedimento para adicionar um grupo de servidores de acesso à rede (NASs) como clientes RADIUS
que são todos 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 segredo compartilhado.
Para concluir este procedimento, é preciso ser um membro do grupo Administradores .
Para configurar clientes RADIUS por intervalo de endereços IP
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
2. No console do NPS, clique duas vezes em clientes e ser vidores 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 de roteamento Inter-Domain sem classe ) . Por exemplo, se o intervalo de endereços IP para os 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 RADIUS padrão .
6. Em novo cliente RADIUS , em segredo compar tilhado , siga um destes procedimentos:
Verifique se a seleção manual está selecionada e, em segredo compar tilhado , digite a senha forte
que também é inserida no nas. Digite novamente o segredo compartilhado em confirmar segredo
compar tilhado .
Selecione gerar e, em seguida, clique em gerar para gerar automaticamente um segredo
compartilhado. Salve o segredo compartilhado gerado para a 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 qualquer método de
autenticação diferente de EAP e PEAP, e se todos os seus NASs oferecerem suporte ao uso do atributo
autenticador de mensagem, selecione as mensagens de solicitação de acesso devem conter a
mensagem Authenticator atributo .
8. Clique em OK . Seus NASs aparecem na lista de clientes RADIUS configurados no NPS.
Para obter mais informações, consulte clientes RADIUS.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Configurar grupos de servidores RADIUS remotos
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para configurar grupos de servidores remotos RADIUS quando desejar 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 este procedimento para adicionar um novo grupo de servidores remotos RADIUS no snap-in
servidor de diretivas de rede (NPS).
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, o que informa ao NPS para onde enviar as solicitações de conexão que
correspondem à política de solicitação de conexão.

NOTE
Você também pode configurar um novo grupo de servidores remotos RADIUS durante o processo de criação de uma
nova política de solicitação de conexão.

A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
Para adicionar um grupo de servidores RADIUS remotos
1. Em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de políticas de
rede para abrir o console do NPS.
2. Na árvore de console, clique duas vezes em clientes e ser vidores RADIUS , clique com o botão direito do
mouse em grupos de ser vidores RADIUS remotos e clique em novo .
3. A caixa de diálogo novo grupo de ser vidores remotos RADIUS é aberta. Em nome do grupo , digite
um nome para o grupo de servidores remotos RADIUS.
4. Em ser vidores RADIUS , clique em Adicionar . A caixa de diálogo adicionar ser vidores RADIUS é
aberta. Digite o endereço IP do servidor RADIUS que você deseja adicionar ao grupo ou digite o FQDN do
nome de domínio totalmente qualificado ( ) do servidor RADIUS e, em seguida, clique em verificar .
5. Em adicionar ser vidores RADIUS , clique na guia Autenticação/Contabilização . Em segredo
compar tilhado e confirmar segredo compar tilhado , 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 EAP para autenticação, clique em solicitar deve conter o atributo
autenticador de mensagem . O EAP usa o atributo Message-Authenticator por padrão.
7. Verifique se os números de porta de autenticação e contabilização estão corretos para sua implantação.
8. Se você usar um segredo compartilhado diferente para contabilidade, em contabilidade , desmarque a caixa
de seleção usar o mesmo segredo compar tilhado para autenticação e contabilização e, em seguida,
digite o segredo compartilhado de contabilidade em segredo compar tilhado e confirme segredo
 compar tilhado .
9. Se você não quiser encaminhar mensagens de início e parada do servidor de acesso à rede para o servidor
RADIUS remoto, desmarque a caixa de seleção encaminhar notificações do ser vidor de acesso à rede
para este ser vidor .
Para obter mais informações sobre como gerenciar o NPS, consulte gerenciar o servidor de políticas de rede.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Gerenciar certificados usados com NPS
12/08/2021 • 7 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Se você implantar um método de autenticação baseado em certificado, como o protocolo de autenticação

extensível, EAP TLS, segurança de camada de transporte de protocolo de autenticação - ( - ) extensível protegida
- ( PEAP - TLS ) e PEAP - Microsoft Challenge Handshake Authentication Protocol versão 2 ( MS - CHAP v2 ) ,
você deverá registrar um certificado de servidor para todos os seus NPSs. O certificado do servidor deve:
Atenda aos requisitos mínimos de certificado do servidor, conforme descrito em configurar modelos de
certificado para os requisitos de PEAP e EAP
Ser emitido por uma autoridade de certificação ( CA ) confiável para computadores cliente. Uma CA é
confiável quando seu certificado existe no repositório de certificados de autoridades de certificação raiz
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 autoridade de
certificação raiz confiável é uma CA de terceiros, como a Verisign, ou é uma AC que você implantou para sua PKI
de infraestrutura de chave pública ( ) usando Active Directory serviços de certificados ( AD CS ) .

Alterar a expiração do identificador TLS em cache

Durante os processos de autenticação inicial 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 que está se conectando. 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 identificador TLS.
Os computadores cliente podem armazenar em cache os identificadores TLS para vários autenticadores,
enquanto NPSs pode armazenar em cache os identificadores TLS de vários computadores cliente.
Os identificadores TLS em cache no cliente e no servidor permitem que o processo de reautenticação ocorra
com mais rapidez. Por exemplo, quando um computador sem fio é reautenticado com um NPS, o NPS pode
examinar o identificador TLS do 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.
De forma correspondente, o cliente examina o identificador TLS do NPS, determina se 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 identificador TLS padrão
é de 10 horas.
Em algumas circunstâncias, talvez você queira aumentar ou diminuir o tempo de expiração do identificador TLS.
Por exemplo, talvez você queira diminuir o tempo de expiração do identificador 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 identificador TLS em cache que não tenha expirado.
Reduzir a expiração do identificador TLS pode ajudar a impedir que esses usuários com certificados revogados
se reconectem.
 NOTE
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 de Active Directory que recebe permissão para se conectar à rede na diretiva de rede. No entanto, a propagação
dessas alterações para todos os controladores de domínio também pode ser atrasada, devido à latência de replicação.

Configurar o tempo de expiração do identificador TLS em

computadores cliente
Você pode usar este procedimento para alterar a quantidade de tempo em que os computadores cliente
armazenam em cache o identificador 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 identificador TLS. O
identificador TLS tem uma duração padrão de 10 horas ( 36 milhões milissegundos ) . Você pode aumentar ou
diminuir o tempo de expiração do identificador TLS usando o procedimento a seguir.
A associação em Administradores , ou equivalente, é o requisito mínimo necessário para concluir este
procedimento.

IMPORTANT
Esse procedimento deve ser executado em um NPS, não em um computador cliente.

Para configurar o tempo de expiração do identificador TLS em computadores cliente

1. Em um NPS, abra o editor do registro.
2. Navegue até a chave do registro HKEY _ local _
MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL
3. No menu Editar , clique em novo e em chave .
4. Digite ClientCacheTime e pressione Enter.
5. Clique com o botão direito do mouse em ClientCacheTime , clique em novo e em valor DWORD (32
bits) .
6. Digite a quantidade de tempo, em milissegundos, que você deseja que os computadores cliente
armazenem 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 identificador TLS em NPSs

Use este procedimento para alterar a quantidade de tempo que o NPSs armazena em cache o identificador TLS
de computadores cliente. Depois de autenticar com êxito um cliente de acesso, NPSs cache as propriedades de
conexão TLS do computador cliente como um identificador TLS. O identificador TLS tem uma duração padrão de
10 horas ( 36 milhões milissegundos ) . Você pode aumentar ou diminuir o tempo de expiração do identificador
TLS usando o procedimento a seguir.
A associação em Administradores , ou equivalente, é o requisito mínimo necessário para concluir este
procedimento.

IMPORTANT
Esse procedimento deve ser executado em um NPS, não em um computador cliente.
Para configurar o tempo de expiração do identificador TLS em NPSs
1. Em um NPS, abra o editor do registro.
2. Navegue até a chave do registro HKEY _ local _
MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL
3. No menu Editar , clique em novo e em chave .
4. Digite Ser verCacheTime e pressione Enter.
5. Clique com o botão direito do mouse em Ser verCacheTime , clique em novo e em valor DWORD (32
bits) .
6. Digite o período de tempo, em milissegundos, que você deseja que o NPSs armazene 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 autoridade de certificação

raiz confiável
Use este procedimento para obter o hash de SHA-1 (algoritmo de hash seguro) 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 autoridade de certificação 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 de certificados do MMC (console de gerenciamento Microsoft).
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 autoridade de certificação raiz confiável
1. na caixa de diálogo executar ou Windows PowerShell, digite mmc e pressione ENTER. O MMC do console
de gerenciamento Microsoft ( ) é aberto. No MMC, clique em arquivo e, em seguida, clique em
Adicionar/remover Snap\in . A caixa de diálogo Adicionar ou Remover Snap-ins é aberta.
2. Em Adicionar ou Remover Snap-ins , em Snap-ins disponíveis , clique duas vezes em Cer tificados .
O assistente de snap-in de certificados é aberto. Clique em Conta de computador e em Avançar .
3. Em Selecionar computador , verifique se o computador local (o computador no qual este
console está sendo executado) está selecionado, clique em concluir e em OK .
4. No painel esquerdo, clique duas vezes em cer tificados (computador local) e, em seguida, clique duas
vezes na pasta autoridades de cer tificação raiz confiáveis .
5. A pasta cer tificados é uma subpasta da pasta autoridades de cer tificação raiz confiáveis . Clique
na pasta Cer tificados .
6. No painel de detalhes, navegue até o certificado de sua AC raiz confiável. Clique duas vezes no
certificado. A caixa de diálogo Cer tificado é aberta.
7. Na caixa de diálogo Cer tificado , clique na guia Detalhes .
8. Na lista de campos, role para 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, em seguida, pressione o atalho de teclado Windows para o comando de cópia (
CTRL + C ) para copiar o hash para a área de transferência de Windows.
10. abra o local no qual você deseja colar o hash SHA-1, localize corretamente o cursor e, em seguida,
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.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Configurar modelos de certificado para requisitos
de PEAP e EAP
12/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Todos os certificados que são usados para autenticação de acesso à rede com - segurança de camada de
transporte ( EAP TLS, segurança de protocolo de autenticação - ) extensível protegidas - ( PEAP - TLS ) e PEAP -
Microsoft Challenge Handshake Authentication Protocol versão 2 ( MS - CHAP v2 ) devem atender aos
requisitos para certificados X. 509 e trabalhar para conexões que usam SSL/TLS (camada de soquete
seguro/segurança em nível de transporte). Os certificados de cliente e de servidor têm requisitos adicionais.

IMPORTANT
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 de infraestrutura de chave pública ( ) com Active Directory serviços de certificados ( AD
CS ) .

Requisitos mínimos de certificado do servidor

Com o PEAP - MS - CHAP v2, PEAP - TLS ou EAP - TLS como o método de autenticação, o NPS deve usar um
certificado de servidor que atenda aos requisitos mínimos de certificado do servidor.
Os computadores cliente podem ser configurados para validar certificados de servidor usando a opção validar
cer tificado do ser vidor no computador cliente ou no 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 entidade contém um valor. Se você emitir um certificado para o servidor que executa o NPS
(servidor de diretivas de rede) que tem um nome de entidade em branco, o certificado não estará
disponível para autenticar o NPS. Para configurar o modelo de certificado com um nome de entidade:
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 entidade e, em seguida, clique em criar com base nessa Active
Director y informações .
4. Em formato de nome da entidade , selecione um valor diferente de nenhum .
O certificado do computador no servidor se encadeia a uma AC (autoridade de certificação) raiz confiável
e não falha em nenhuma das verificações executadas pelo CryptoAPI e que são especificadas na política
de acesso remoto ou na diretiva de rede.
O certificado de computador para o servidor NPS ou VPN é configurado com a finalidade de
autenticação de servidor em extensões 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:
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 criptografia e certifique-se de configurar o seguinte:
Categoria do provedor : provedor de Armazenamento de chave
Nome do algoritmo: RSA
Provedores: Provedor Microsoft Platform crypto
Tamanho mínimo da chave: 2048
Algoritmo de hash: SHA2
4. Clique em Próximo .
A extensão de nome alternativo da entidade (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:
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 entidade e, em seguida, clique em criar com base nessa Active
Director y informações .
4. Em incluir essas informações em nome de entidade alternativo , selecione nome DNS .
Ao usar PEAP e EAP-TLS, o NPSs exibirá uma lista de todos os certificados instalados no repositório de
certificados do computador, com as seguintes exceções:
Os certificados que não contêm a finalidade de autenticação de servidor em extensões EKU não são
exibidos.
Os certificados que não contêm um nome de entidade não são exibidos.
Os certificados de logon e de cartão inteligente com base no registro não são exibidos.
Para obter mais informações, consulte implantar certificados de servidor para implantações com e sem fio
802.1 x.

Requisitos mínimos de certificado do cliente

Com EAP-TLS ou PEAP-TLS, o servidor aceita a tentativa de autenticação de cliente quando o certificado atende
aos seguintes requisitos:
O certificado do cliente é emitido por uma autoridade de certificação corporativa ou mapeado para uma
conta de usuário ou computador no Active Directory Domain Services ( AD DS ) .
O certificado de usuário ou computador no cliente encadeia a uma AC raiz confiável, inclui a finalidade de
autenticação de cliente em extensões EKU ( o identificador de objeto para autenticação de cliente é
1.3.6.1.5.5.7.3.2 ) e não faz a falha das verificações executadas pelo CryptoAPI e especificadas na política
de acesso remoto ou política de rede nem nas verificações de identificador de objeto de certificado
especificadas na política de rede do NPS.
O cliente 802.1 X não usa certificados baseados no registro que sejam certificados de logon de cartão
inteligente ou protegidos por senha.
Para certificados de usuário, a extensão SubjectAltName do nome alternativo da entidade ( ) no
certificado contém o UPN do nome principal do usuário ( ) . Para configurar o UPN em um modelo de
certificado:
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 entidade e, em seguida, clique em criar com base nessa Active
Director y informações .
4. Em incluir essas informações em nome de entidade alternativo , selecione ( UPN ) nome da
entidade de usuário .
Para certificados de computador, a extensão SubjectAltName do nome alternativo ( ) da entidade no
certificado deve conter o FQDN do nome de domínio totalmente qualificado ( ) do cliente, que também é
chamado de nome DNS . Para configurar esse nome no modelo de certificado:
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 entidade e, em seguida, clique em criar com base nessa Active
Director y informações .
4. Em incluir essas informações em nome de entidade alternativo , selecione nome DNS .
Com - o PEAP TLS e o EAP - TLS, os clientes exibem uma lista de todos os certificados instalados no snap-in de
certificados, com as seguintes exceções:
Os clientes sem fio não exibem certificados baseados no registro e de logon de cartão inteligente.
Clientes sem fio e clientes VPN não exibem certificados protegidos por senha.
Os certificados que não contêm a finalidade de autenticação de cliente em extensões EKU não são
exibidos.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Gerenciar NPSs
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar os tópicos nesta seção para gerenciar NPSs.

NOTE
Para obter documentação adicional do Servidor de Políticas de Rede, você pode usar as seções de biblioteca a seguir.
Introdução ao Servidor de Políticas de Rede
Implantar o Servidor de Políticas de Rede

Esta seção contém os seguintes tópicos.

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
Instalar o NPS (Servidor de Políticas de Rede)
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
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 diretivas de rede), você
pode configurar o seguinte:
Os adaptadores de rede que fazem e não enviam e recebem serviço RADIUS ( ) tráfego RADIUS.
Em uma base de adaptador por rede, se o NPS monitora o tráfego RADIUS no protocolo IP versão 4 ( IPv4 ) ,
IPv6 ou IPv4 e IPv6.
Os números de porta UDP sobre os 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 o
tráfego RADIUS, você só precisa especificar os adaptadores de rede que deseja que o NPS use para o tráfego
RADIUS quando desejar impedir que o NPS utilize um adaptador de rede específico.

NOTE
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.

Em um NPS com vários adaptadores de rede instalados, talvez você queira configurar o NPS para enviar e
receber o tráfego RADIUS somente nos adaptadores que você especificar.
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 ao NPS um caminho de rede para seus
clientes RADIUS configurados. Nesse cenário, é importante direcionar o NPS a 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 dois dos
adaptadores para o tráfego RADIUS, você poderá configurar informações de porta somente para os dois
adaptadores. Ao excluir a configuração de porta para o terceiro adaptador, você impede que o NPS use o
adaptador para o 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íticas 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 sobre o 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 contabilização.
Sintaxe de tráfego IPv6: [IPv6Address]: UDPport, em que os colchetes em aproximadamente IPv6Address são
necessários, IPv6Address é o endereço IPv6 configurado no adaptador de rede sobre o 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 contabilização.
Os caracteres a seguir podem ser usados como delimitadores para configurar as informações de endereço IP e
porta UDP:
Delimitador de endereço/porta: dois-pontos (:)
Delimitador de porta: vírgula (,)
Delimitador de interface: ponto e vírgula (;)

Configurando servidores de acesso à rede

Verifique se os servidores de acesso à rede estão configurados com os mesmos números de porta UDP RADIUS
que você configura em seu 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
contabilização.

IMPORTANT
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.

Configurar o NPS de hospedagem múltipla

Você pode usar o procedimento a seguir para configurar o NPS de hospedagem múltipla.
A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.
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 ferramentas e, em seguida, clique em ser vidor de políticas de
rede para abrir o console do NPS.
2. Clique com o botão direito do mouse em ser vidor de políticas de rede e clique em Propriedades .
3. Clique na guia por tas e preceda 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 de porta de
1812, 1645 para 192.168.1.2:1812, 1645 . Se a autenticação RADIUS e as portas UDP de
contabilização RADIUS forem diferentes dos valores padrão, altere as configurações de porta
adequadamente.
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 as portas UDP do NPS, consulte configurar informações de porta do NPS
UDP
Para obter mais informações sobre o NPS, consulte servidor de políticas de rede
 Configurar informações da porta UDP do NPS
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar o procedimento a seguir para configurar as portas que o servidor de diretivas de rede (NPS) usa
para serviço RADIUS ( ) tráfego de estatísticas e autenticação RADIUS.
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.

NOTE
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
pelo Internet Engineering Task Force ( IETF ) 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.

A associação no Admins. do Domínio ou equivalente é o requisito mínimo exigido para concluir este
procedimento.

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 ser vidor de políticas de rede e clique em Propriedades .
3. Clique na guia por tas 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 de políticas de rede.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Desabilitar o encaminhamento de notificação do
NAS no NPS
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este procedimento para desabilitar o encaminhamento de mensagens de início e de parada de
servidores de acesso à rede (NASs) 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, desmarque a caixa de seleção encaminhar solicitações de contabilidade para este grupo
de ser vidores remotos RADIUS , esses grupos ainda serão enviados nas 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
do NAS para servidores individuais em cada grupo de servidores RADIUS remotos.
Para concluir este procedimento, é preciso ser um membro do grupo Administradores .
Para desabilitar o encaminhamento de notificação do NAS
1. No Gerenciador do Servidor, clique em Ferramentas e, em seguida, clique em Ser vidor de Políticas
de Rede . O console do NPS é aberto.
2. No console do NPS, clique duas vezes em clientes e ser vidores RADIUS , clique em grupos de
ser vidores RADIUS remotos e clique duas vezes no grupo de servidores remotos RADIUS que você
deseja configurar. A caixa de diálogo Propriedades do grupo de servidores remotos RADIUS é aberta.
3. Clique duas vezes no membro do grupo que você deseja configurar e, em seguida, clique na guia
Autenticação/Contabilização .
4. Em contabilidade , desmarque a caixa de seleção encaminhar o ser vidor de acesso à rede iniciar e
parar notificações neste ser vidor e clique em OK .
5. Repita as etapas 3 e 4 para todos os membros do grupo que você deseja configurar.
Para obter mais informações sobre como gerenciar o NPS, consulte gerenciar o servidor de políticas de rede.
Para obter mais informações sobre o NPS, consulte servidor de diretivas de rede (NPS).
 Exportar uma configuração do NPS para
importação em outro servidor
07/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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
usar Windows PowerShell.
No Windows Server 2008 R2 e Windows Server 2008, use Netsh.

IMPORTANT
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.

NOTE
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.

Export-NpsConfiguration -Path <filename>

A tabela a seguir lista parâmetros para o cmdlet Expor t-NpsConfiguration no Windows PowerShell.
Parâmetros em negrito são necessários.
 PA RÂ M ET RO DESC RIÇ Ã O

Caminho Especifica o nome e o local do arquivo XML para o qual você

deseja exportar a configuração do NPS.

Credenciais administrativas
Para concluir este procedimento, é preciso ser um membro do grupo Administradores.
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.

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.

Import-NpsConfiguration [-Path] <String> [ <CommonParameters>]

Exemplo de importação
O comando a seguir importa as 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.

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
expor t.
Quando o comando netsh nps impor t é 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 impor t, 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.

NOTE
Ao usar o comando netsh nps expor t, você precisa fornecer o parâmetro de comando expor tPSK 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.

Credenciais administrativas
Para concluir este procedimento, é preciso ser um membro do grupo Administradores.
Para copiar uma configuração do NPS para outro NPS usando comandos Netsh
1. No NPS de origem, abra 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" expor tPSK=YES , em que path é o local
da pasta em que você deseja salvar o arquivo de configuração 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 impor t filename= "path\file.xml" e
pressione Enter. Uma mensagem é exibida indicando se a importação do arquivo XML foi bem-sucedida.

Referências adicionais
Shell de Rede (Netsh)
 Aumentar autenticações simultâneas processadas
pelo NPS
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 do 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 fazer isso, você deve editar a seguinte chave do Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Adicione um novo valor chamado MaxConcurrentApi e atribua a ele um valor de 2 a 5.

Cau t i on

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 como gerenciar o NPS, consulte Manage Network Policy Server.
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede (NPS).
 Instalar o NPS (Servidor de Políticas de Rede)
13/08/2021 • 2 minutes to read

você pode usar este tópico para instalar o servidor de diretivas de rede (NPS) 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.

NOTE
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 e IPv4
do protocolo ip versão 6 ) . se os servidores de acesso à rede estiverem configurados para enviar tráfego RADIUS por
portas diferentes desses padrões, remova as exceções criadas em Windows Firewall 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 .

Para instalar o NPS usando Windows PowerShell

para executar esse procedimento usando Windows PowerShell, execute Windows PowerShell como
administrador, digite o comando a seguir e pressione ENTER.
Install-WindowsFeature NPAS -IncludeManagementTools

Para instalar o NPS usando Gerenciador do Servidor

1. No NPS1, 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 .

NOTE
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 ser vidor de destino , verifique se Selecionar um ser vidor no pool de ser vidores
está marcada. Em Pool de Ser vidores , verifique se o computador local está selecionado. Clique em
Próximo .
5. em selecionar funções de ser vidor , em funções , selecione política de rede e Ser viços do
Access . uma caixa de diálogo será aberta perguntando se ele deve adicionar recursos necessários para a
política de rede e Serviços do Access. Clique em Adicionar recursos e em Avançar
6. Em Selecionar recursos , clique em Avançar e, em Ser viços de Acesso e Política de Rede , analise
as informações fornecidas e clique em Avançar .
7. Em Selecionar ser viços de função , clique em Ser vidor de Políticas de Rede . Em Adicionar
recursos que são necessários para Ser vidor de Políticas de Rede , clique em Adicionar
Recursos . Clique em Próximo .
8. Em Confirmar seleções de instalação , clique em Reiniciar cada ser vidor 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 "a instalação foi bem-sucedida em ComputerName" será exibida,
em que ComputerName é o nome do computador no qual você instalou o servidor de políticas de rede.
Clique em Fechar .
Para obter mais informações, consulte Manage NPSs.
 Balanceamento de carga do servidor proxy NPS
07/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Remote Authentication Dial-In User Service (RADIUS), que são servidores de acesso à rede, como servidores
vpn (rede virtual privada) e pontos de acesso sem fio, criam solicitações de conexão e as enviam para servidores
RADIUS, como NPS. Em alguns casos, um NPS pode receber muitas solicitações de conexão ao mesmo tempo,
resultando em desempenho degradado ou sobrecarga. Quando um NPS está sobrecarregado, é uma boa ideia
adicionar mais NPSs à sua rede e configurar o balanceamento de carga. Quando você distribui solicitações de
conexão de entrada de maneira equilibrada entre vários NPSs para evitar a sobrecarga de um ou mais NPSs, ele
é chamado de balanceamento de carga.
O balanceamento de carga é particularmente útil para:
Organizações que usam a Autenticação Extensível Protocol-Transport ( EAP-TLS ou TLS de Protocolo de
Autenticação Extensível Protegido ) ( PEAP ) -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 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.
ISPs de provedores de serviços ( de Internet ) que terceirizam o acesso à VPN para outras organizações. Os
serviços VPN terceirizados podem gerar um grande volume de tráfego de autenticação.
Há dois métodos que você pode usar para equilibrar a carga de solicitações de conexão enviadas ao 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 organizações pequenas 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, 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 de maneira
equilibrada as solicitações de conexão entre os três servidores RADIUS. Esse método de balanceamento de
carga é melhor para organizações médias e grandes que têm muitos clientes e servidores RADIUS.
Em muitos casos, a melhor abordagem para 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 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 de 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 remoto. Ao adicionar membros do grupo ou
depois de criar um servidor RADIUS como membro de grupo, você pode acessar a caixa de diálogo Adicionar
servidor RADIUS para configurar os seguintes itens na guia Balanceamento de Carga:
Prioridade . Priority especifica a ordem de importância do servidor RADIUS para o servidor proxy NPS.
O nível de prioridade deve ser atribuído a um valor que seja um inteiro, como 1, 2 ou 3. Quanto menor o
número, maior a prioridade que o proxy NPS dá ao servidor RADIUS. Por exemplo, se o servidor RADIUS
tiver a prioridade mais alta de 1, o proxy NPS enviará solicitações de conexão ao servidor RADIUS
primeiro; se os servidores com prioridade 1 não estão disponíveis, o NPS envia 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 Peso para balancear a carga entre eles.
Peso . O NPS usa essa configuração peso para determinar quantas solicitações de conexão enviar para
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 RADIUS remoto contiver dois membros que têm um nível de
prioridade de 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 não está disponível. Se o NPS determinar que um servidor
RADIUS não está disponível, ele poderá começar a enviar solicitações de conexão a outros membros do
grupo. Com essas configurações, você pode definir o número de segundos que o proxy NPS espera por
uma resposta do servidor RADIUS antes de considerar a solicitação retirada; o número máximo de
solicitações descartados antes que o proxy NPS identifique o servidor RADIUS como indisponível; e o
número de segundos que podem transcorr entre solicitações antes que o proxy NPS identifique o
servidor RADIUS como indisponível.

Configurar o balanceamento de carga do proxy 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 Prioridade e Peso para cada servidor.

NOTE
As etapas a seguir pressuem 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 tomar as seguintes ações:
1. Implante seus servidores VPN de clientes RADIUS, servidores discados, servidores de Gateway de
Serviços de Terminal, comutadores de autenticação 802.1X e pontos de acesso sem fio ( 802.1X 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 RADIUS remotos.
4. No proxy NPS, para cada servidor RADIUS que você adicionar a um grupo de servidores RADIUS remoto,
clique na guia Balanceamento de Carga do servidor RADIUS e, em seguida, configure As configurações
Prioridade, Peso e Avançado .
5. No proxy NPS, configure políticas de solicitação de conexão para encaminhar solicitações de autenticação
e contabilidade para grupos de servidores RADIUS remotos. Você deve criar uma política de solicitação
de conexão por grupo de servidores RADIUS remoto. 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
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

você pode usar este tópico para registrar um servidor que executa o servidor de diretivas de rede no 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 este procedimento para registrar um NPS no domínio em que o servidor é membro do
domínio.
NPSs deve ser registrado em Active Directory para que eles tenham permissão para ler as propriedades de
discagem de contas de usuário durante o processo de autorização. O registro de um NPS adiciona o servidor ao
grupo de Ser vidores RAS e ias em Active Directory.
A associação a Administradores ou equivalente é o requisito mínimo para a execução destes procedimentos.
Para registrar um NPS em seu domínio padrão
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do servidor de diretivas de rede é aberto.
2. Clique com o botão direito do mouse em NPS (local) e, em seguida, clique em registrar ser vidor em
Active Director y . A caixa de diálogo Ser vidor de Políticas de Rede é aberta.
3. Em Ser vidor de Políticas de Rede , clique em OK e em OK novamente.

Registrar um NPS em outro domínio

Para fornecer um NPS com permissão para ler as propriedades de discagem de contas de usuário no Active
Directory, o NPS deve ser registrado no domínio em que as contas residem.
Você pode usar este procedimento para registrar um NPS em um domínio em que o NPS não é membro do
domínio.
A associação a Administradores ou equivalente é o requisito mínimo para a execução destes procedimentos.
Para registrar um NPS em outro domínio
1. No controlador de domínio, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique
em Active Director y usuários e computadores . 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 Ser vidores RAS e ias e clique em
Propriedades . A caixa de diálogo Propriedades de ser vidores RAS e ias é aberta.
4. Na caixa de diálogo Propriedades de ser vidores RAS e ias , clique na guia Membros , adicione cada
NPSs que você 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 registeredser ver domínio Server e
pressione Enter.

NOTE
No comando anterior, Domain é o nome de domínio DNS do domínio em que você deseja registrar o NPS e Server é o
nome do computador NPS.
 Cancelar o registro de um NPS de um domínio do
Active Directory
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

No processo de gerenciamento da implantação do NPS, você pode achar útil mover um NPS para outro
domínio, substituir um NPS ou para retirar um NPS.
Ao mover ou descompactar um NPS, você pode fazer o registro do NPS nos domínios do Active Directory em
que o NPS tem permissão para ler as propriedades das contas de usuário no Active Directory.
A associação a Administradores ou equivalente é o requisito mínimo para a execução destes procedimentos.

Para não fazer o registro de um NPS

1. No controlador de domínio, no Gerenciador do Servidor, clique em Ferramentas e, em seguida, clique
Usuários e Computadores do Active Director y . O console de Usuários e Computadores do Active
Directory é aberto.
2. Clique em Usuários e clique duas vezes em SERVIDORES RAS e IAS.
3. Clique na guia Membros e, em seguida, selecione o NPS que você deseja excluir do registro.
4. Clique em Remover , clique em Sim e em OK.
 Use expressões regulares no NPS
12/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016

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.

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 estão entre barras (/).

C A RA C T ERE DESC RIÇ Ã O EXEM P LO

\ Indica que o caractere a seguir é um /n/ matches the character "n"

caractere especial ou deve ser while the sequence /\n/ matches
a line feed or newline
interpretado literalmente. character.

^ Corresponde ao início da entrada ou

linha.

$ Corresponde ao final da entrada ou

linha.

* Corresponde ao caractere anterior zero /zo*/ matches either "z" or

ou mais vezes. "zoo."

+ Corresponde ao caractere anterior /zo+/ matches "zoo" but not "z."

uma ou mais vezes.

? Corresponde ao caractere anterior zero /a?ve?/ matches the "ve" in

ou uma vez. "never."

. Corresponde a qualquer caractere

único, exceto um caractere de nova
linha.

(pattern) Corresponde a "padrão" e se lembra da

corresponder.
Para corresponder aos caracteres (
literais ) e (parênteses), use \( ou
\) .

x | y Corresponde a x ou y.

{n} Corresponde exatamente n vezes ( n é /o{2}/ does not match the "o" in
um inteiro não negativo - ) . "Bob," but matches the first two
instances of the letter o in
"foooood."
C A RA C T ERE DESC RIÇ Ã O EXEM P LO

{n,} Corresponde a pelo menos n vezes ( n
é um inteiro não negativo - ) .
/o{2,}/ does not match the "o"
in "Bob" but matches all of the
instances of the letter o in
"foooood." /o{1,}/ is equivalent
to /o+/.

{n,m} Corresponde a pelo menos n e, no /o{1,3}/ matches the first three

máximo, m vezes ( m e n são - inteiros instances of the letter o in
"fooooood."
não ) negativos.

[xyz] Corresponde a qualquer um dos /[abc]/ matches the "a" in

caracteres incluídos um ( conjunto de "plain."
caracteres ) .

[^xyz] Corresponde a todos os caracteres que /[^abc]/ matches the "p" in

não estão incluídos ( em um conjunto "plain."
de caracteres ) negativos.

\b Corresponde a um limite de ( palavra, /ea*r\b/ matches the "er" in

por exemplo, um espaço ) . "never early."

\B Corresponde a um limite não de /ea*r\B/ matches the "ear" in

palavra. "never early."

\d Corresponde a um caractere ( de dígito

equivalente a dígitos de 0 a 9 ) .

\D Corresponde a um caractere nãodigit (

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,
tabulação 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
tabulação.

\v Corresponde a um caractere de
tabulação vertical.
 C A RA C T ERE DESC RIÇ Ã O EXEM P LO

\w Corresponde a qualquer caractere de

palavra, incluindo sublinhado (
equivalente a [A-Za-z0-9_] ) .

\W Corresponde a qualquer caractere -

que não seja de palavra, excluindo o
sublinhado equivalente a (
[^A-Za-z0-9_] ) .

\num Refere-se a corresponde a ( ?num \1 substitui o que é armazenado na

lembradas , em que num é um inteiro primeira combinação lembrada.
positivo ) . Essa opção só pode ser
usada na caixa de texto Substituir ao
configurar a manipulação de atributo.

/n/ Permite a inserção de códigos ASCII

em expressões regulares, em que n é
um valor de ( ?n escape octal,
hexadecimal ou ) decimal.

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
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 par te do realm do atributo Nome de Usuário
Em um cenário de discagem terceirizada no qual um ISP do provedor de serviços de Internet roteia solicitações
de conexão para um NPS da organização, o proxy RADIUS do ISP pode exigir um nome de realm para rotear a
solicitação de ( ) autenticação. No entanto, o NPS pode não reconhecer a parte do nome de 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 mensagem RADIUS por um servidor

proxy
Você pode criar regras de roteamento que encaminham mensagens RADIUS com um nome de realm
especificado para um conjunto de servidores RADIUS quando o NPS é usado como um proxy RADIUS. A seguir
está uma sintaxe recomendada para roteamento de solicitações com base no nome do realm.
Nome netBIOS: WCOAST
Padrão: ^wcoast\\
No exemplo a seguir, wcoast.microsoft.com é um sufixo UPN (nome upn) 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 sufixo UPN.
Nome netBIOS: WCOAST
Sufixo UPN: wcoast.microsoft.com
Padrão: ^wcoast\\|@wcoast\.microsoft\.com$
Para obter mais informações sobre como gerenciar o NPS, consulte Manage Network Policy Server.
Para obter mais informações sobre o NPS, consulte Servidor de Políticas de Rede (NPS).
 Verificar a configuração após alterações do NPS
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para verificar a configuração do NPS após uma alteração de nome ou endereço IP
para o servidor.

Verificar a configuração após uma alteração de endereço IP 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 NPS ou endereço IP de proxy, será necessário reconfigurar partes da 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 de acesso à rede, autorização ou contabilidade em sua rede para servidores NPS RADIUS e
servidores proxy RADIUS.
Você deve ser um membro de Administradores ou equivalente, para executar esses procedimentos.
Para verificar a configuração após uma alteração de endereço IP 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 remoto, reconfigure o proxy NPS com o novo
endereço IP do NPS.
3. Se você tiver configurado o NPS para usar SQL Server log, verifique se a conectividade entre o
computador que está executando SQL Server e o NPS ainda está funcionando corretamente.
4. Se você implantou 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 Firewall do
Windows com Segurança Avançada para usar o novo endereço IP do NPS.
5. Se o NPS for multihomed e você tiver configurado o servidor para se vincular a um adaptador de rede
específico, reconfigure as configurações de porta NPS com o novo endereço IP.
Para verificar a configuração após uma alteração de endereço IP do 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 multihomed e você tiver configurado o proxy para se vincular a um adaptador de
rede específico, reconfigure as configurações de porta NPS com o novo endereço IP.
3. Reconfigure todos os membros de todos os grupos de servidores RADIUS remotos com o endereço IP do
servidor proxy. Para realizar essa tarefa, em cada NPS que tenha 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 RADIUS e, em seguida, no painel de detalhes, clique duas vezes no cliente RADIUS que você
deseja alterar.
b. Em Propriedades do cliente RADIUS , em IP de endereço ou ( DNS ) , digite o novo endereço IP do
 proxy NPS.
4. Se você tiver configurado o proxy NPS para usar o log SQL Server, verifique se a conectividade entre o
computador que está executando SQL Server e o proxy NPS ainda está funcionando corretamente.

Verificar a configuração depois de renomear um NPS

Pode haver circunstâncias em que você precisa alterar o nome de um NPS ou proxy, como quando você
redesenha as convenções de nomentura para seus servidores.
Se você alterar um NPS ou um nome de proxy, será necessário reconfigurar partes da 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 contabilidade de acesso à rede.
Você deve ser um membro de Administradores ou equivalente, para executar este procedimento.
Para verificar a configuração após uma alteração de nome nps ou proxy
1. Se o NPS for membro de um grupo de servidores RADIUS remoto e o grupo estiver configurado com
nomes de computador em vez de endereços IP, reconfigure o grupo de servidores RADIUS remoto com o
novo nome NPS.
2. Se os métodos de autenticação baseados em certificado são implantados no NPS, a alteração de nome
invalida o certificado do servidor. Você pode solicitar um novo certificado do administrador da AC
(autoridade de certificação) ou, se o computador for um computador membro do domínio e você o
registro automático de certificados para membros do domínio, você poderá atualizar o 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 AC 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 pode ser diferente dependendo da expiração da CRL (Lista de Certificados
Revogados) e da expiração do tempo de cache de TLS (Transport Layer Security) dos padrões. A expiração
da CRL padrão é de uma semana; a expiração de tempo de cache TLS padrão é de 10 horas.
No entanto, se você quiser configurar o NPS para usar o novo certificado imediatamente, poderá
reconfigurar manualmente as políticas de rede com o novo certificado.
4. Depois que o certificado antigo expirar, o NPS começará automaticamente a usar o novo certificado.
5. Se você tiver configurado o NPS para usar SQL Server log, verifique se a conectividade entre o
computador que está executando SQL Server e o NPS ainda está funcionando corretamente.
 Coleta de dados de usuário do Servidor de Política
de Rede
07/08/2021 • 2 minutes to read

Este documento explica como encontrar informações do usuário coletadas pelo NPS (Servidor de Políticas de
Rede) caso você gostaria de removê-los.

NOTE
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
Data/hora do evento
Nome de Usuário
Nome de usuário qualificado completo
Endereço IP do Cliente
Fornecedor do cliente
Nome amigável do cliente
Tipo de autenticação
Vários outros campos referentes ao protocolo RADIUS

Coletar dados do NPS

Se os dados de contabilidade estão habilitados e configurados, os registros das tentativas de autenticação NPS
de um usuário podem ser obtidos do SQL Server ou dos arquivos de log, dependendo da configuração.
Se os dados de contabilidade estão configurados para SQL Server, consulte todos os registros WHERE
User_Name = '<username>' .
Se os dados de contabilidade estão configurados para um arquivo de log, pesquise o arquivo de log para
<username> encontrar todas as entradas de log.

A Política de Rede e Serviços do Access de log de eventos são consideradas duplicativas para os dados de
contabilidade e não precisam ser coletadas.
Se os dados de contabilidade não estão habilitados, os registros das tentativas de autenticação NPS de um
usuário podem ser obtidos da Política de Rede e Serviços do Access log de eventos pesquisando o <username> .
 Gerenciar modelos do NPS
12/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar ( modelos NPS do servidor ) de políticas de rede para criar elementos de configuração, como
serviço RADIUS ( ) clientes 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, no qual você pode criar, modificar, excluir,
duplicar e exibir o uso de modelos de NPS. 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 compar tilhados . Esse tipo de modelo possibilita que você especifique um segredo
compartilhado que pode ser reutilizado (selecionando o modelo no local apropriado no console do NPS)
ao configurar clientes e servidores RADIUS.
Clientes RADIUS . Esse tipo de modelo possibilita que você defina as configurações do cliente RADIUS
que podem ser reutilizadas selecionando o modelo no local apropriado no console do NPS.
Ser vidores RADIUS remotos . Esse modelo possibilita que você defina as configurações do servidor
RADIUS remoto que você pode reutilizar selecionando o modelo no local apropriado no console do NPS.
Filtros de IP . Esse modelo possibilita que você crie filtros IPv6 (protocolo IP versão 4) e protocolo IP
versão 6 ( ) que podem ser reutilizados ( , selecionando o modelo no local apropriado no console do NPS
) quando você configura as políticas de rede.

Criar um modelo de NPS

Configurar um modelo é diferente de configurar diretamente o NPS. A criação de um modelo não afeta a
funcionalidade do NPS. Ele é apenas quando você seleciona o modelo no local apropriado no console do NPS e
aplica o modelo que o modelo afeta a funcionalidade do NPS.
Por exemplo, se você configurar um cliente RADIUS no console do NPS em clientes e ser vidores RADIUS ,
altere a configuração do NPS e execute uma etapa para configurar o NPS para se comunicar com um dos seus
servidores de acesso à rede. (A próxima etapa é configurar o nas do servidor de acesso à rede ( ) 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 ser vidores RADIUS , você criou um
modelo, mas ainda não alterou a funcionalidade do 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.
A associação em Administradores , ou equivalente, é o requisito mínimo necessário para concluir este
procedimento.
Para criar um modelo de NPS
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
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 Propriedades do modelo é aberta e você pode usar o para configurar o
modelo.

Aplicar um modelo de 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.
A associação em Administradores , ou equivalente, é o requisito mínimo necessário para concluir este
procedimento.
Para aplicar um modelo de NPS
1. No NPS, em Gerenciador do Servidor, clique em ferramentas e, em seguida, clique em ser vidor de
políticas de rede . O console do NPS é aberto.
2. No console do NPS, expanda clientes e ser vidores RADIUS e 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 de NPS e clique em Propriedades .
4. Na caixa de diálogo Propriedades do cliente RADIUS, em selecionar um modelo de segredos
compar tilhados existente , selecione o modelo que você deseja aplicar na lista de modelos.

Exportar ou importar modelos de NPS

Você pode exportar modelos para uso em outros NPSs, ou você pode importar modelos para o
Gerenciamento de modelos para uso no computador local.
A associação em Administradores , ou equivalente, é o requisito mínimo necessário para concluir este
procedimento.
Para exportar ou importar modelos de NPS
1. Para exportar modelos de NPS, no console do NPS, clique com o botão direito do mouse em
Gerenciamento de modelos e clique em expor tar modelos para um arquivo .
2. Para importar modelos de NPS, no console do NPS, clique com o botão direito do mouse em
Gerenciamento de modelos e clique em impor tar modelos de um computador ou impor tar
modelos de um arquivo .
 Netsh (Shell de Rede)
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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 clientes, como o cliente (DHCP) e o BranchCache, também fornecem comandos netsh
que permitem configurar computadores cliente que executam o 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 Microsoft) para cada função de servidor de rede ou recurso de
rede. Por exemplo, você pode configurar o NPS (Servidor de Políticas de Rede) usando o snap-in do MMC do
NPS ou os comandos netsh no contexto do netsh nps .
Além disso, há comandos netsh para tecnologias de rede, como 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.

IMPORTANT
Recomendamos usar o Windows PowerShell para gerenciar as tecnologias de rede no Windows Server e Windows 10 em
vez de no Shell de Rede. No entanto, o Shell de Rede é incluído para oferecer compatibilidade com seus scripts e há
suporte para o uso dele.

Referência Técnica do Netsh (Shell de Rede)

A Referência Técnica do Netsh fornece uma referência de comando netsh abrangente, incluindo sintaxe,
parâmetros e exemplos para comandos netsh. Use a Referência Técnica do Netsh para criar scripts e arquivos
em lotes usando comandos netsh para gerenciamento local ou remoto de tecnologias de rede em
computadores que executam o Windows Server e o Windows 10.
Disponibilidade do conteúdo
A Referência Técnica do Shell de Rede está disponível para download no formato (*.chm) da Ajuda do Windows
na Galeria do TechNet: Referência Técnica do Netsh
 Sintaxe, Contextos e Formatação do Comando
Netsh
13/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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) da 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 do netsh,
digite o nome do contexto e digite /? ou help . Por exemplo, para exibir uma lista de subcontextos e comandos
que podem ser usados no contexto de roteiros, no prompt do 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" star tupquer yinter val=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 para interpretar e usar a sintaxe de comando netsh correta quando
você executa o comando no prompt do 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.
O texto seguido por um reticências (...) é um parâmetro que pode ser repetido várias vezes em uma linha de
comando.
O texto entre colchetes [ ] é um item opcional.
O 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 de comando Netsh.exe (ou seja, netsh> ).
Sintaxe
netsh [ -a AliasFile] [ -c Context ] [ -r RemoteComputer] [ -u [ DomainName\ ] UserName ] [ -p Password | *]
[{NetshCommand | -f ScriptFile}]
Par âm et r o s

-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.

IMPORTANT
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 estiver 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 -u UserName.
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.

 NOTE
Se você especificar -r seguido por outro comando, netsh executará o comando no computador remoto e voltará para
o prompt de comando Cmd.exe. Se você especificar -r sem outro comando, o netsh 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 netsh 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)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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 o (WINS) (Serviço de Nome da Internet do Windows) em arquivos de
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 exemplo de arquivo em lotes, 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 o WINS-B como um parceiro de replicação push/pull do WINS-A
Conecta-se ao WINS-B e, em seguida, define o WINS-A como um parceiro de replicação push/pull do WINS-
B
Inicia uma replicação push do WINS-A para o WINS-B
Conecta-se ao WINS-B para verificar se o novo registro, MEU_REGISTRO, 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.
ser ver . Desloca o contexto atual da linha de-comando do WINS para o servidor especificado pelo seu nome
ou endereço IP.
add name . Registra um nome no servidor WINS.
add par tner . 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.

Referências adicionais
Shell de Rede (Netsh)
 Comandos Netsh http
13/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Use netsh http para consultar e definir configurações e parâmetros de HTTP.sys.

TIP
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

add iplisten [ ipaddress= ] IPAddress

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

ipaddress O endereço IPv4 ou IPv6 a ser Necessária

adicionado à 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.

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

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

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

ippor t 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.

cer thash Especifica o hash de SHA do Necessária

certificado. 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.

cer tstorename Especifica o nome do repositório para Opcional

o certificado. O padrão é MY. O
certificado deve ser armazenado no
contexto do computador local.
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

verifyclientcer trevocation Especifica a verificação de Opcional

Ativada/desativada de revogação de
certificados de cliente.

verifyrevocationwithcachedclientc Especifica se o uso somente do Opcional

er tonly 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.

clientcer tnegotiation 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 sslcer t .
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
 add timeout [ timeouttype= ] IdleConnectionTimeout | HeaderWaitTimeout [ value=] U-Short

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

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

add urlacl [ url= ] URL [ [user=] User [ [ listen= ] yes | no [ delegate= ] yes | no ] | [ sddl= ] SDDL ]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

url Especifica a URL (Uniform Resource Necessária

Locator) totalmente qualificada.

user Especifica o nome do usuário ou do Necessária

grupo de usuários

listen Especifica um dos seguintes valores: Opcional

sim: permitir que o usuário registre
URLs. Este é o valor padrão. não: negar
que o usuário registre URLs.

delegate Especifica um dos seguintes valores: Opcional

sim: permitir que o usuário delegue
URLs não: negar que o usuário
delegue URLs. Este é o valor padrão.

sddl Especifica uma cadeia de caracteres Opcional

SDDL que descreve a DACL.

Exemplos
A seguir, estão quatro exemplos do comando add urlacl .
 add urlacl url=https://+:80/MyUri user=DOMAIN\ user
add urlacl url=https://www.contoso.com:80/MyUri user=DOMAIN\user listen=yes
add urlacl url=https://www.contoso.com:80/MyUri user=DOMAIN\user delegate=no
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

delete cache [ [ url= ] URL [ [recursive= ] yes | no ]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

url Especifica a URL (Uniform Resource Opcional

Locator) totalmente qualificada que
você deseja excluir.

recursive Especifica se todas as entradas no Opcional

cache de URL são removidas. Sim :
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

delete iplisten [ ipaddress= ] IPAddress

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

ipaddress O endereço IPv4 ou IPv6 a ser excluído Necessária

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. "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

delete sslcert [ ipport= ] IPAddress:port

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

ippor t Especifica o endereço IPv4 ou IPv6 e a Necessária

porta para a qual as associações 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 sslcer t .
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
 delete timeout [ timeouttype= ] idleconnectiontimeout | headerwaittimeout

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

timeouttype Especifica o tipo de configuração de Necessária

tempo limite.

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

delete urlacl [ url= ] URL

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

url Especifica a URL (Uniform Resource Necessária

Locator) totalmente qualificada 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

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

show cachestate [ [url= ] URL]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

url Especifica a URL totalmente qualificada Opcional

que você deseja exibir. Se não 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

show iplisten

show servicestate
Exibe um instantâneo do serviço HTTP.
Sintaxe

show servicestate [ [ view= ] session | requestq ] [ [ verbose= ] yes | no ]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

Exibir Especifica se um instantâneo do estado Opcional

do serviço HTTP deve ser exibido com
base na sessão do servidor ou nas filas
de solicitação.

Verbose Especifica se é devem ser exibidas Opcional

informações detalhadas que também
mostram informações de propriedade.
Exemplos
A seguir, estão dois exemplos do comando show ser vicestate .
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

show sslcert [ ipport= ] IPAddress:port

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

ippor t Especifica o endereço IPv4 ou IPv6 e a Necessária

porta para a qual as associações 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 sslcer t .
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

show timeout

show urlacl
Exibe DACLs (listas de controle de acesso discricional) para a URL reservada especificada ou todas as URLs
reservadas.
Sintaxe
 show urlacl [ [url= ] URL]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

url Especifica a URL totalmente qualificada Opcional

que você deseja exibir. Se não 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
12/08/2021 • 10 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Use os comandos netsh interface por tproxy 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.
Mensagens de computador e aplicativo configuradas para IPv4 enviadas para computadores e aplicativos
configurados para IPv6.
Mensagens de computador e aplicativo configuradas para IPv6 enviadas para computadores e aplicativos
configurados para IPv4.
Mensagens de computador e aplicativo configuradas para IPv6 enviadas para 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 por tproxy . 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:

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
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

add v4tov4 listenport= {Integer | ServiceName} [[connectaddress=] {IPv4Address | HostName}] [[connectport=]

{Integer | ServiceName}] [[listenaddress=] {IPv4Address | HostName}] [[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t 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.

connectpor t Especifica a porta IPv4, por número da porta ou nome do

serviço, à qual se conectar. Se connectpor t não for
especificado, o padrão será o valor de listenpor t no
computador local.

listenaddress Especifica o endereço IPv4 para o 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.

protocol Especifica o protocolo a ser usado.

add v4tov6
O servidor portproxy escuta mensagens enviadas a uma porta e um endereço IPv4 específicos e mapeia uma
porta e um endereço IPv6 para enviar as mensagens recebidas após estabelecer uma conexão TCP separada.
Sintaxe

add v4tov6 listenport= {Integer | ServiceName} [[connectaddress=] {IPv6Address | HostName} [[connectport=]

{Integer | ServiceName}] [[listenaddress=] {IPv4Address | HostName} [[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O
 PA RÂ M ET RO DESC RIÇ Ã O

listenpor t Especifica a porta IPv4, por número da porta ou nome do

serviço, na qual escutar.

connectaddress Especifica o endereço IPv6 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.

connectpor t Especifica a porta IPv6, por número da porta ou nome do

serviço, à qual se conectar. Se connectpor t não for
especificado, o padrão será o valor de listenpor t no
computador local.

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.

protocol Especifica o protocolo a ser usado.

add v6tov4
O servidor portproxy escuta mensagens enviadas a uma porta e um endereço IPv6 específicos e mapeia uma
porta e um endereço IPv4 para os quais enviar as mensagens recebidas após estabelecer uma conexão TCP
separada.
Sintaxe

add v6tov4 listenport= {Integer | ServiceName} [[connectaddress=] {IPv4Address | HostName} [[connectport=]

{Integer | ServiceName}] [[listenaddress=] {IPv6Address | HostName} [[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t Especifica a porta IPv6, 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.

connectpor t Especifica a porta IPv4, por número da porta ou nome do

serviço, à qual se conectar. Se connectpor t não for
especificado, o padrão será o valor de listenpor t no
computador local.

listenaddress Especifica o endereço IPv6 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.

protocol Especifica o protocolo a ser usado.

add v6tov6
O servidor portproxy escuta mensagens enviadas a uma porta e um endereço IPv6 específicos e mapeia uma
porta e um endereço IPv6 para os quais enviar as mensagens recebidas após estabelecer uma conexão TCP
separada.
Sintaxe

add v6tov6 listenport= {Integer | ServiceName} [[connectaddress=] {IPv6Address | HostName} [[connectport=]

{Integer | ServiceName}] [[listenaddress=] {IPv6Address | HostName} [[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t Especifica a porta IPv6, por número da porta ou nome do

serviço, na qual escutar.

connectaddress Especifica o endereço IPv6 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.

connectpor t Especifica a porta IPv6, por número da porta ou nome do

serviço, à qual se conectar. Se connectpor t não for
especificado, o padrão será o valor de listenpor t no
computador local.

listenaddress Especifica o endereço IPv6 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.

protocol Especifica o protocolo a ser usado.

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

delete v4tov4 listenport= {Integer | ServiceName} [[listenaddress=] {IPv4Address | HostName}

[[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t 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.

protocol Especifica o protocolo a ser usado.

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

delete v4tov6 listenport= {Integer | ServiceName} [[listenaddress=] {IPv4Address | HostName}

[[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t 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.

protocol Especifica o protocolo a ser usado.

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

delete v6tov4 listenport= {Integer | ServiceName} [[listenaddress=] {IPv6Address | HostName}

[[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t Especifica a porta IPv6 a ser excluída.

listenaddress Especifica o endereço IPv6 a ser excluído. Se um endereço

não for especificado, o padrão é o computador local.

protocol Especifica o protocolo a ser usado.

delete v6tov6
O servidor portproxy exclui um endereço IPv6 da lista de endereços IPv6 para os quais o servidor escuta.
Sintaxe

delete v6tov6 listenport= {Integer | ServiceName} [[listenaddress=] {IPv6Address | HostName}

[[protocol=]tcp]

Parâmetros
 PA RÂ M ET RO DESC RIÇ Ã O

listenpor t Especifica a porta IPv6 a ser excluída.

listenaddress Especifica o endereço IPv6 a ser excluído. Se um endereço

não for especificado, o padrão é o computador local.

protocol Especifica o protocolo a ser usado.

reset
Redefine o estado de configuração do IPv6.
Sintaxe
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

set v4tov4 listenport= {Integer | ServiceName} [[connectaddress=] {IPv4Address | HostName} [[connectport=]

{Integer | ServiceName}] [[listenaddress=] {IPv4Address | HostName} [[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t 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.

connectpor t Especifica a porta IPv4, por número da porta ou nome do

serviço, à qual se conectar. Se connectpor t não for
especificado, o padrão será o valor de listenpor t no
computador local.

listenaddress Especifica o endereço IPv4 para o 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.

protocol Especifica o protocolo a ser usado.

set v4tov6
Modifica os valores de parâmetro de uma entrada existente no servidor portproxy criado com o comando add
v4tov6 ou adiciona uma nova entrada à lista que mapeia os pares porta/endereço.
Sintaxe
 set v4tov6 listenport= {Integer | ServiceName} [[connectaddress=] {IPv6Address | HostName} [[connectport=]
{Integer | ServiceName}] [[listenaddress=] {IPv4Address | HostName} [[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t Especifica a porta IPv4, por número da porta ou nome do

serviço, na qual escutar.

connectaddress Especifica o endereço IPv6 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.

connectpor t Especifica a porta IPv6, por número da porta ou nome do

serviço, à qual se conectar. Se connectpor t não for
especificado, o padrão será o valor de listenpor t no
computador local.

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.

protocol Especifica o protocolo a ser usado.

set v6tov4
Modifica os valores de parâmetro de uma entrada existente no servidor portproxy criado com o comando add
v6tov4 ou adiciona uma nova entrada à lista que mapeia os pares porta/endereço.
Sintaxe

set v6tov4 listenport= {Integer | ServiceName} [[connectaddress=] {IPv4Address | HostName} [[connectport=]

{Integer | ServiceName}] [[listenaddress=] {IPv6Address | HostName} [[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t Especifica a porta IPv6, 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.

connectpor t Especifica a porta IPv4, por número da porta ou nome do

serviço, à qual se conectar. Se connectpor t não for
especificado, o padrão será o valor de listenpor t no
computador local.
 PA RÂ M ET RO DESC RIÇ Ã O

listenaddress Especifica o endereço IPv6 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.

protocol Especifica o protocolo a ser usado.

set v6tov6
Modifica os valores de parâmetro de uma entrada existente no servidor portproxy criado com o comando add
v6tov6 ou adiciona uma nova entrada à lista que mapeia os pares porta/endereço.
Sintaxe

set v6tov6 listenport= {Integer | ServiceName} [[connectaddress=] {IPv6Address | HostName} [[connectport=]

{Integer | ServiceName}] [[listenaddress=] {IPv6Address | HostName} [[protocol=]tcp]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O

listenpor t Especifica a porta IPv6, por número da porta ou nome do

serviço, na qual escutar.

connectaddress Especifica o endereço IPv6 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.

connectpor t Especifica a porta IPv6, por número da porta ou nome do

serviço, à qual se conectar. Se connectpor t não for
especificado, o padrão será o valor de listenpor t no
computador local.

listenaddress Especifica o endereço IPv6 no qual escutar. Os valores

aceitáveis são endereço 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.

protocol Especifica o protocolo a ser usado.

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
Exibe os parâmetros v4tov6 portproxy.
Sintaxe
show v4tov6

show v6tov4
Exibe os parâmetros v6tov4 portproxy.
Sintaxe
show v6tov4

show v6tov6
Exibe os parâmetros v6tov6 portproxy.
Sintaxe
show v6tov6
 Comandos netsh mbn
13/08/2021 • 13 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Use o netsh mbn para consultar e definir configurações e parâmetros de banda larga móvel.

TIP
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

add dmprofile [interface=]<string> [name=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

name Nome do arquivo XML do perfil. É o Necessária

nome do arquivo XML que contém os
dados do perfil.

Exemplo

add dmprofile interface="Cellular" name="Profile1.xml"

perfil
Adiciona um perfil de rede ao Armazenamento de Dados do Perfil.
Sintaxe

add profile [interface=]<string> [name=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

name Nome do arquivo XML do perfil. É o Necessária

nome do arquivo XML que contém os
dados do perfil.

Exemplo

add profile interface="Cellular" name="Profile1.xml"

connect
Conecta-se a uma rede de Banda Larga Móvel.
Sintaxe

connect [interface=]<string> [connmode=]tmp|name [name=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

connmode Especifica como os parâmetros de Necessária

conexão estão sendo fornecidos.
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

name Nome do arquivo XML do perfil. É o Necessária

nome do arquivo XML que contém os
dados do perfil.

Exemplos

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

delete dmprofile [interface=]<string> [name=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

name Nome do arquivo XML do perfil. É o Necessária

nome do arquivo XML que contém os
dados do perfil.

Exemplo

delete dmprofile interface="Cellular" name="myProfileName"

perfil
Exclui um perfil de rede do Armazenamento de Dados de Perfil.
Sintaxe

delete profile [interface=]<string> [name=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

name Nome do arquivo XML do perfil. É o Necessária

nome do arquivo XML que contém os
dados do perfil.

Exemplo

delete profile interface="Cellular" name="myProfileName"

diagnose
Executa o diagnóstico para problemas básicos de celular.
Sintaxe

diagnose [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

diagnose interface="Cellular"

desconectar
Desconecta-se de uma rede de Banda Larga Móvel.
Sintaxe

disconnect [interface=]<string>

Parâmetros
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

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

dump

ajuda
Exibe uma lista de comandos.
Sintaxe

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

set acstate [interface=]<string> [state=]autooff|autoon|manualoff|manualon

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

name O estado de conexão automática a ser Necessária

definido. Um dos seguintes 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

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

set dataenablement [interface=]<string> [profileset=]internet|mms|all [mode=]yes|no

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

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

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
 set dataroamcontrol [interface=]<string> [profileset=]internet|mms|all [state=]none|partner|all

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

profileset Nome do conjunto de perfis. Necessária

mode Um dos seguintes valores: Necessária

none: somente operadora residencial.
partner: somente operadoras
residencial e de parceiro.
all: operadoras domésticas, parceiras e
de roaming.

Exemplo

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

set enterpriseapnparams [interface=]<string> [allowusercontrol=]yes|no|nc [allowuserview=]yes|no|nc

[profileaction=]add|delete|modify|nc

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

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.

allowuser view Um dos seguintes valores: Necessária

yes: permite ao usuário visualizar
enterpriseAPN.
no: não permite ao usuário visualizar
enterpriseAPN.
nc: sem alteração.
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

profileaction Um dos seguintes valores: Necessária

add: um perfil enterpriseAPN é
adicionado.
delete: um perfil enterpriseAPN é
excluído.
modify: um perfil enterpriseAPN é
modificado.
nc: sem alteração.

Exemplo

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 interface fornecida.
Sintaxe

set highestconncategory [interface=]<string> [highestcc=]admim|user|operator|device

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

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

set highestconncategory interface="Cellular" highestcc=operator

powerstate
Ativa ou desativa o rádio de Banda Larga Móvel para a interface fornecida.
Sintaxe

set powerstate [interface=]<string> [state=]on|off

Parâmetros
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

state Um dos seguintes valores: Necessária

on: ligar o transceptor de rádio.
off: desligar o transceptor de rádio.

Exemplo

set powerstate interface="Cellular" state=on

profileparameter
Definir parâmetros em um Perfil de Rede de Banda Larga Móvel.
Sintaxe

set profileparameter [name=]<string> [[interface=]<string>] [[cost]=default|unrestricted|fixed|variable]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

name Nome do perfil a ser modificado. Se a Necessária

interface for especificada, somente o
perfil nessa interface será modificado.

interface Nome da interface. É um dos nomes Opcional

de interface mostrados pelo comando
"netsh mbn show interfaces".

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

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

set slotmapping [interface=]<string> [slotindex=]<integer>

Parâmetros
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

slotindex Índice do slot a ser definido. Necessária

Exemplo

set slotmapping interface="Cellular" slotindex=1

tracing
Habilitar ou desabilitar o rastreamento.
Sintaxe

set tracing [mode=]yes|no

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

mode Um dos seguintes valores: Necessária

yes: habilita o rastreamento para
Banda Larga Móvel.
não: desabilita o rastreamento para
Banda Larga Móvel.

Exemplo

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 interface fornecida.
Sintaxe

show acstate [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show acstate interface="Cellular"

capability
Mostra as informações de capacidade da interface para a interface fornecida.
Sintaxe

show capability [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo
 show capability interface="Cellular"

connection
Mostra as informações de conexão atuais para a interface fornecida.
Sintaxe

show connection [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show connection interface="Cellular"

dataenablement
Mostra o estado de habilitação de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe

show dataenablement [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show dataenablement interface="Cellular"

dataroamcontrol
Mostra o estado de controle de roaming de dados de Banda Larga Móvel para a interface fornecida.
Sintaxe

show dataroamcontrol [interface=]<string>

Parâmetros
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show dataroamcontrol interface="Cellular"

dmprofiles
Mostra uma lista de perfis de Configuração de DM configurados no sistema.
Sintaxe

show dmprofiles [[name=]<string>] [[interface=]<string>]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

name Nome do perfil a ser exibido. Opcional

interface Nome da interface. É um dos nomes Opcional

de interface mostrados pelo comando
"netsh mbn show interfaces".

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

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

show enterpriseapnparams [interface=]<string>

Parâmetros
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show enterpriseapnparams interface="Cellular"

highestconncategory
Mostra a categoria de conexão mais alta de Dados de Banda Larga Móvel para a interface fornecida.
Sintaxe

show highestconncategory [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show highestconncategory interface="Cellular"

homeprovider
Mostra as informações do provedor de residencial para a interface fornecida.
Sintaxe

show homeprovider [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

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
 show interfaces

netlteattachinfo
Mostra as informações de anexação LTE de rede de Banda Larga Móvel para a interface fornecida.
Sintaxe

show netlteattachinfo [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show netlteattachinfo interface="Cellular"

pin
Mostra as informações de marcador para a interface fornecida.
Sintaxe

show pin [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show pin interface="Cellular"

pinlist
Mostra as informações de lista de marcadores para a interface fornecida.
Sintaxe

show pinlist [interface=]<string>

Parâmetros
 PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show pinlist interface="Cellular"

preferredproviders
Mostra a lista de provedores preferenciais para a interface fornecida.
Sintaxe

show preferredproviders [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show preferredproviders interface="Cellular"

profiles
Mostra uma lista de perfis configurados no sistema.
Sintaxe

show profiles [[name=]<string>] [[interface=]<string>] [[purpose=]<string>]

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

name Nome do perfil a ser exibido. Opcional

interface Nome da interface. É um dos nomes Opcional

de interface mostrados pelo comando
"netsh mbn show interfaces".

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

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

show profilestate [interface=]<string> [name=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

name Nome do perfil. É o nome do perfil que Necessária

tem o estado a ser mostrado.

Exemplo

show profilestate interface="Cellular" name="myProfileName"

provisionedcontexts
Mostra as informações de contextos provisionadas para a interface fornecida.
Sintaxe

show provisionedcontexts [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo
 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

show purpose

radio
Mostra as informações de estado de rádio para a interface fornecida.
Sintaxe

show radio [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show radio interface="Cellular"

readyinfo
Mostra as informações prontas para a interface fornecida.
Sintaxe

show readyinfo [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show readyinfo interface="Cellular"

signal
Mostra as informações de sinal para a interface fornecida.
Sintaxe

show signal [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show signal interface="Cellular"

slotmapping
Mostra o mapeamento de slot de modem de Banda Larga Móvel para a interface fornecida.
Sintaxe

show slotmapping [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show slotmapping interface="Cellular"

slotstatus
Mostra o status do slot de modem de Banda Larga Móvel para a interface fornecida.
Sintaxe

show slotstatus [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo
 show slotstatus interface="Cellular"

smsconfig
Mostra as informações de configuração do SMS para a interface fornecida.
Sintaxe

show smsconfig [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

show smsconfig interface="Cellular"

tracing
Mostra se o rastreamento de Banda Larga Móvel está habilitado ou desabilitado.
Sintaxe

show tracing

visibleproviders
Mostra a lista de provedores visíveis para a interface fornecida.
Sintaxe

show visibleproviders [interface=]<string>

Parâmetros

PA RÂ M ET RO DESC RIÇ Ã O REQ UISITO

interface Nome da interface. É um dos nomes Necessária

de interface mostrados pelo comando
"netsh mbn show interfaces".

Exemplo

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

M A RC A VA LO R O P C IO N A L?

feature Uma área de recursos das áreas de Obrigatório

recursos compatíveis listadas abaixo

testpath Demarcador que contém os binários Opcional se o servidor HLK estiver

de teste instalado

taefpath Demarcador que contém os binários Opcional se o servidor HLK estiver

TAEF instalado

param Parâmetros separados por vírgulas, a Necessários para determinadas áreas

serem usados para os testes de 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar este tópico para uma visão geral do subsistema de rede e links para outros tópicos neste guia.

NOTE
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 na pilha de rede e contém o driver de rede que se
comunica diretamente com o adaptador de rede.
2. NDIS (Especificação de Interface do Driver de Rede). O NDIS expõe interfaces para o driver abaixo
dele e para as camadas acima dele, como a Pilha de Protocolos.
3. Pilha de protocolos . A pilha de protocolo implementa protocolos como TCP/IP e UDP/IP. Essas camadas
expõem a interface da camada de transporte para camadas acima delas.
4. Drivers de sistema . Normalmente, esses são clientes que usam uma interface TDX (transport data
extension) ou WSK (Winsock Kernel) para expor interfaces a aplicativos de modo de usuário. A interface
WSK foi introduzida no Windows Server 2008 e Windows Vista e é exposta ® por AFD.sys. A interface
melhora o desempenho eliminando a alternação entre o modo de usuário e o modo kernel.
5. Aplicativos de 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 que
são executados em cada camada.
 Escolhendo um adaptador de rede
13/08/2021 • 11 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar este tópico para aprender alguns dos recursos dos adaptadores de rede que podem afetar suas
opções de compra.
Aplicativos com uso intensivo de rede exigem Adaptadores de rede de alto desempenho. Esta seção explora
algumas considerações sobre como escolher adaptadores de rede, bem como definir configurações de
adaptador de rede diferentes para obter o melhor desempenho de rede.

TIP
Você pode definir as configurações do adaptador de rede usando Windows PowerShell. Para obter mais informações,
consulte cmdlets do adaptador de rede em Windows PowerShell.

Recursos de descarga
O descarregamento de tarefas da CPU da 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 nos produtos da Microsoft pode descarregar uma ou mais tarefas em 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 de diferentes recursos de descarregamento que estão disponíveis no
Windows Server 2016.

T IP O DE DESC A RREGA M EN TO DESC RIÇ Ã O

Cálculo da soma de verificação para TCP
A pilha de rede pode descarregar o cálculo e a validação das
somas de verificação TCP do protocolo de controle de
transmissão ( ) nos caminhos de código de envio e
recebimento. Ele também pode descarregar o cálculo e a
validação de somas de verificação de IPv4 e IPv6 em
caminhos de código de envio e recebimento.

Cálculo da soma de verificação para UDP A pilha de rede pode descarregar o cálculo e a validação de
somas de verificação UDP do protocolo de datagrama de
usuário ( ) em caminhos de código de envio e recebimento.

Cálculo da soma de verificação para IPv4 A pilha de rede pode descarregar o cálculo e a validação de
somas de verificação de IPv4 em caminhos de código de
envio e recebimento.

Cálculo da soma de verificação para IPv6 A pilha de rede pode descarregar o cálculo e a validação de
somas de verificação do IPv6 em caminhos de código de
envio e recebimento.
 T IP O DE DESC A RREGA M EN TO DESC RIÇ Ã O

Segmentação de pacotes TCP grandes A camada de transporte TCP/IP dá suporte ao LSOv2

(carregamento de envio grande) v2. Com o LSOv2, a camada
de transporte TCP/IP pode descarregar a segmentação de
pacotes TCP grandes no adaptador de rede.

RSS de escala lateral de recebimento ()
O RSS é uma tecnologia de driver de rede que permite a
distribuição eficiente de processamento de recebimento de
rede em várias CPUs em sistemas multiprocessadores. Mais
detalhes sobre o RSS são fornecidos posteriormente neste
tópico.

União de segmento de recebimento ( RSC)
O RSC é a capacidade de agrupar pacotes para minimizar o
processamento 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.

Receber dimensionamento lateral

Windows Server 2016, Windows Server 2012, Windows Server 2012 r2, Windows server 2008 R2 e Windows
server 2008 dão suporte ao rss de dimensionamento do lado de recebimento ( ) .
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 ( peers de SMT de vários threads simultâneos ) . A tecnologia
Intel Hyper-Threading é um exemplo. O RSS direciona o processamento de rede para até um processador lógico
por núcleo. Por exemplo, em um servidor com Intel Hyper-Threading, 4 núcleos e 8 processadores lógicos, 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, que preserva a ordenação.
O RSS também equilibra o tráfego de difusão e unicast UDP e roteia os fluxos relacionados ( que são
determinados pelo hash dos endereços de origem e de destino ) para o mesmo processador lógico,
preservando a ordem das entradas relacionadas. Isso ajuda a melhorar a escalabilidade e o desempenho para
cenários de uso intensivo de recebimento para servidores que têm menos adaptadores de rede do que os
processadores lógicos qualificados.
Configurando RSS
no Windows Server 2016, você pode configurar o RSS usando os cmdlets Windows PowerShell e os perfis RSS.
você pode definir perfis RSS usando o parâmetro – Profile do cmdlet Set-NetAdapterRss Windows
PowerShell.
comandos de Windows PowerShell para configuração de RSS
Os cmdlets a seguir permitem ver e modificar os parâmetros RSS por adaptador de rede.

NOTE
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 Get-Help 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. Esse comando recupera as propriedades de RSS do adaptador de rede que você
especificar.
Set-NetAdapterRss. Esse comando define as propriedades de RSS no adaptador de rede que você
especificar.
Perfis de 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 esse parâmetro são:
Mais próximo . Os números de processador lógicos próximos ao processador RSS base do adaptador de
rede são preferenciais. Com esse perfil, o sistema operacional pode reequilibrar os processadores lógicos
dinamicamente com base na carga.
ClosestStatic . Os números de processador lógico próximo ao processador RSS de base do adaptador de
rede são preferenciais. Com esse perfil, o sistema operacional não reequilibra dinamicamente os
processadores lógicos com base na carga.
Numa . Os números de processador lógicos geralmente são selecionados em diferentes nós NUMA para
distribuir a carga. Com esse perfil, o sistema operacional pode reequilibrar os processadores lógicos
dinamicamente com base na carga.
NUMAStatic . Esse é o perfil padrão . Os números de processador lógicos 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.
Conser vador . 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 de 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 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 set-NetAdapterRss adicionais que você pode usar para configurar o RSS:

NOTE
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 do

processador usada pelo RSS. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –BaseProcessorGroup <value>

* MaxProcessorGroup : define o grupo de processador máximo de um nó numa. Isso afeta a matriz do

processador usada pelo RSS. Definir isso restringiria um grupo de processadores máximo 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 do

processador usada pelo RSS. Isso permite o particionamento de processadores entre adaptadores de
rede. Esse é o primeiro processador lógico no intervalo de processadores RSS que é atribuído a cada
adaptador. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –BaseProcessorNumber <Byte Value>

* NumaNode : o nó numa para o qual cada adaptador de rede pode alocar memória. Isso pode estar
dentro de um grupo k ou de diferentes grupos k. Exemplo de sintaxe:
Set-NetAdapterRss –Name "Ethernet" –NumaNodeID <value>

* NumberofReceiveQueues : se os processadores lógicos parecem estar subutilizados para receber

tráfego ( , por exemplo, como 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 no seu 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 afunilamento
de processamento de recebimento, apresentando o RSS no formato Word.
Noções básicas sobre o desempenho do RSS
O ajuste do RSS requer a compreensão da configuração e da lógica de balanceamento de carga. para verificar se
as configurações de RSS entraram em vigor, você pode examinar a saída ao executar o cmdlet Get-
NetAdapterRss Windows PowerShell. Veja a seguir um exemplo de saída 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 dos parâmetros de eco 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 que são usados para distribuir o tráfego de entrada.
Neste exemplo, a notação n:c designa o par de índice K-Group: CPU de numa que é 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 este sistema (k-Group 0) e uma entrada de tabela de indireção n (em que n <=
128). Como o número de filas de recebimento está definido como 2, somente 2 processadores (0:0, 0:4) são
escolhidos, embora os processadores máximos estejam definidos como 8. Na verdade, a tabela de indireção
está aplicando hash ao tráfego de entrada para usar apenas 2 CPUs dos 8 que estão disponíveis.
Para utilizar totalmente as CPUs, o número de filas de recebimento RSS deve ser igual ou maior que os
processadores máximos. No exemplo anterior, a fila de recebimento deve ser definida como 8 ou superior.
Agrupamento NIC e RSS
O RSS pode ser habilitado em um adaptador de rede que está agrupado com outra placa de interface de rede
usando o 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 os cmdlets RSS no adaptador de rede agrupado.
União de segmento de recebimento (RSC )
A União de segmento ( de recebimento RSC ) ajuda o desempenho, reduzindo o número de cabeçalhos IP que
são processados para uma determinada quantidade de dados recebidos. Ele deve ser usado para ajudar a
dimensionar o desempenho de dados recebidos agrupando ( ou unindo ) os pacotes menores em unidades
maiores.
Essa abordagem pode afetar a latência com os benefícios vistos principalmente nos ganhos da produtividade. O
RSC é recomendado para aumentar a taxa de transferência para cargas de trabalho pesadas recebidas.
Considere a implantação de adaptadores de rede que dão suporte a RSC.
Nesses adaptadores de rede, verifique se o RSC está nessa ( 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 mostre os
benefícios do RSC sendo desativado.
Compreendendo o diagnóstico de RSC
você pode diagnosticar o RSC usando os cmdlets de Windows PowerShell Get-NetAdapterRsc e get-
NetAdapterStatistics .
A seguir, há um exemplo de saída 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 ao 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 ou as exceções Unidas causadas. Isso fornece uma indicação dos problemas
de União.
A seguir, há um exemplo de saída 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
Somente há suporte para RSC 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 do Hyper-V. Além disso, as máquinas virtuais não têm o benefício de RSC porque os
adaptadores de rede virtual não dão suporte a RSC.
O RSC pode ser habilitado para uma máquina virtual quando o Sr-IOV de virtualização de entrada/saída de raiz
única ( ) estiver habilitado. Nesse caso, as funções virtuais dão suporte ao recurso 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 configurar manualmente os recursos usando a guia rede avançada para o
adaptador. Para esses adaptadores, você pode definir os valores de um número de parâmetros, incluindo o
número de buffers de recebimento e buffers de envio.
a configuração de recursos do adaptador de rede é simplificada pelo uso dos cmdlets Windows PowerShell a
seguir.
Get-NetAdapterAdvancedProperty
Set-NetAdapterAdvancedProperty
Habilitar-netadapter
Habilitar-netadaptadorbinding
Habilitar-NetAdapterChecksumOffload
Habilitar-NetAdapterIPSecOffload
Habilitar-NetAdapterLso
Habilitar-NetAdapterPowerManagement
Habilitar-NetAdapterQos
Habilitar-NetAdapterRDMA
Habilitar-NetAdapterSriov
Para obter mais informações, consulte cmdlets do adaptador de rede em Windows PowerShell.
Para obter links para todos os tópicos deste guia, consulte ajuste de desempenho do subsistema de rede.
 Configurar a ordem das interfaces de rede
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

em Windows Server 2016 e Windows 10, você pode usar a métrica de interface para configurar a ordem das
interfaces de rede.
isso é diferente de em versões anteriores do Windows e Windows Server, que permitia que você configure 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 dos 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.
Quando as rotas de tráfego de rede são escolhidas e você configurou o parâmetro InterfaceMetric do
comando set-NetIPInterface , a métrica geral usada para determinar a preferência de interface é a soma da
métrica de rota e a métrica da interface. Normalmente, a métrica de interface dá preferência a uma interface
específica, como usar com fio se ambos com e sem fio estiverem disponíveis.
o exemplo de comando a seguir Windows PowerShell mostra o uso desse parâmetro.

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 obter links para todos os tópicos deste guia, consulte ajuste de desempenho do subsistema de rede.
 Adaptadores de rede para ajuste do desempenho
13/08/2021 • 16 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Use as informações neste tópico para ajustar os adaptadores de rede de desempenho para computadores que
executam o 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 taxa de transferência de rede e o uso de recursos.
As configurações de ajuste corretas para seus 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 eficiente o suficiente para lidar com os recursos de descarregamento com alta
taxa de transferência.

IMPORTANT
Não use os recursos de descarregamento Descarregamento de tarefa IPSec ou descarregamento de Chimney TCP .
essas tecnologias são preteridas 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, habilitar
os 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á seguir um habilitar os
recursos de descarga de segmentação.

NOTE
Alguns adaptadores de rede exigem que você habilite recursos de descarregamento independentemente para os
caminhos de envio e recebimento.

Habilitando o RSS (recebimento em escala) 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 por adaptadores de rede
compatíveis com RSS, o servidor pode processar solicitações da Web de entrada de diferentes conexões
simultaneamente em diferentes CPUs.
 IMPORTANT
Evite usar adaptadores de rede não RSS e adaptadores de rede compatíveis com RSS no mesmo servidor. Devido à lógica
de distribuição de carga em RSS e HTTP (Hypertext Transfer Protocol), o desempenho poderá ser seriamente degradado se
um adaptador de rede compatível com RSS aceitar o tráfego da Web em um servidor que tenha um ou mais adaptadores
de rede compatíveis com 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 RSS predefinido padrão é NUMAStatic , que difere do padrão que as versões anteriores do Windows
usavam. Antes de começar a usar perfis RSS, examine os perfis disponíveis para entender quando eles são
benéficos e como eles se aplicam ao seu ambiente de rede e ao hardware.
Por exemplo, se você abrir o Gerenciador de tarefas e examinar os processadores lógicos em seu servidor e eles
parecerem estar subutilizados para receber tráfego, você poderá tentar aumentar o número de filas RSS do
padrão de dois para o máximo ao qual o adaptador de rede dá suporte. 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.

NOTE
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 com um valor fixo que não pode ser alterado.

Habilitando a moderação de interrupção

Para controlar a moderação da interrupção, alguns adaptadores de rede expõem diferentes níveis de moderação
de interrupção, diferentes parâmetros de União de buffer (às vezes separadamente para buffers de envio e
recebimento) ou ambos.
Você deve considerar a moderação da interrupção para cargas de trabalho vinculadas à CPU. Ao usar a
moderação de interrupção, considere a compensação entre as economias e a latência da CPU do host versus a
economia de CPU do host maior devido a mais interrupções e menos latência. Se o adaptador de rede não
executar a moderação de interrupção, mas expor a União de buffer, você poderá melhorar o desempenho
aumentando o número de buffers agrupados 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 de Configurações ou usando o comando powercfg . Para
obter mais informações, consulte Opções de Powercfg Command-Line.
Defina o perfil de gerenciamento de energia do sistema operacional para Sistema de alto
desempenho .

NOTE
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 descarregamentos estáticos. Por exemplo, habilite as somas de verificação de UDP, somas de
verificação de TCP e configurações de descarga grande (LSO).
Se o tráfego for de vários fluxos, como ao receber o tráfego de multicast de alto volume, habilite 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 compensação.
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 o SMI (System Management interrupções) para uma variedade de funções
de manutenção, como erros de memória ECC (código de correção de erros), mantendo a compatibilidade com
USB herdada, controlando o ventilador e gerenciando configurações de energia controladas por 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 de BIOS são frequentemente
chamadas de "BIOS de baixa latência" ou "BIOS gratuito do SMI". Em alguns casos, não é possível para uma
plataforma de hardware eliminar a atividade de SMI completamente, ela é usada para controlar funções
essenciais (por exemplo, ventiladores de refrigeração).

NOTE
O sistema operacional não pode controlar SMIs porque o processador lógico está sendo executado em um modo de
manutenção especial, o que impede a intervenção do sistema operacional.
Ajuste de desempenho TCP
Você pode usar os seguintes itens para ajustar o desempenho de TCP.
Ajuste automática da janela de recepção TCP
no Windows Vista, Windows Server 2008 e versões posteriores do Windows, a pilha de rede Windows usa um
recurso chamado nível de ajuste da janela de recepção tcp para negociar o tamanho da janela de recepção 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 recepção de tamanho fixo
(65.535 bytes) que limitou a taxa de transferência potencial geral para conexões. A taxa de transferência
atingível total de conexões TCP pode limitar os cenários de uso da rede. A janela de recepção TCP habilita esses
cenários para usar totalmente a rede.
Para uma janela de recepção TCP que tem um tamanho específico, você pode usar a equação a seguir para
calcular a taxa de transferência total de uma única conexão.

Taxa de transferência atingível total em bytes = Tamanho da janela de recepção 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 taxa de transferência atingível total é de
apenas 51 Mbps. Esse valor é razoável para uma grande infraestrutura de rede corporativa. No entanto, usando
a AutoAjuste 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 recepção TCP. Se o aplicativo não definir o tamanho da
janela de recebimento, a velocidade do link determinará o tamanho da seguinte maneira:
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 tem um adaptador de rede de 1 Gbps instalado, o tamanho da janela
deve ser 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.

NOTE
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 essa KB 934430, a conectividade de rede falha quando você tenta usar o Windows Vista atrás de
um dispositivo de firewall ou entre em contato com a equipe de suporte do fornecedor do dispositivo de rede.

Revisar e configurar o nível de ajuste automático da janela de recebimento TCP

Você pode usar comandos netsh ou Windows PowerShell cmdlets para revisar ou modificar o nível de ajuste
automático da janela de recebimento TCP.
 NOTE
Ao contrário das versões do Windows que pré-datam Windows 10 ou Windows Server 2019, você não pode mais usar o
Registro para configurar o tamanho da janela de recebimento TCP. Para obter mais informações sobre as configurações
preterida, consulte Parâmetros TCP preterido.

NOTE
Para obter informações detalhadas sobre os níveis de ajuste automático disponíveis, consulte Níveis de ajuste automático.

Para usar o netsh para revisar ou modificar o nível de ajuste automático

Para revisar as configurações atuais, abra uma janela do Prompt de Comando e execute o seguinte comando:

netsh interface tcp show global

A saída desse comando deve ser semelhante à 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:

netsh interface tcp set global autotuninglevel=<Value>

NOTE
No comando anterior, representa <Value> o novo valor para o nível de ajuste automático.

Para obter mais informações sobre esse comando, consulte Comandos Netsh para o Protocolo de Controle de
Transmissão de Interface.
Para usar o PowerShell para revisar ou modificar o nível de ajuste automático
Para revisar as configurações atuais, abra uma janela do PowerShell e execute o cmdlet a seguir.

Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal

A saída desse cmdlet deve ser semelhante à seguinte.

 SettingName AutoTuningLevelLocal
----------- --------------------
Automatic
InternetCustom Normal
DatacenterCustom Normal
Compat Normal
Datacenter Normal
Internet Normal

Para modificar a configuração, execute o cmdlet a seguir no prompt de comando do PowerShell.

Set-NetTCPSetting -AutoTuningLevelLocal <Value>

NOTE
No comando anterior, representa <Value> 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ático
Você pode definir o ajuste automático 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 VA LO R H EXA DEC IM A L C O M EN TÁ RIO S

Normal (padrão) 0x8 (fator de escala de 8) De definir a janela de recebimento TCP

para crescer para acomodar quase
todos os cenários.

Desabilitado Nenhum fator de escala disponível De definir a janela de recebimento TCP

com seu valor padrão.

Restritos 0x4 (fator de escala de 4) Definir a janela de recebimento TCP

para crescer além de seu valor padrão,
mas limitar esse crescimento em
alguns cenários.

Altamente Restrito 0x2 (fator de escala de 2) De definir a janela de recebimento TCP

para aumentar além de seu valor
padrão, mas faça isso de forma muito
conservadora.

Habilitação 0xE (fator de escala de 14) De definir a janela de recebimento TCP

para aumentar para acomodar
cenários extremos.

Se você usar um aplicativo para capturar pacotes de rede, o aplicativo deverá relatar dados semelhantes aos
seguintes para diferentes configurações de nível de ajuste automático de janela.
Nível de ajuste automático: 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ático: desabilitado

Frame: Number = 353, Captured Frame Length = 62, 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 = 2576, Total IP Length
= 48
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60956, DstPort=Microsoft-DS(445), PayloadLen=0,
Seq=2315885330, Ack=0, Win=64240 ( ) = 64240
SrcPort: 60956
DstPort: Microsoft-DS(445)
SequenceNumber: 2315885330 (0x8A099B12)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 112 (0x70)
+ 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
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ NoOption:
+ SACKPermitted:

Nível de ajuste automático: Restrito

 Frame: Number = 3, 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 = 2319, Total IP Length
= 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60890, DstPort=Microsoft-DS(445), PayloadLen=0,
Seq=1966088568, Ack=0, Win=64240 ( Negotiating scale factor 0x4 ) = 64240
SrcPort: 60890
DstPort: Microsoft-DS(445)
SequenceNumber: 1966088568 (0x75302178)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. ---------------------------------------------------------> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x4 ) = 64240 ---------> TCP Receive Window set as 64K as
per NIC Link bitrate. Note it shows the 0x4 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 4 -------------------------------> Scale factor, defined by
AutoTuningLevel.
+ NoOption:
+ NoOption:
+ SACKPermitted:

Nível de ajuste automático: altamente restrito

Frame: Number = 115, 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 = 2388, Total IP Length
= 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60903, DstPort=Microsoft-DS(445), PayloadLen=0,
Seq=1463725706, Ack=0, Win=64240 ( Negotiating scale factor 0x2 ) = 64240
SrcPort: 60903
DstPort: Microsoft-DS(445)
SequenceNumber: 1463725706 (0x573EAE8A)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. ---------------------------------------------------------> SYN Flag set
Window: 64240 ( Negotiating scale factor 0x2 ) = 64240 ---------> TCP Receive Window set as 64K as
per NIC Link bitrate. Note it shows the 0x2 Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 2 ------------------------------> Scale factor, defined by
AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:

Nível de ajuste automático: experimental

 Frame: Number = 238, 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 = 2490, Total IP Length
= 52
- Tcp: [Bad CheckSum]Flags=......S., SrcPort=60933, DstPort=Microsoft-DS(445), PayloadLen=0,
Seq=2095111365, Ack=0, Win=64240 ( Negotiating scale factor 0xe ) = 64240
SrcPort: 60933
DstPort: Microsoft-DS(445)
SequenceNumber: 2095111365 (0x7CE0DCC5)
AcknowledgementNumber: 0 (0x0)
+ DataOffset: 128 (0x80)
+ Flags: ......S. ---------------------------------------------------------> SYN Flag set
Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP Receive Window set as 64K as
per NIC Link bitrate. Note it shows the 0xe Scale Factor.
Checksum: 0x8182, Bad
UrgentPointer: 0 (0x0)
- TCPOptions:
+ MaxSegmentSize: 1
+ NoOption:
+ WindowsScaleFactor: ShiftCount: 14 -----------------------------> Scale factor, defined by
AutoTuningLevel
+ NoOption:
+ NoOption:
+ SACKPermitted:

Parâmetros TCP preterido

As configurações de registro a seguir do Windows Server 2003 não têm mais suporte e são ignoradas em
versões posteriores.
TcpWindowSize
NumTcbTablePar titions
MaxHashTableSize
Todas essas configurações estavam localizadas na seguinte sub-chave do Registro:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Ser vices\Tcpip\Parameters

Windows Plataforma de filtragem

Windows O Vista Windows Server 2008 introduziu o WFP (Windows Filtering Platform). O WFP fornece APIs a
ISVs (fornecedores de software não independentes da Microsoft) para criar filtros de processamento de pacotes.
Exemplos incluem software de firewall e antivírus.

NOTE
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 WFP no Windows Centro de
Desenvolvimento.

Para ver links para todos os tópicos neste guia, consulte Ajuste de desempenho do subsistema de rede.
 Contadores de desempenho relacionados à rede
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Este tópico lista os contadores que são relevantes para gerenciar o desempenho de rede e contém as seções a
seguir.
Utilização de recursos
Possíveis problemas de rede
Desempenho de União lateral de recebimento (RSC)

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
Interface 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 isso for maior do
que 2, ocorrerão atrasos. Você deve encontrar o afunilamento e eliminá-lo se puder. Como o NDIS
enfileira as solicitações, esse comprimento deve ser sempre 0.
Informações do processador
% Tempo do Processador
Interrupções/s
DPCs enfileirados/s
Esse contador é uma taxa média na qual as DPCs foram adicionadas à fila de DPC do processador
lógico. Cada processador lógico tem sua própria fila de DPC. Esse contador mede a taxa na qual as
 DPCs são adicionadas à 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
amostragem.

Possíveis problemas de rede

Os contadores de desempenho a seguir são relevantes para possíveis problemas de rede.
Interface 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 de datagramas recebidos
TCPv4, TCPv6
Falhas de Conexão
Conexões Redefinidas
Política de QoS de rede
Pacotes removidos
Pacotes eliminados/s
Atividade da placa de interface de rede por processador
Indicações de recebimento de recursos baixos/s
Pacotes de recursos baixos recebidos/s
BSP Microsoft Winsock
Datagramas removidos
Datagramas removidos/s
Conexões rejeitadas
Conexões rejeitadas/s

Desempenho de União lateral de recebimento (RSC)

Os contadores de desempenho a seguir são relevantes para o desempenho do RSC.
Adaptador de rede (*)
Conexões TCP ativas RSC
Tamanho médio de pacote RSC de TCP
Pacotes de União RSC TCP/s
 Exceções RSC de TCP/s
Para obter links para todos os tópicos deste guia, consulte ajuste de desempenho do subsistema de rede.
 Ferramentas de desempenho para cargas de
trabalho de rede
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber mais sobre as ferramentas de desempenho.
Este tópico contém seções sobre o cliente para a ferramenta de tráfego de servidor e o tamanho da janela
TCP/IP.

Ferramenta de tráfego de cliente para servidor

A ferramenta cliente para servidor ( ctsTraffic de tráfego ) fornece a capacidade de criar e verificar o tráfego de
rede.
Para obter mais informações e 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, pois NTttcp define o tamanho padrão da janela TCP como 64 K por meio de uma opção de
processador lógico específica ( 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 padrão de tamanho de janela
TCP para NTttcp gera 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 para 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 do TCP/IP. Por padrão, o tamanho da janela TCP é definido
com um valor suficiente e ajusta somente sob carga pesada ou por links de alta latência.
Para obter mais informações, consulte ajuste de desempenho do subsistema de rede.
 Agrupamento NIC
07/08/2021 • 12 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

neste tópico, fornecemos uma visão geral do agrupamento NIC (placa de Interface de rede) no Windows Server.
O agrupamento NIC permite que você agrupe entre um e 32 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.

IMPORTANT
Você deve instalar adaptadores de rede de membros da equipe NIC no mesmo computador host físico.

TIP
Uma equipe NIC que contém apenas um adaptador de rede não pode fornecer balanceamento de carga e failover. No
entanto, com um adaptador de rede, você pode usar agrupamento NIC para separação de tráfego de rede quando você
também estiver usando redes locais virtuais (VLANs).

Quando você configura adaptadores de rede em uma equipe NIC, eles se conectam à solução de agrupamento
NIC Common Core, que apresenta um ou mais adaptadores virtuais (também chamados de NICs de equipe
[tNICs] ou interfaces de equipe) ao sistema operacional.
como Windows Server 2016 dá suporte a até 32 interfaces de equipe por equipe, há uma variedade de
algoritmos que distribuem o tráfego de saída (carga) entre as NICs. A ilustração a seguir descreve uma equipe
NIC com vários tNICs.

Além disso, você pode conectar suas NICs agrupadas ao mesmo comutador ou a diferentes opções. Se você
conectar NICs a diferentes comutadores, ambos os comutadores deverão estar na mesma sub-rede.

Disponibilidade
O agrupamento NIC está disponível em todas as versões do Windows Server 2016. Você pode usar uma
variedade de ferramentas para gerenciar o agrupamento NIC de computadores que executam um sistema
operacional cliente, como:
 Cmdlets do Windows PowerShell
Área de Trabalho Remota
Ferramentas de Administração de Servidor Remoto

NICs com e sem suporte

você pode usar qualquer NIC Ethernet que tenha passado no Windows o teste de qualificação de Hardware e
logotipo (testes de WHQL) em uma equipe NIC em Windows Server 2016.
Você não pode inserir as seguintes NICs em uma equipe NIC:
Adaptadores de rede virtual do Hyper-V que são portas do comutador virtual Hyper-V expostas como
NICs na partição de host.

IMPORTANT
Não coloque as NICs virtuais do Hyper-V expostas na vNICs (partição de host) em uma equipe. Não há suporte
para o agrupamento de vNICs dentro da partição de host em nenhuma configuração. Tentativas de vNICs de
equipe podem causar uma perda completa de comunicação se ocorrerem falhas de rede.

Adaptador de rede de depuração do kernel (KDNIC).

NICs usadas para inicialização de rede.
nics que usam tecnologias diferentes de Ethernet, como WWAN, WLAN/Wi-Fi, Bluetooth e Infiniband,
incluindo NICs do protocolo Internet sobre Infiniband (IPoIB).

Compatibilidade
o agrupamento NIC é compatível com todas as tecnologias de rede no Windows Server 2016 com as seguintes
exceções.
Sr-IOV (vir tualização de e/s de raiz única) . Para SR-IOV, os dados são entregues diretamente à NIC
sem passá-los por meio da pilha de rede (no sistema operacional do host, no caso de virtualização).
Portanto, não é possível que a equipe NIC Inspecione ou Redirecione os dados para outro caminho na
equipe.
QoS (qualidade de ser viço) do host nativo . Quando você define políticas de QoS em um sistema
nativo ou de host, e essas políticas chamam limitações de largura de banda mínima, a taxa de
transferência geral para uma equipe NIC é menor do que seria sem as políticas de largura de banda em
vigor.
Chimney TCP . Não há suporte para TCP Chimney com agrupamento NIC porque o Chimney TCP
descarrega toda a pilha de rede diretamente para a NIC.
autenticação 802.1 x . Você não deve usar a autenticação 802.1 X com agrupamento NIC, pois algumas
opções não permitem a configuração da autenticação 802.1 X e do agrupamento NIC na mesma porta.
Para saber mais sobre como usar o agrupamento NIC em máquinas virtuais (VMs) executadas em um host
Hyper-V, confira criar uma nova equipe NIC em um computador host ou VM.

Filas de máquina virtual (VMQs)

VMQs é um recurso de NIC que aloca uma fila para cada VM. Sempre que você tiver habilitado o Hyper-V; Você
também deve habilitar a VMQ. no Windows Server 2016, VMQs use o comutador NIC vPorts com uma única fila
atribuída ao vPort para fornecer a mesma funcionalidade.
Dependendo do modo de configuração do comutador e do algoritmo de distribuição de carga, o agrupamento
NIC apresenta o menor número de filas disponíveis e com suporte por qualquer adaptador na equipe (modo
min-Queues) ou o número total de filas disponíveis em todos os membros da equipe (modo de soma de filas).
Se a equipe estiver no modo de agrupamento Switch-Independent e você definir a distribuição de carga para o
modo de porta do Hyper-V ou modo dinâmico, o número de filas relatadas será a soma de todas as filas
disponíveis nos membros da equipe (modo de soma das filas). Caso contrário, o número de filas relatadas é o
menor número de filas suportadas por qualquer membro da equipe (modo mín. de filas).
Veja por quê:
Quando a equipe independente de comutador estiver no modo de porta do Hyper-V ou no modo
dinâmico, o tráfego de entrada para uma VM (porta do comutador) do Hyper-V sempre chegará ao
mesmo membro da equipe. O host pode prever/controlar qual membro recebe o tráfego para uma VM
específica, de modo que o agrupamento NIC possa ser mais elaborado sobre quais filas de VMQ alocar
em um determinado membro da equipe. O agrupamento NIC, trabalhando com a opção Hyper-V, define
a VMQ para uma VM em um membro da equipe precisamente e sabe que o tráfego de entrada atinge
essa fila.
Quando a equipe está em qualquer modo dependente de switch (agrupamento estático ou Agrupamento
de LACP), o comutador ao qual a equipe está conectada controla a distribuição de tráfego de entrada. O
software de agrupamento NIC do host não pode prever qual membro da equipe Obtém o tráfego de
entrada para uma VM e pode ser que o comutador distribua o tráfego para uma VM em todos os
membros da equipe. Como resultado do software de agrupamento NIC, trabalhar com a opção Hyper-V,
programa uma fila para a VM em cada membro da equipe, não apenas um membro da equipe.
Quando a equipe está no modo independente de comutador e usa o balanceamento de carga de hash de
endereço, o tráfego de entrada sempre entra em uma NIC (o membro da equipe principal) – tudo isso em
apenas um membro da equipe. Como outros membros da equipe não estão lidando com o tráfego de
entrada, eles são programados com as mesmas filas que o membro primário para que, se o membro
primário falhar, qualquer outro membro da equipe possa ser usado para pegar o tráfego de entrada e as
filas já estiverem em vigor.
A maioria das NICs tem filas usadas para o RSS (modo de recebimento) ou a VMQ, mas não ao mesmo
tempo. Algumas configurações de VMQ parecem ser configurações para filas RSS, mas são
configurações nas filas genéricas que o RSS e a VMQ usam, dependendo de qual recurso está atualmente
em uso. Cada NIC tem, em suas propriedades avançadas, valores para * RssBaseProcNumber e *
MaxRssProcessors. A seguir estão algumas configurações de VMQ que fornecem melhor desempenho do
sistema.
O ideal é que cada NIC tenha o * RssBaseProcNumber definido como um número par maior ou igual a
dois (2). O primeiro processador físico, o núcleo 0 (processadores lógicos 0 e 1), normalmente faz a
maior parte do processamento do sistema, de modo que o processamento da rede deve ser afastado
desse processador físico. Algumas arquiteturas de computador não têm dois processadores lógicos por
processador físico, portanto, para esses computadores, o processador base deve ser maior ou igual a 1.
Em caso de dúvida, suponha que o host esteja usando um processador lógico 2 por arquitetura de
processador físico.
Se a equipe estiver no modo de soma das filas, os processadores de membros da equipe não devem ser
sobrepostos. Por exemplo, em um host de 4 núcleos (8 processadores lógicos) com uma equipe de 2
NICs 10 Gbps, você pode definir o primeiro para usar o processador base 2 e usar 4 núcleos; o segundo
seria definido para usar o processador base 6 e usar dois núcleos.
Se a equipe estiver no modo de Min-Queues, os conjuntos de processador usados pelos membros da
equipe deverão ser idênticos.
HNV (Virtualização de Rede Hyper-V)
O agrupamento NIC é totalmente compatível com a HNV (virtualização de rede do Hyper-V). O sistema de
gerenciamento de HNV fornece informações para o driver de agrupamento NIC que permite que o
agrupamento NIC distribua a carga de forma a otimizar o tráfego HNV.

Migração dinâmica
O agrupamento NIC em VMs não afeta Migração ao Vivo. As mesmas regras existem para Migração ao Vivo se
está ou não Configurando o agrupamento NIC na VM.

VLANs (redes locais virtuais)

Quando você usa o agrupamento NIC, a criação de várias interfaces de equipe permite que um host se conecte a
VLANs diferentes ao mesmo tempo. Configure seu ambiente usando as seguintes diretrizes:
Antes de habilitar o agrupamento NIC, configure as portas de comutador físico conectadas ao host de
agrupamento para usar o modo de tronco (promíscuo). O comutador físico deve passar todo o tráfego
para o host para filtragem sem modificar o tráfego.
Não configure filtros de VLAN nas NICs usando as configurações de propriedades avançadas de NIC.
Permita que o software de agrupamento NIC ou o comutador virtual Hyper-V (se presente) execute a
filtragem de VLAN.
Usar VLANs com agrupamento NIC em uma VM
Quando uma equipe se conecta a um comutador virtual do Hyper-V, toda a diferenciação de VLAN deve ser feita
no comutador virtual do Hyper-V em vez de no agrupamento NIC.
Planeje usar VLANs em uma VM configurada com uma equipe NIC usando as seguintes diretrizes:
O método preferencial de dar suporte a várias VLANs em uma VM é configurar a VM com várias portas
no comutador virtual do Hyper-V e associar cada porta a uma VLAN. Nunca faça uma equipe dessas
portas na VM porque isso causa problemas de comunicação de rede.
Se a VM tiver várias funções virtuais de SR-IOV (VFs), verifique se elas estão na mesma VLAN antes de
agrupá-las na VM. É facilmente possível configurar o VFs diferente para estar em VLANs diferentes e
fazer isso causa problemas de comunicação de rede.
Gerenciar adaptadores de rede e VLANs
Se você precisar ter mais de uma VLAN exposta em um sistema operacional convidado, considere renomear as
interfaces Ethernet para esclarecer a VLAN atribuída à interface. Por exemplo, se você associar a interface
Ethernet com a VLAN 12 e a interface Ethernet 2 com VLAN 48, renomeie a interface Ethernet para
EthernetVL AN12 e a outra para EthernetVL AN48 .
renomeie interfaces usando o comando Windows PowerShell renomear-netadapter ou executando o
seguinte procedimento:
1. Em Gerenciador do Servidor, em Propriedades do adaptador de rede que você deseja renomear, clique
no link à direita do nome do adaptador de rede.
2. Clique com o botão direito do mouse no adaptador de rede que você deseja renomear e selecione
renomear .
3. Digite o novo nome para o adaptador de rede e pressione ENTER.

Máquinas Virtuais (VMs)

Se você quiser usar o NIC Teaming em uma VM, deverá conectar os adaptadores de rede virtual na VM somente
a comutadores virtuais externos do Hyper-V. Isso permite que a VM sustente a conectividade de rede mesmo na
circunstância em que um dos adaptadores de rede física conectados a um com switch virtual falha ou é
desconectado. Adaptadores de rede virtual conectados a Comutadores Virtuais do Hyper-V internos ou privados
não podem se conectar ao comutadores quando estão em uma equipe e a rede falha para a VM.
O NIC Teaming no Windows Server 2016 dá suporte a equipes com dois membros em VMs. Você pode criar
equipes maiores, mas não há suporte para equipes maiores. Todos os membros da equipe devem se conectar a
um com switch virtual externo diferente e as interfaces de rede da VM devem ser configuradas para permitir o
teaming.
Se você estiver configurando uma equipe de NIC em uma VM, deverá selecionar um modo de Equipe de Opção
Independente e um modo de balanceamento de carga do Hash de Endereço.

Adaptadores de rede com capacidade para SR-IOV

Uma equipe de NIC no host Hyper-V ou no host Hyper-V não pode proteger o tráfego SR-IOV porque ele não
passa pelo Com switch do Hyper-V. Com a opção de Teaming NIC da VM, você pode configurar dois
Comutadores Virtuais do Hyper-V externos, cada um conectado à sua própria NIC com capacidade para SR-IOV.

Cada VM pode ter uma VF (função virtual) de uma ou ambas NICs SR-IOV e, no caso de uma desconexão NIC,
failover do VF primário para o adaptador de backup (VF). Como alternativa, a VM pode ter uma VF de uma NIC
e uma vmNIC não VF conectada a outro com switch virtual. Se a NIC associada à VF for desconectada, o tráfego
poderá fazer failover para a outra opção sem perda de conectividade.
Como o failover entre NICs em uma VM pode resultar no tráfego enviado com o endereço MAC da outra
vmNIC, cada porta do Com switch virtual do Hyper-V associada a uma VM usando o NIC Teaming deve ser
definida para permitir o teaming.

Tópicos relacionados
Uso e gerenciamento de endereços MAC de NIC Teaming:quando você configura uma equipe NIC com o
modo independente do comutamento e o hash de endereço ou a distribuição dinâmica de carga, a
equipe usa o endereço MAC (controle de acesso à mídia) do membro principal da Equipe de NIC no
tráfego de saída. O membro principal da Equipe NIC é um adaptador de rede selecionado pelo sistema
operacional do conjunto inicial de membros da equipe.
Configurações de NIC Teaming: neste tópico, apresentamos uma visão geral das propriedades da Equipe
de NIC, como modos de balanceamento de carga e de equipe. Também lhe damos detalhes sobre a
configuração do adaptador Em espera e a propriedade de interface da equipe primária. Se você tiver pelo
menos dois adaptadores de rede em uma Equipe NIC, não será necessário designar um adaptador em
espera para tolerância a falhas.
Criar uma nova Equipe NIC em um computador host ou VM:neste tópico, você cria uma nova Equipe de
NIC em um computador host ou em uma VM (máquina virtual) Hyper-V em execução Windows Server
2016.
Solução de problemas de equipe NIC:neste tópico, discutiremos maneiras de solucionar problemas de
NIC Teaming, como hardware, com switch físico e desabilitando ou habilitando adaptadores de rede
usando Windows PowerShell.
 Gerenciamento e uso do endereço MAC de
agrupamento NIC
12/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Quando você configura uma Equipe NIC com o modo independente do comutamento e o hash de endereço ou
a distribuição dinâmica de carga, a equipe usa o endereço MAC (controle de acesso de mídia) do membro
principal da Equipe de NIC no tráfego de saída. O membro principal da Equipe de NIC é um adaptador de rede
que o sistema operacional seleciona no conjunto inicial de membros da equipe. É o primeiro membro da equipe
a ser associado à equipe depois que você a cria ou depois que o computador host é reiniciado. Como o membro
da equipe principal pode mudar de maneira não determinística em cada inicialização, ação de NIC
desabilitar/habilitar ou outras atividades de reconfiguração, o membro da equipe principal pode mudar e o
endereço MAC da equipe pode variar.
Na maioria das situações, isso não causa problemas, mas há alguns casos em que podem surgir problemas.
Se o membro da equipe principal for removido da equipe e colocado em operação, poderá haver um conflito de
endereço MAC. Para resolver esse conflito, desabilite e habilita a interface de equipe. O processo de
desabilitação e habilitação da interface de equipe faz com que a interface selecione um novo endereço MAC dos
membros restantes da equipe e elimina o conflito de endereço MAC.
Você pode definir o endereço MAC da equipe de NIC para um endereço MAC específico definindo-o na interface
da equipe primária, assim como você pode fazer ao configurar o endereço MAC de qualquer NIC física.

Uso de endereço MAC em pacotes transmitidos

Quando você configura uma Equipe de NIC no modo independente do comutamento e o hash de endereço ou a
distribuição dinâmica de carga, os pacotes de uma única fonte (como uma única VM) são distribuídos
simultaneamente entre vários membros da equipe. Para evitar que as opções se confundam e para evitar
alarmes mac acionados, o endereço MAC de origem é substituído por um endereço MAC diferente nos quadros
transmitidos em membros da equipe diferentes do membro da equipe principal. Por isso, cada membro da
equipe usa um endereço MAC diferente. Conflitos de endereço MAC são impedidos, a menos que e até que
ocorra uma falha.
Quando uma falha é detectada na NIC primária, o software de Equipe NIC começa a usar o endereço MAC do
membro da equipe principal no membro da equipe escolhido para servir como o membro temporário da
equipe primária (ou seja, aquele que agora aparecerá na opção como o membro da equipe principal). Essa
alteração só se aplica ao tráfego que seria enviado no membro da equipe primária com o endereço MAC do
membro da equipe primária como seu endereço MAC de origem. Outro tráfego continua sendo enviado com
qualquer endereço MAC de origem que ele teria usado antes da falha.
A seguir estão as listas que descrevem o comportamento de substituição de endereço MAC de NIC Teaming,
com base em como a equipe está configurada:
1. No modo Alternar Independente com distribuição de Hash de Endereço
Todos os pacotes ARP e NS são enviados no membro da equipe principal
Todo o tráfego enviado em NICs que não seja o membro da equipe principal é enviado com o
 endereço MAC de origem modificado para corresponder à NIC na qual eles são enviados
Todo o tráfego enviado no membro da equipe primária é enviado com o endereço MAC de origem
original (que pode ser o endereço MAC de origem da equipe)
2. No modo Alternar Independente com distribuição de Por ta do Hyper-V
Cada porta vmSwitch é associada a um membro da equipe
Cada pacote é enviado no membro da equipe para o qual a porta está associada
Nenhuma substituição de MAC de origem é feita
3. No modo Alternar Independente com Distribuição dinâmica
Cada porta vmSwitch é associada a um membro da equipe
Todos os pacotes ARP/NS são enviados no membro da equipe para o qual a porta está associada
Pacotes enviados no membro da equipe que é o membro da equipe afiliado não têm substituição
de endereço MAC de origem feita
Pacotes enviados em um membro da equipe que não seja o membro da equipe afiliado terão a
substituição de endereço MAC de origem feita
4. No modo Dependente de Comutagem (todas as distribuições)
Nenhuma substituição de endereço MAC de origem é executada

Tópicos relacionados
NIC Teaming: neste tópico, apresentamos uma visão geral do NIC (Network Interface Card) Teaming in
Windows Server 2016. O NIC Teaming permite agrupar entre um e 32 adaptadores de rede Ethernet
físicos em um ou mais adaptadores de rede virtual baseados em software. Esses adaptadores de rede
virtual fornecem desempenho rápido e tolerância a falhas em caso de falha do adaptador de rede.
Configurações de NIC Teaming: neste tópico, apresentamos uma visão geral das propriedades da Equipe
de NIC, como modos de balanceamento de carga e de equipe. Também lhe damos detalhes sobre a
configuração do adaptador Em espera e a propriedade de interface da equipe primária. Se você tiver pelo
menos dois adaptadores de rede em uma Equipe NIC, não será necessário designar um adaptador em
espera para tolerância a falhas.
Criar uma nova Equipe NIC em um computador host ou VM:neste tópico, você cria uma nova Equipe de
NIC em um computador host ou em uma VM (máquina virtual) Hyper-V em execução Windows Server
2016.
Solução de problemas de equipe NIC:neste tópico, discutiremos maneiras de solucionar problemas de
NIC Teaming, como hardware, com switch físico e desabilitando ou habilitando adaptadores de rede
usando Windows PowerShell.
 Criar uma nova equipe NIC em um computador
host ou VM
12/08/2021 • 9 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, você criará uma nova Equipe de NIC em um computador host ou em uma VM (máquina virtual)
hyper-V em execução Windows Server 2016.

Requisitos de configuração de rede

Antes de criar uma nova Equipe NIC, você deve implantar um host Hyper-V com dois adaptadores de rede que
se conectam a comutadores físicos diferentes. Você também deve configurar os adaptadores de rede com
endereços IP que são do mesmo intervalo de endereços IP.
Os requisitos de comutar físico, Comutar Virtual do Hyper-V, LAN (rede local) e NIC Teaming para criar uma
equipe de NIC em uma VM são:
O computador que executa o Hyper-V deve ter dois ou mais adaptadores de rede.
Se estiver conectando os adaptadores de rede a vários comutadores físicos, os comutadores físicos
deverão estar na mesma sub-rede da Camada 2.
Você deve usar o Gerenciador do Hyper-V ou Windows PowerShell para criar dois Comutadores Virtuais
externos do Hyper-V, cada um conectado a um adaptador de rede físico diferente.
A VM deve se conectar a ambos os comutadores virtuais externos que você criar.
O NIC Teaming, Windows Server 2016, dá suporte a equipes com dois membros em VMs. Você pode
criar equipes maiores, mas não há suporte.
Se você estiver configurando uma equipe de NIC em uma VM, deverá selecionar um modo de Equipe de
Opção Independente e um modo de balanceamento de carga do Hash de Endereço.

Etapa 1. Configurar a rede física e virtual

Neste procedimento, você cria dois Comutadores Virtuais externos do Hyper-V, conecta uma VM às opções e
configura as conexões de VM com os comutadores.
Pré -requisitos
Você deve ter associação em Administradores ou equivalente.
Procedimento
1. No host Hyper-V, abra o Gerenciador do Hyper-V e, em Ações, clique em Gerenciador de Comu switch
vir tual.
2. No Virtual Switch Manager, certifique-se de que Externo está selecionado e, em seguida, clique em
Criar Com switch vir tual.
3. Em Propriedades do Com switch virtual, digite um Nome para o comu switch virtual e adicione
Obser vações conforme necessário.
4. Em Tipo de conexão , em Rede externa , selecione o adaptador de rede física ao qual você deseja anexar
o comutor virtual.
5. Configure propriedades de opção adicionais para sua implantação e clique em OK.
6. Crie um segundo com switch virtual externo repetindo as etapas anteriores. Conexão a segunda opção
externa para um adaptador de rede diferente.
7. No Gerenciador do Hyper-V, em Máquinas Virtuais , clique com o botão direito do mouse na VM que
você deseja configurar e clique em Configurações .
A caixa de diálogo Configurações VM é aberta.
8. Verifique se a VM não foi iniciada. Se ele for iniciado, execute um desligamento antes de configurar a VM.
9. Em Hardware, clique em Adaptador de Rede .
10. Em Propriedades do Adaptador de Rede, selecione o primeiro comutor virtual que você criou nas
etapas anteriores e clique em Aplicar .
11. Em Hardware , clique para expandir o sinal de a mais (+) ao lado de Adaptador de Rede .
12. Clique em Recursos Avançados para habilitar o Teaming NIC usando a interface gráfica do usuário.

TIP
Você também pode habilitar o NIC Teaming com um Windows PowerShell comando:

Set-VMNetworkAdapter -VMName <VMname> -AllowTeaming On

a. Selecione Dinâmico para endereço MAC.

b. Clique para selecionar Rede protegida.
c. Clique para selecionar Habilitar este adaptador de rede para fazer parte de uma equipe no
sistema operacional convidado .
d. Clique em OK .
13. Para adicionar um segundo adaptador de rede, no Gerenciador do Hyper-V, em Máquinas Vir tuais,
clique com o botão direito do mouse na mesma VM e clique em Configurações .
A caixa de diálogo Configurações VM é aberta.
14. Em Adicionar Hardware, clique em Adaptador de Rede e, em seguida, clique em Adicionar .
15. Em Propriedades do Adaptador de Rede, selecione o segundo comutor virtual que você criou nas
etapas anteriores e clique em Aplicar .
16. Em Hardware , clique para expandir o sinal de a mais (+) ao lado de Adaptador de Rede .
17. Clique em Recursos Avançados , role para baixo até NIC Teaming e clique para selecionar Habilitar
este adaptador de rede para fazer parte de uma equipe no sistema operacional convidado .
18. Clique em OK .
Parabéns! Você configurou a rede física e virtual. Agora você pode prosseguir com a criação de uma nova
Equipe de NIC.

Etapa 2. Criar uma nova equipe NIC

Ao criar uma nova Equipe de NIC, você deve configurar as propriedades da Equipe de NIC:
Nome da equipe
Adaptadores de membro
Modo de agrupamento
Modo de balanceamento de carga
Adaptador em espera
Opcionalmente, você também pode configurar a interface de equipe principal e configurar um número de VLAN
(LAN virtual).
Para obter mais detalhes sobre essas configurações, consulte NIC Teaming settings.
Pré -requisitos
Você deve ter associação em Administradores ou equivalente.
Procedimento
1. No Gerenciador do Servidor, clique em Ser vidor Local .
2. No painel Propriedades, na primeira coluna, localize NIC Teaming e clique no link Desabilitado.
A caixa de diálogo NIC Teaming é aberta.

3. Em Adaptadores e Interfaces , selecione um ou mais adaptadores de rede que você deseja adicionar a
uma equipe de NIC.
4. Clique em TAREFAS e clique em Adicionar à Nova Equipe.
A caixa de diálogo Nova equipe é aberta e exibe adaptadores de rede e membros da equipe.
5. Em Nome da equipe , digite um nome para a nova Equipe NIC e clique em Propriedades adicionais .
6. Em Propriedades adicionais, selecione valores para:
Modo de equipe . As opções para o modo de Equipe são Alternar Independente e Mudar
Dependente. O modo Dependente do Comutamento inclui o Teaming Estático e o LACP
(Protocolo de Controle de Agregação de Vínculo).
Alternar Independente. Com o modo Switch Independent, a opção ou as opções para as
quais os membros da Equipe NIC estão conectados não estão cientes da presença da
equipe de NIC e não determinam como distribuir o tráfego de rede para membros da
Equipe NIC – em vez disso, a equipe NIC distribui o tráfego de rede de entrada entre os
membros da Equipe NIC.
Alternar Dependente. Com os modos dependentes de switch, o comutador ao qual os
membros da equipe NIC estão conectados determina como distribuir o tráfego de rede de
entrada entre os membros da equipe NIC. A opção tem uma independência completa para
 determinar como distribuir o tráfego de rede entre os membros da equipe da NIC.

M O DE DESC RIÇ Ã O

Teaming Estático Exige que você configure manualmente a opção e

o host para identificar quais links formam a
equipe. Como essa é uma solução configurada
estaticamente, não há nenhum protocolo
adicional para auxiliar a opção e o host a
identificar cabos conectados incorretamente ou
outros erros que podem causar falha na
execução da equipe. Normalmente, comutadores
de classe de servidor dão suporte para esse
modo.

Protocolo L ACP Ao contrário do Teaming Estático, o modo de

Equipe LACP identifica dinamicamente os links
que estão conectados entre o host e a opção.
Essa conexão dinâmica permite a criação
automática de uma equipe e, em teoria, mas
raramente na prática, a expansão e a redução de
uma equipe simplesmente pela transmissão ou
recebimento de pacotes LACP da entidade par.
Todas as opções de classe de servidor são
suportam LACP e todas exigem que o operador
de rede habilita administrativamente o LACP na
porta do comutador. Quando você configura um
modo de Teaming do LACP, o NIC Teaming
sempre opera no modo Ativo do LACP. Por
padrão, o NIC Teaming usa um temporizador
curto (3 segundos), mas você pode configurar
um temporizador longo (90 segundos) com
Set-NetLbfoTeam .

Modo de balanceamento de carga . As opções para o modo de distribuição do Balanceamento

de Carga são Hash de Endereço, Por ta hyper-V e Dinâmico.
Hash de endereço. Com o Hash de Endereço, esse modo cria um hash com base nos
componentes de endereço do pacote, que são atribuídos a um dos adaptadores disponíveis.
Normalmente, esse mecanismo sozinho é suficiente para criar um equilíbrio razoável entre
os adaptadores disponíveis.
Por ta do Hyper-V. Com a Porta do Hyper-V, os Teams NIC configurados em hosts Hyper-V
dão endereços MAC independentes às VMs. O endereço MAC das VMs ou a VM portada
conectada à opção Hyper-V pode ser usado para dividir o tráfego de rede entre os
membros da Equipe NIC. Não é possível configurar a NIC Teams que você cria em VMs com
o modo de balanceamento de carga de porta do Hyper-V. Em vez disso, use o modo Hash
de Endereço.
Dinâmico. Com Dinâmico, as cargas de saída são distribuídas com base em um hash das
portas TCP e endereços IP. O modo dinâmico também reequilibrar as cargas em tempo real
para que um determinado fluxo de saída possa se mover entre os membros da equipe. As
cargas de entrada, por outro lado, são distribuídas da mesma maneira que a Porta do
Hyper-V. Em resumo, o modo dinâmico utiliza os melhores aspectos do Hash de Endereço e
da Porta do Hyper-V e é o modo de balanceamento de carga de desempenho mais alto.
Adaptador em espera . As opções para Adaptador em Espera são Nenhum (todos os
adaptadores ativos) ou sua seleção de um adaptador de rede específico na Equipe de NIC que atua
como um adaptador em espera.
 TIP
Se você estiver configurando uma equipe de NIC em uma VM (máquina virtual), deverá selecionar um modo de
Equipe de Opção Independente e um modo de balanceamento de carga do Hash de Endereço.

7. Se você quiser configurar o nome da interface da equipe primária ou atribuir um número de VLAN à
Equipe NIC, clique no link à direita da interface da equipe primária .
A caixa de diálogo Nova interface de equipe é aberta.

8. Dependendo de seus requisitos, faça um dos seguintes:

Forneça um nome de interface tNIC.
Configurar associação À VLAN: clique em VL AN específica e digite as informações da VLAN. Por
exemplo, se você quiser adicionar essa Equipe de NIC à VLAN de contabilidade número 44, Digite
Contabilidade 44 – VLAN.
9. Clique em OK .
Parabéns! Você criou uma nova Equipe de NIC em um computador host ou VM.

Tópicos relacionados
NIC Teaming: neste tópico, apresentamos uma visão geral do NIC (Network Interface Card) Teaming in
Windows Server 2016. O NIC Teaming permite agrupar entre um e 32 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.
Uso e gerenciamento de endereços MAC de NIC Teaming:quando você configura uma equipe NIC com o
modo independente do comutamento e o hash de endereço ou a distribuição dinâmica de carga, a
equipe usa o endereço MAC (controle de acesso à mídia) do membro principal da Equipe de NIC no
tráfego de saída. O membro principal da Equipe NIC é um adaptador de rede selecionado pelo sistema
operacional do conjunto inicial de membros da equipe.
Configurações de NIC Teaming: neste tópico, apresentamos uma visão geral das propriedades da Equipe
de NIC, como modos de balanceamento de carga e de equipe. Também lhe damos detalhes sobre a
configuração do adaptador Em espera e a propriedade de interface da equipe primária. Se você tiver pelo
menos dois adaptadores de rede em uma Equipe NIC, não será necessário designar um adaptador em
espera para tolerância a falhas.
Solução de problemas de equipe NIC:neste tópico, discutiremos maneiras de solucionar problemas de
NIC Teaming, como hardware, com switch físico e desabilitando ou habilitando adaptadores de rede
usando Windows PowerShell.
 Solucionar problemas de agrupamento NIC
07/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, discutiremos maneiras de solucionar problemas de agrupamento NIC, como valores de hardware
e comutador físico. Quando as implementações de hardware de protocolos padrão não estão em conformidade
com as especificações, o desempenho de agrupamento NIC pode ser afetado. Além disso, dependendo da
configuração, o agrupamento NIC pode enviar pacotes do mesmo endereço IP com vários endereços MAC que
podem viajar recursos de segurança no comutador físico.

Hardware que não está em conformidade com a especificação

Durante a operação normal, o agrupamento NIC pode enviar pacotes do mesmo endereço IP, ainda com vários
endereços MAC. De acordo com os padrões de protocolo, os receptores desses pacotes devem resolver o
endereço IP do host ou da VM para um endereço MAC específico, em vez de responder ao endereço MAC do
pacote de recebimento. Os clientes que implementam corretamente os protocolos de resolução de endereço
(ARP e NDP) enviam pacotes com os endereços MAC de destino corretos, ou seja, o endereço MAC da VM ou
host que possui esse endereço IP.
Alguns hardwares incorporados não implementam corretamente os protocolos de resolução de endereço e
também podem não resolver explicitamente um endereço IP para um endereço MAC usando ARP ou NDP. Por
exemplo, um controlador SAN (rede de área de armazenamento) pode ser executado dessa maneira.
Dispositivos sem conformidade copiam o endereço MAC de origem de um pacote recebido e, em seguida,
usam-o como o endereço MAC de destino nos pacotes de saída correspondentes, o que resulta em pacotes
enviados para o endereço MAC de destino errado. Por isso, os pacotes são descartados pelo comutador virtual
do Hyper-V porque não correspondem a nenhum destino conhecido.
Se você estiver tendo problemas para se conectar a controladores SAN ou a outro hardware incorporado,
deverá fazer capturas de pacote para determinar se o hardware está implementando o ARP ou NDP
corretamente e entre em contato com seu fornecedor de hardware para obter suporte.

Recursos de segurança do comutador físico

Dependendo da configuração, o agrupamento NIC pode enviar pacotes do mesmo endereço IP com vários
endereços MAC de origem, liberando os recursos de segurança no comutador físico. Por exemplo, inspeção ARP
dinâmica ou proteção de origem IP, especialmente se o comutador físico não estiver ciente de que as portas
fazem parte de uma equipe, o que ocorre quando você configura o agrupamento NIC no modo independente
de comutador. Inspecione os logs de comutador para determinar se os recursos de segurança do comutador
estão causando problemas de conectividade.

Desabilitando e habilitando adaptadores de rede usando Windows

PowerShell
Um motivo comum para uma equipe NIC falhar é que a interface da equipe está desabilitada e, em muitos
casos, por acidente ao executar uma sequência de comandos. Essa sequência específica de comandos não
habilita todos os adaptadores de netdesabilitados porque desabilitar todos os membros físicos subjacentes de
NICs remove a interface de equipe da NIC.
Nesse caso, a interface de equipe NIC não é mais mostrada no Get-netadapter e, por isso, Enable-netadapter \
_ não HABILITA a equipe NIC. O comando _ Enable-netadapter \* * faz, no entanto, habilitar as NICs do membro,
que depois (após um curto período) recria a interface da equipe. A interface de equipe permanece no estado
"desabilitado" até que seja habilitada novamente, permitindo que o tráfego de rede comece a fluir.
a sequência de comandos a seguir Windows PowerShell pode desabilitar a interface de equipe por acidente:

Disable-NetAdapter *
Enable-NetAdapter *

Tópicos relacionados
Agrupamento NIC: neste tópico, fornecemos uma visão geral do agrupamento NIC (placa de interface de
rede) no Windows Server 2016. O agrupamento NIC permite que você agrupe entre um e 32
adaptadores de rede Ethernet físicos em um ou mais adaptadores de rede virtual baseados em software.
Esses adaptadores de rede virtual fornecem desempenho rápido e tolerância a falhas se um adaptador de
rede falhar.
Uso e gerenciamento de endereço MAC de agrupamento NIC: quando você configura uma equipe NIC
com o modo independente de comutador e o hash ou a distribuição de carga dinâmica, a equipe usa o
endereço MAC (controle de acesso à mídia) do membro da equipe NIC primário no tráfego de saída. O
membro da equipe NIC primário é um adaptador de rede que o sistema operacional seleciona do
conjunto inicial de membros da equipe.
Configurações de agrupamento NIC: neste tópico, fornecemos uma visão geral das propriedades da
equipe NIC, como os modos de agrupamento e balanceamento de carga. Também fornecemos detalhes
sobre a configuração do adaptador em espera e a propriedade da interface da equipe principal. Se você
tiver pelo menos dois adaptadores de rede em uma equipe NIC, não será necessário designar um
adaptador em espera para tolerância a falhas.
 Pktmon do monitor de pacotes ()
13/08/2021 • 5 minutes to read

aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows servidor 2019, Windows 10,
Hub de Azure Stack, Azure

O monitor de pacotes (Pktmon) é uma ferramenta de diagnóstico de rede entre componentes para Windows.
Ele pode ser usado para captura de pacotes, detecção de pacotes drop, filtragem de pacotes e contagem. A
ferramenta é especialmente útil em cenários de virtualização, como rede de contêineres e SDN, pois fornece
visibilidade dentro da pilha de rede. ele está disponível na caixa por meio do comando pktmon.exe e por meio
de extensões do centro de administração do Windows.

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 todos
os roteamentos e comutadores de pacotes ocorrem em dispositivos externos.

No entanto, com o advento da virtualização de rede, o tamanho da pilha de rede foi multiplicado. Essa pilha de
rede estendida agora inclui componentes como o comutador virtual que lida com o processamento e a
alternância de pacotes. Esse ambiente flexível permite uma maior utilização de recursos e isolamento de
segurança, 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 na pilha de rede que geralmente é necessária para
identificar esses erros.
O monitor de pacotes intercepta os pacotes em vários locais em toda a pilha de rede, expondo a rota do pacote.
Se um pacote foi descartado por um componente com suporte na pilha de rede, o monitor de pacotes relatará
esse descarte de pacotes. Isso permite que os usuários diferenciem entre um componente que é o destino
pretendido para um pacote e um componente que está interferindo com um pacote. Além disso, o monitor de
pacotes relatará os motivos de remoção; por exemplo, incompatibilidade de MTU ou VLAN filtrada, etc. Esses
motivos de eliminação 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 intercepção,
permitindo 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 a análise de rede.
Verifique a ajuda da linha de comando para obter argumentos e funcionalidades (por exemplo, pktmon Start
help).
Configure os filtros de pacote correspondentes ao seu cenário (pktmon filtro de adição).
Verifique os contadores de pacotes durante o experimento de exibição de alto nível (contadores de pktmon).
Examine o log para ver a análise detalhada (formato pktmon 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 pacotes Drop em vários locais de pilha
Filtragem de pacotes em tempo de execução flexível com suporte para encapsulamento
Suporte a 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 móvel de banda larga
Suporte ao formato PCAPNG

Introdução ao 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 na 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 de monitoramento de pacotes permite que você opere e consuma o Monitor de pacotes por meio do
centro de administração do Windows. 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 a entender sua saída.
extensão de diagnóstico de caminho de dados SDN no centro de administração Windows
o diagnóstico de caminho de dados sdn é uma ferramenta na extensão de monitoramento SDN do centro de
administração do Windows. A ferramenta automatiza 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 que é fácil de seguir e manipular.
Você pode usar este tópico para aprender a operar a ferramenta e a 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 Monitor de Rede da
Microsoft (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 o
Wireshark (ou qualquer analisador de pcapng). Este tópico explica a saída esperada e como aproveitá-la.

Fornecer comentários à equipe de engenharia

Relate quaisquer 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 o botão sugerir um recurso .
3. Forneça um título de feedback significativo na caixaresumir seu problema .
4. Forneça detalhes e etapas para reproduzir o problema na caixanos 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 emEnviar .
Depois de enviar o feedback/bug, a equipe de engenharia poderá dar uma olhada nos comentários e solucioná-
los.
 Formatação de comando Pktmon
13/08/2021 • 10 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure

O Monitor de Pacotes (Pktmon) é uma ferramenta de diagnóstico de rede entre componentes in-box para
Windows. Ele pode ser usado para captura de pacotes, detecção de soltar 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. O Monitor de Pacotes está disponível na caixa por meio do
comando pktmon.exe no Windows 10 e Windows Server 2019 (versão 1809 e posterior). Você pode usar este
tópico para saber como entender a sintaxe pktmon, a formatação de comando e a saída. Para ver uma lista
completa de comandos, consulte sintaxe pktmon.

Início rápido
Use as seguintes etapas para começar a usar 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.

C:\Test> pktmon filter add help

C:\Test> pktmon filter add <filters>

3. Inicie a captura e habilita o log de pacotes.

C:\Test> pktmon start -c

4. Reproduza o problema que está sendo diagnosticada. Contadores de consulta para confirmar a presença
do tráfego esperado e obter uma exibição de alto nível de como o tráfego fluia no computador.

C:\Test> pktmon counters

5. Pare a captura e recupere os logs no formato txt para análise.

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 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 barulhento para analisar. 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 ao mesmo tempo.
Por exemplo, o conjunto de filtros a seguir capturará qualquer tráfego ICMP de ou para o endereço IP 10.0.0.10,
bem como qualquer tráfego na porta 53.

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 distinguirá entre 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 para corresponder pode
ser fornecida. Os sinalizadores com suporte são FIN, SYN, RST, PSH, ACK, LTDA, 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:

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 o padrão é 4789.
Para obter mais informações, consulte sintaxe de filtro pktmon.

Captura de pacotes e eventos gerais

O Monitor de Pacotes pode capturar pacotes por meio do parâmetro [-c] com o comando start. Isso habilita a
captura de pacotes e o registro em log, bem como os contadores de pacotes. Para habilitar contadores de pacote
somente sem registrar o pacote em log, adicione o parâmetro [-o] ao comando start. 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]. Pode ser apenas NICs
ou uma lista de IDs de componente e assume como padrão todos os componentes. Você também pode filtrar
por status de propagação de pacotes (pacotes descartados ou fluindo) usando o parâmetro [--type].
Juntamente 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:

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:

C:\Test> pktmon start -c --comp 4,5 --type drop

Esse comando capturará pacotes e eventos de log do provedor "Microsoft-Windows-TCPIP":

C:\Test> pktmon start --capture --trace -p Microsoft-Windows-TCPIP

Funcionalidade de registro em log de pacotes

O Monitor de Pacotes dá suporte a vários modos de registro em log:
Circular: novos pacotes sobrescrevem os mais antigos quando o tamanho máximo do arquivo é
atingido. Esse é o modo de registro em 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 todo o log, mas tenha cuidado com a utilização do armazenamento.
Observação: use o timestamp de criação de arquivo de cada arquivo de log como uma indicação para
um período de tempo 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 grande quantidade de tráfego em um período muito curto no buffer de memória.
Usando outros modos de registro em log, algum tráfego pode ser perdido.
Especifique quanto do pacote deve ser log por meio do parâmetro [-p]. Registre o pacote inteiro de
cada pacote, independentemente do tamanho, definindo esse parâmetro como 0. O padrão é 128 bytes,
que devem incluir os headers 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 sobrescrever os
pacotes mais antigos com os mais novos. Esse também será o tamanho máximo de cada arquivo no
modo de registro em 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 sintaxe de início 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 no formato de texto (a opção padrão) e analise-o com uma ferramenta de 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 no formato pcapng para analisá-lo usando o Wireshark*
Abra o arquivo ETL com Monitor de Rede*

NOTE
*Use os hiperlinks acima para saber como analisar e analisar logs do Monitor de Pacotes no Wireshark e 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. Da mesma
forma, 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 de pacote começando com o timestamp. Logo após,
há pelo menos uma linha (em negrito na imagem abaixo) para mostrar o pacote bruto analisado no formato de
texto (sem um timestamp); 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çadas em amarelo); todos os instantâneos do mesmo pacote devem ter esses dois valores em comum. O
valor aparência (realçada 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) que denota 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 componentes
é mostrada na imagem abaixo realçando "Componente 1" em amarelo (esse era o componente em que o último
instantâneo acima foi capturado). Componentes com duas 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" aparece 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 para soltar o pacote; por exemplo,
incompatibilidade de MTU, VLAN filtrada, etc.

Contadores de pacotes
Os contadores de 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 depois de iniciar a captura do monitor de
pacotes. Redefina os contadores para zero usando pktmon Reset ou pare de monitorar todos juntos usando
pktmon Stop .
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: os componentes relatam a propagação de pacotes quando um pacote está ultrapassando o limite do
componente (borda). Cada componente pode ter uma ou mais bordas. Os drivers de miniporta normalmente
têm borda superior única, os protocolos têm borda inferior única e os drivers de filtro têm bordas superiores
e inferiores.
Quedas: os contadores de remoção de pacotes estão sendo relatados na mesma tabela.
No exemplo a seguir, uma nova captura foi iniciada, então o comando pktmon Counters foi usado para
consultar os contadores antes da interrupção da captura. Os contadores mostram um único pacote que o torna
fora da pilha de rede, começando da camada de protocolo até o adaptador de rede física e sua resposta volta na
outra direção. Se o ping ou a resposta estava ausente, é fácil detectá-lo por meio dos contadores.
No exemplo a seguir, os descartes são relatados na coluna "Counter". Recupere a última razão de descarte 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 nesses exemplos, os contadores podem fornecer muitas informações por meio de um
diagrama que pode ser analisado apenas com uma aparência rápida.
Para obter mais informações, consulte sintaxe de contadores de pktmon.

Layout de pilha de rede

Examine o layout da pilha de rede por meio da lista de pktmon de comando.
O comando mostra os componentes de rede (drivers) organizados por associações de adaptadores.
Uma associação típica consiste em:
Uma única placa de interface de rede (NIC)
Alguns (possivelmente zero) drivers de filtro
Um ou mais drivers de protocolo (TCP/IP ou outros)
Cada componente é identificado exclusivamente por uma ID de componente de monitor de pacotes, que é
usada para direcionar componentes individuais para monitoramento.

NOTE
As IDs não são persistentes e podem ser alteradas entre as reinicializações e as reinicializações do driver do monitor de
pacotes.

Para obter mais informações, consulte sintaxe da lista de pktmon.

 Extensão de monitoramento de pacotes no
Windows Admin Center
12/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure

A extensão monitoramento de pacotes permite que você opere e consuma o Monitor de Pacotes por meio
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)?

O Monitor de Pacotes (Pktmon) é uma ferramenta de diagnóstico de rede entre componentes in-box para
Windows. Ele pode ser usado para captura de pacotes, detecção de soltar 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.

O que é o Windows Admin Center?

Windows O Centro de Administração é uma ferramenta de gerenciamento baseada em navegador implantada
localmente que permite gerenciar seus servidores Windows sem dependência de nuvem ou do Azure. 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 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 usar.
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 pacote, 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 barulhento para analisar. Da
mesma forma, a extensão orienta você para o painel de filtros primeiro antes de iniciar a captura. Você pode
ignorar esta etapa clicando em Próximo para iniciar a captura 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 filtros mostrará o layout da pilha de rede para que você possa selecionar os componentes pelos
qual 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 da VLAN.
Quando dois MACs, IPs ou portas são especificados, a ferramenta não distinguirá entre origem ou
destino; ele capturará pacotes que têm ambos os valores, seja como um destino ou fonte. No entanto,
os filtros de exibição podem fazer essa distinção; consulte a seção Exibir filtros abaixo.
Para filtrar ainda mais os pacotes TCP, uma lista opcional de sinalizadores TCP para corresponder pode
ser fornecida. Os sinalizadores com suporte são FIN, SYN, RST, PSH, ACK, LTDA, ECE e CWR.
Se a caixa de encapsulamento estiver marcada, a ferramenta aplicará o filtro aos 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 de fluxo de pacote
O Monitor de Pacotes capturará pacotes em fluxo e descartados por padrão. Para capturar somente em
pacotes descartados, selecione Pacotes Descar tados.

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:
Timestamp, Sources IP Address, Source Port, Destination IP Address, Destination Port, Ethertype, Protocol, TCP
Flags, whether the packet was dropped, and the drop reason.
O timestamp para cada um desses pacotes também é um hiperlink que redireciona você para uma página
diferente, na qual você pode 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 para soltar e são exibidos
em texto vermelho para facilitar a localização.
Todas as guias podem ser ordenadas 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 mudam
conforme eles são processados por cada componente que passam.
Os instantâneos de pacote são agrupados por cada pilha de adaptador/comporte; Ou seja, instantâneos de
pacote capturados por um adaptador/com switch, seus drivers de filtro e seus drivers de protocolo serão
agrupados sob o nome do adaptador/opção. 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 headers de pacotes brutos.
Todos os pacotes descartados têm um valor "True" na guia Descartado, um motivo para soltar e são exibidos
em texto vermelho para facilitar a localizaçã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 após a aplicação 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 salvar 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 no computador local, você poderá salvá-lo em vários formatos:
Formato ETL que pode ser analisado usando Monitor de Rede da Microsoft. 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 Wireshark.
A maioria dos metadados do Monitor de Pacotes será perdida durante essa conversão. Confira 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
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure

O Diagnóstico de Caminho de Dados SDN é uma ferramenta dentro da extensão de monitoramento SDN do
Centro de Administração do Windows que automatiza capturas de pacotes baseadas no Monitor de Pacotes de
acordo com vários cenários de SDN e apresenta a saída em uma única exibição que é fácil de seguir e manipular.

O que é o Monitor de Pacotes (Pktmon)?

O Monitor de Pacotes (Pktmon) é uma ferramenta de diagnóstico de rede entre componentes in-box para
Windows. Ele pode ser usado para captura de pacotes, detecção de soltar pacotes, filtragem de pacotes e
contagem. 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.

O que é o Windows Admin Center?

Windows O Centro de Administração é uma ferramenta de gerenciamento baseada em navegador implantada
localmente que permite gerenciar seus servidores Windows sem dependência de nuvem ou do Azure. 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 ao Windows Admin Center:
1. Clique em + Adicionar em Todas as Conexões .
2. Escolha adicionar uma conexão Hyper-Converged cluster.
3. Digite o nome do cluster e, se solicitado, as credenciais a usar.
4. Marque 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, para a extensão
"Monitoramento de SDN" e, em seguida, para a guia "Diagnóstico de 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
diagnosticada.

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 que as consultas executem uma captura bem-sucedida, sem nenhuma
intervenção do usuário para descobrir o fluxo de pacotes esperado, os máquinas envolvidas no cenário, sua
localização no cluster ou os filtros de captura a aplicar em cada computador. Os parâmetros obrigatórios
permitem que a captura seja executado 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 máquinas em que a captura está iniciando. Você
poderá ser solicitado a entrar nesses máquinas se suas credenciais não foram salvas. Você pode começar
reproduzindo o ping ou o problema que está tentando diagnosticar capturando os pacotes relativos. Depois que
os pacotes são capturados, a extensão mostrará marcas ao lado dos máquinas em que os pacotes foram
capturados.

Depois de interromper a captura, os logs de todos os máquinas serão mostrados em uma única página, dividida
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:
Timestamp, Sources IP Address, Source Port, Destination IP Address, Destination Port, Ethertype, Protocol, TCP
Flags, whether the packet was dropped, and the drop reason.
O timestamp para cada um desses pacotes também é um hiperlink que redireciona você para uma página
diferente, na qual você pode 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 para soltar e são exibidos
em texto vermelho para facilitar a localização.
Todas as guias podem ser ordenadas 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 de propagação de pacotes
incorretos 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 sobre ele são
agrupados pelo nome do adaptador. Isso facilita o controle 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 facilitar a localização.
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 verifica
se há problemas de configuração incompatibilidade.

Scroll down 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 após a aplicação 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 posterior 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 Monitor de Rede da Microsoft. 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 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 a Pktmon para Monitor de Rede da
Microsoft (Netmon)
07/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure

O Monitor de Pacotes (Pktmon) gera logs no formato ETL. Esses logs podem ser analisados usando Monitor de
Rede da Microsoft (Netmon) usando analisadores especiais. Este tópico explica como analisar arquivos ETL
gerados pelo Monitor de Pacotes no Netmon.

Monitor de Rede configuração e configuração

Siga estas etapas para instalar e configurar o Netmon para analisar arquivos ETL gerados pelo Monitor de
Pacotes:
1. Instale Monitor de Rede 3.4.
2. Inicie Monitor de Rede elevado e de Windows como Perfil do analisador ativo em
(Ferramentas/Opções/Perfis do Analisador).
3. Copie etl_Microsoft-Windows-PktMon-Events.npl daqui para "%PROGRAMDATA%\Microsoft\Monitor de
Rede 3\NPL\NetworkMonitor Parsers\Windows"
4. Copie stub_etl_Microsoft-Windows-PktMon-Events.npl daqui para "%PROGRAMDATA%\Microsoft\Monitor
de Rede 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\Monitor de Rede 3\NPL\NetworkMonitor Parsers"
7. Reinicie Monitor de Rede elevado para recriar os analisadores.
 Suporte a Pktmon para Wireshark (pcapng)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Server 2019, Windows 10,
Azure Stack Hub, Azure

O Monitor de Pacotes (Pktmon) pode converter logs no 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 pcapng Pktmon

Use os comandos a seguir para converter a captura pktmon no formato pcapng.

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 rebaixamento de pacotes e o fluxo de pacotes pela pilha de rede
serão perdidas na saída pcapng. Portanto, o conteúdo do log deve ser cuidadosamente pré-filtrado para essa
conversão. Por exemplo:
O formato Pcapng não faz distinção entre um pacote de fluxo 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 esse comando para cada conjunto de IDs de componente em
que você está interessado.
 Qualidade da ( política de QoS de serviço )
13/08/2021 • 7 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

NOTE
Além deste tópico, a documentação de 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 de usuário ou a um computador como parte de um
GPO de Política de Grupo objeto ( ) que você vinculou a um contêiner de Active Directory, como um domínio,
site ou UO da unidade organizacional ( ) .
O gerenciamento de tráfego de QoS ocorre abaixo da camada de aplicativo, o que significa que os aplicativos
existentes não precisam ser modificados para se beneficiarem 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 de computadores ou usuários com os
seguintes sistemas operacionais da Microsoft.
Windows Server 2016
Windows 10
Windows Server 2012 R2
Windows 8.1
Windows Server 2012
Windows 8
Windows Server 2008 R2
Windows 7
Windows Server 2008
Windows Vista
Local da política de QoS no Política de Grupo
no Windows Server 2016 Editor de Gerenciamento de Política de Grupo, o caminho para a política de QoS para
a configuração do computador é o seguinte.
Política de domínio padrão | Configuração do computador | Políticas | Windows Configurações | -
QoS baseada em política
Esse caminho é ilustrado na imagem a seguir.
no Windows Server 2016 Editor de Gerenciamento de Política de Grupo, o caminho para a política de QoS para
a 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
baseada 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 balancear o desempenho da rede
com o custo de serviço, mas o tráfego de rede normalmente não é fácil de priorizar e gerenciar.
Em sua rede, - os aplicativos críticos de missão crítica e - de latência devem competir pela largura de banda da
rede em relação ao tráfego de prioridade mais baixa. Ao mesmo tempo, alguns usuários e computadores com
requisitos de desempenho de rede específicos podem exigir níveis de serviço diferenciados.
Os desafios de fornecer níveis de desempenho de rede previsíveis e econômicos geralmente aparecem em
conexões WAN de rede de longa distância ( ) ou com aplicativos sensíveis à latência, como VoIP de voz sobre IP (
) e streaming de vídeo. No entanto, a meta final de fornecer níveis de serviço de rede previsíveis se aplica a
qualquer ambiente ( de rede, por exemplo, a uma rede de área local ) das empresas e a mais de aplicativos VoIP,
como a linha - de aplicativos de negócios personalizada da sua empresa - .
A QoS baseada em políticas é a ferramenta de gerenciamento de largura de banda de rede que fornece controle
de rede baseado em aplicativos, usuários e computadores.
Quando você usa a política de QoS, seus aplicativos não precisam ser escritos para APIs de interfaces de
programação de aplicativo específicas ( ) . Isso lhe dá a capacidade de usar QoS com aplicativos existentes. Além
disso, a QoS baseada em políticas aproveita sua infraestrutura de gerenciamento existente, pois a QoS baseada
em políticas é incorporada ao Política de Grupo.

Definir a prioridade de QoS por meio de um DSCP de ponto de

código serviços diferenciados ()
Você pode criar políticas de QoS que definem a prioridade de tráfego de rede com um valor de DSCP de ponto
de código serviços diferenciados ( ) que você atribui a diferentes tipos de tráfego de rede.
O DSCP permite aplicar um valor ( 0 – 63 ) dentro do tipo de ( campo Service tos ) no cabeçalho de um pacote
IPv4 e dentro do campo classe de tráfego no IPv6.
O valor de DSCP fornece a classificação de tráfego de rede no nível de IP do protocolo de Internet ( ) , que os
roteadores usam para decidir o comportamento do 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 esforço.
O tráfego de rede de missão crítica, que está na fila de alta prioridade, tem preferência sobre outro tráfego.
Limitar o uso de largura de banda de rede por aplicativo com taxa de aceleraçã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 os limites de limitação determina a taxa de tráfego de rede de saída. Por
exemplo, para gerenciar os custos de 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 de DSCP e taxas de limitação
Você também pode usar a política de QoS para aplicar valores de DSCP e taxas de limitação para o tráfego de
rede de saída para o seguinte:
Enviando o caminho do aplicativo e do diretório
Endereços IPv4 ou IPv6 de origem e de destino ou prefixos de endereço
Protocolo-protocolo ( TCP ) e UDP do protocolo de datagrama do usuário ()
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 de QoS com um valor DSCP de 46 para um
aplicativo VoIP, permitindo que 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 de 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 oferece as seguintes vantagens.
1. Nível de detalhe: É 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 comutador ou portas de roteador fixos, como
costuma ser o caso com computadores portáteis. Por outro lado, a política de QoS torna mais fácil
configurar uma - política de QoS de nível de usuário em um controlador de domínio e propagar 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 - as
políticas de QoS de nível de usuário, a política de QoS é aplicada em qualquer dispositivo compatível em
qualquer local em que o usuário fizer logon.
3. Segurança: Se o seu departamento de ti criptografar o tráfego dos usuários de ponta a ponta usando
IPsec de segurança de protocolo Internet ( ) , você não poderá classificar o tráfego em roteadores com
base em qualquer informação acima da camada IP no pacote ( , por exemplo, uma porta TCP ) . No
entanto, usando a política de QoS, você pode classificar os pacotes no dispositivo final para indicar a
prioridade dos pacotes no cabeçalho IP antes que as cargas de IP sejam criptografadas e que os pacotes
sejam enviados.
4. Desempenho: Algumas funções de QoS, como a limitação, são mais bem executadas quando estão mais
perto da origem. A política de QoS move essas funções de QoS mais próximas da origem.
5. Capacidade de gerenciamento: A política de QoS aprimora a capacidade de gerenciamento de rede
 de duas maneiras:
a . Como ele se baseia 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
do 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 do localizador de recursos uniforme ( ) 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 baseada no endereço IP de cada servidor.
Para o próximo tópico deste guia, consulte introdução com a política de QoS.
 Introdução com a política de QoS
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar os tópicos a seguir para começar com a qualidade da ( política de QoS 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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Ao iniciar ou obter a configuração atualizada do usuário ou do computador Política de Grupo configurações de

QoS, ocorre o seguinte processo.
1. O mecanismo de Política de Grupo recupera as configurações de Política de Grupo do usuário ou do
computador de Active Directory.
2. O mecanismo de Política de Grupo informa a extensão de Client-Side de QoS de que houve alterações
nas políticas de QoS.
3. A extensão de Client-Side de 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 inspeção de QoS recupera as políticas de QoS de usuário ou computador e as armazena.
Quando uma nova conexão TCP do ponto de extremidade da camada de transporte ( ou o tráfego UDP ) é
criado, ocorre o processo a seguir.
1. O componente da camada de transporte da pilha TCP/IP informa o módulo inspeção de QoS.
2. O módulo 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 entrará Pacer.sys para criar um
fluxo, uma estrutura de dados que contém o valor DSCP e as configurações de limitação de tráfego da
política de QoS correspondente. Se houver várias políticas de QoS que correspondam 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 inspeção de QoS retorna o número de fluxo para a camada de transporte.
6. A camada de transporte armazena o número do 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, ocorre o processo a seguir.
1. A camada de transporte marca internamente o pacote com o número do fluxo.
2. A camada de rede consulta 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 de classe do tráfego IPv4 ou do protocolo IPv6 para o valor DSCP
especificado por Pacer.sys e, para pacotes IPv4, calcula a soma de verificação do cabeçalho IPv4 final.
5. A camada de rede entrega o pacote à camada de enquadramento.
6. Como o pacote foi marcado com um número de fluxo, a camada de enquadramento distribui o pacote
para Pacer.sys por meio do NDIS 6. x.
7. Pacer.sys usa o número de fluxo do pacote para determinar se o pacote precisa ser limitado e, em caso
afirmativo, agenda o pacote para envio.
8. Pacer.sys distribui o pacote imediatamente se não houver ( limitação de tráfego ) ou conforme agendado
( se houver limitação de tráfego ) para o NDIS 6. x para transmissão no adaptador de rede apropriado.
Esses processos de QoS baseado 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
de camada por transporte, em vez de por pacote.
Não há impacto no desempenho do tráfego que não corresponde a uma política de QoS.
Os aplicativos não precisam ser modificados para tirar proveito do serviço diferenciado baseado em
DSCP ou da limitação de tráfego.
As políticas de QoS podem ser aplicadas ao tráfego protegido com IPsec.
Para o próximo tópico deste 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar este tópico para saber mais sobre a arquitetura da Política de QoS.
A figura a seguir mostra a arquitetura da QoS baseada em políticas.

A arquitetura da QoS baseada em políticas consiste nos seguintes componentes:

Política de Grupo Cliente do . Um Windows que gerencia as configurações de usuário e computador
Política de Grupo configurações.
Política de Grupo mecanismo . Um componente do serviço cliente Política de Grupo que recupera as
configurações de usuário e computador Política de Grupo do Active Directory na inicialização e verifica
periodicamente se há alterações por padrão, a cada ( 90 ) minutos. Se as alterações são detectadas, o
Política de Grupo recupera as novas Política de Grupo configurações. O 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 do QoS . Um componente do serviço cliente Política de Grupo que
aguarda uma indicação do mecanismo Política de Grupo 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 de
Filtragem.
Inspeção de QoS . Módulo Um componente dentro da pilha TCP/IP que aguarda indicações de
alterações de política de QoS da Extensão do Lado do Cliente QoS, recupera as configurações de política
de 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 de modo kernel e o sistema operacional em
sistemas operacionais Windows Server e Client. O NDIS 6.x dá suporte a filtros leves, que é um modelo
de driver simplificado para drivers intermediários NDIS e miniportes que proporcionam melhor
desempenho.
Interface do provedor de rede QoS ( NPI ) . Uma interface para drivers de 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íticas e para o tráfego de aplicativos que usam as APIs genéricas de QoS GQoS e TC de controle de
( ) ( ) tráfego. 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 o primeiro tópico deste guia, consulte Política de QoS (Qualidadede Serviço).
 Cenários de política de QoS
13/08/2021 • 10 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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

NOTE
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 do 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.

NOTE
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 (Qualidadede 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 QoS é um aplicativo ERP de
planejamento de recursos de toda - - a Enterprise ( ) empresa. O aplicativo ERP é hospedado em vários
computadores que estão executando Windows Server 2016. No Active Directory Domain Services, esses
computadores são membros de uma UO de unidade da organização que foi criada para servidores de
aplicativos LOB de 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 Política de Grupo objeto 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.

NOTE
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.

A P L IC A DO À S
TA XA DE UN IDA DES DA
N O M E DE P O L ÍT IC A VA LO R DSC P A C EL ERA Ç Ã O O RGA N IZ A Ç Ã O DESC RIÇ Ã O

[Sem política] 0 Nenhum [Sem implantação] Melhor esforço

(padrão) para tráfego
não classificado.

Dados de backup 1 Nenhum Todos os clientes Aplica um valor DSCP

de baixa prioridade
para esses dados em
massa.
 A P L IC A DO À S
TA XA DE UN IDA DES DA
N O M E DE P O L ÍT IC A VA LO R DSC P A C EL ERA Ç Ã O O RGA N IZ A Ç Ã O DESC RIÇ Ã O

LOB do servidor 44 Nenhum UO do computador Aplica DSCP de alta

para servidores ERP prioridade para
tráfego de servidor
ERP

LOB do cliente 60 Nenhum Grupo de usuários Aplica DSCP de alta

financeiros prioridade para
tráfego de cliente
ERP

NOTE
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 o DSCP ( RFC 2474. ) Para obter
mais informações, consulte RFC 2474.
Os requisitos de credenciais administrativas são atendidos.
Credenciais administrativas
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.

NOTE
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 Política de Grupo objeto ( 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 para 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. Porém, ao especificar o tráfego, em vez de fornecer o nome do aplicativo, você
só inserirá a URL para a qual seu aplicativo de servidor HTTP responderá: por exemplo, https://hrweb/training .

NOTE
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.
Para o primeiro tópico deste guia, consulte Política de QoS (Qualidadede Serviço).
 Gerenciar política de QoS
13/08/2021 • 20 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

NOTE
Além deste tópico, a documentação de gerenciamento de política de QoS a seguir está disponível.
Eventos e erros da política de QoS

em sistemas operacionais Windows, a política de QoS combina a funcionalidade de QoS baseada em padrões
com a capacidade de gerenciamento de Política de Grupo. A configuração dessa combinação torna o aplicativo
fácil de políticas de QoS para Política de Grupo objetos. o 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 de DSCP
Taxa de limitação
Priorizando o tráfego com DSCP
Conforme observado no 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 valores de 0 a 63 sejam especificados dentro do campo
TOS de um pacote IPv4 e dentro do campo classe de tráfego no IPv6. Os roteadores de rede usam o valor DSCP
para classificar os pacotes de rede e enfileirar-los adequadamente.

NOTE
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 crítico para os negócios, 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 de chave para gerenciar a largura de banda da rede.
Conforme mencionado anteriormente, você pode usar a configuração especificar taxa de restrição para
configurar uma política de QoS com uma taxa de limitaçã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 para 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.

NOTE
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 objeto de Política de Grupo (GPO) de dentro da
ferramenta Console de Gerenciamento de Política de Grupo (GPMC). Em seguida, o GPMC abre a 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 na configuração do computador \ Windows Configurações política \QoS se aplica a
computadores, independentemente do usuário que estiver conectado no momento. Normalmente, você
usa políticas de QoS baseadas no computador em servidores.
uma política de QoS na configuração do usuário \ Windows Configurações política \QoS se aplica aos
usuários depois que eles tiverem feito logon, independentemente de em qual computador eles fizeram
logon.
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 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 a política de
forma exclusiva.
2. Opcionalmente, use especificar valor DSCP para habilitar a marcação DSCP e, em seguida, 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 limitação deve ser maior que 1 e você pode especificar unidades de
kilobytes por segundo, ( kbps ) ou megabytes por segundo ( Mbps ) .
4. Clique em Próximo .
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 pelo nome do executável, para um caminho e nome de aplicativo, ou
para os aplicativos de servidor HTTP que lidam com solicitações de uma URL específica.
Todos os aplicativos especifica 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 ser vidor http respondendo a solicitações para esta URL especifica que
as configurações de gerenciamento de tráfego na primeira página do assistente de política de QoS se
aplicam apenas 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.

NOTE
O caminho do aplicativo não pode incluir um caminho que resolva um link simbólico.

A URL deve estar em conformidade com a RFC 1738, na forma de http[s]://<hostname\>:<port\>/<url-path> .

Você pode usar um caractere curinga, ‘*' , para <hostname> e/ou <port> , por exemplo
https://training.\*/, https://\*.\* ,, mas o curinga não pode indicar uma subcadeia de caracteres de
<hostname> ou <port> .

Em outras palavras, nem https://my\*site/ nem https://\*training\*/ é válido.

Opcionalmente, você pode selecionar incluir subdiretórios e arquivos para executar correspondência em
todos os subdiretó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á as solicitações para https://training/video uma boa
correspondência.
Para configurar a página nome do aplicativo do assistente de política de QoS
1. Nesta política de QoS aplica-se a , 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.
3. Clique em Próximo .
Página 3-endereços IP do assistente
Na terceira página do assistente de política de QoS, você pode especificar as 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 ambos apenas para o endereço IP de origem a seguir e apenas 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 da política de QoS nesta página do assistente está esmaecido.
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. Nesta política de QoS aplica-se a (origem), selecione qualquer endereço IP de origem ou apenas
para o endereço de origem IP a seguir .
2. Se você selecionou apenas o endereço de origem IP a seguir , especifique um endereço ou prefixo
IPv4 ou IPv6.
3. Nesta política de QoS aplica-se a (destino), selecione qualquer endereço de destino ou apenas
para o endereço IP de destino a seguir.
4. Se você selecionou apenas para o endereço IP de destino a seguir , especifique um endereço IPv4
ou IPv6 ou prefixo que corresponda ao tipo de endereço ou prefixo especificado para o endereço de
origem.
5. Clique em Próximo .
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 por ta de origem , selecione De qualquer por ta de origem ou Deste
número de por ta de origem .
3. Se você selecionou a par tir desse número de por ta de origem , digite um número de porta entre 1 e
65535.
Opcionalmente, você pode especificar um intervalo de portas, no formato "baixo:alto", onde baixo e alto
representam os limites inferiores e 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 por ta de destino , selecione Para qualquer por ta de destino ou
Para este número de por ta de destino .
5. Se você selecionou Para este número de por ta 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 por tas do
assistente de política de QoS. Quando concluído, 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 em 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
que são 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 da 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 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 detalhes da 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 da Editor de Objeto de
Política de Grupo e clique em excluir política .
Relatórios GPMC de política de QoS
Depois de ter aplicado uma série de políticas de QoS em sua organização, pode ser útil ou necessário examinar
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 os relatórios do GPMC.
Para executar o assistente de resultados de Política de Grupo 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 Assistente de política de grupo de resultados.
depois que os resultados da Política de Grupo forem gerados, clique na guia Configurações . na guia
Configurações , as políticas de QoS podem ser encontradas nos nós "configuração do computador \ Windows
Configurações política \QoS" e "configuração do usuário \ Windows Configurações política \QoS".
na guia Configurações , as políticas de qos são listadas por seus nomes de política de qos com o valor DSCP, a
taxa de aceleração, as condições de política e o GPO vencedor listado na mesma linha.
A exibição de resultados de Política de Grupo 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. As políticas de QoS conflitantes (identificadas pelo nome da política) que estão
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 limitação e as condições de política também são visíveis em Editor de
Objeto de Política de Grupo (GPOE)
Configurações avançadas para roaming e usuários remotos
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 para dentro ou para fora da rede corporativa. como as políticas de qos
não são relevantes enquanto estão longe da rede da empresa, as políticas de qos são habilitadas somente em
interfaces de rede que estão conectadas à empresa para Windows 8, Windows 7 ou Windows Vista.
Por exemplo, um usuário pode conectar seu computador portátil à rede da sua empresa por meio da VPN (rede
virtual privada) de uma cafeteria. Para VPN, a 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 mais tarde inserir outra rede da 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 às cargas de trabalho do servidor. Por exemplo, um servidor
com vários adaptadores de rede pode se sentar na borda da rede de uma empresa. O departamento de ti pode
optar por ter políticas de QoS para limitar o tráfego que egresso a empresa; no entanto, esse adaptador de rede
que envia esse tráfego de saída não necessariamente se conecta de volta à rede corporativa. Por esse motivo, as
políticas de QoS sempre são habilitadas em todas as interfaces de rede de um computador que executa o
Windows Server 2012.

NOTE
A habilitação seletiva só se aplica a políticas de QoS e não às configurações de QoS avançadas discutidas a seguir neste
documento.

Configurações de QoS avançadas

As configurações de QoS avançadas fornecem controles adicionais para que os administradores de ti gerenciem
o consumo de rede do computador e marcações DSCP. As configurações de QoS avançadas aplicam-se somente
ao 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 de QoS avançadas
1. clique em configuração do computador e, em seguida, clique em 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 Configurações de qos
avançados .
A figura a seguir mostra as duas guias configurações avançadas de QoS: tráfego TCP de entrada e
substituição de marcação DSCP .

NOTE
os Configurações de QoS avançados são configurações de Política de Grupo no nível do computador.

Configurações de QoS avançadas: tráfego TCP de entrada

O tráfego TCP de entrada controla o consumo de largura de banda TCP no lado do destinatário, 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 menor na guia tráfego TCP de entrada , o TCP limitará o tamanho
de sua janela de recebimento TCP anunciada. O efeito dessa configuração aumentará as taxas de taxa de
transferência e a utilização de links para conexões TCP com larguras de banda ou latências maiores (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 recepção TCP foi alterada em 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
limitaram a janela do lado do recebimento TCP a um máximo de 64 kilobytes (KB), enquanto Windows Server
2012, Windows 8, Windows server 2008 R2, Windows server 2008 e Windows Vista dimensionam
dinamicamente a janela do lado do recebimento até 16 megabytes (MB). No controle de tráfego TCP de entrada,
você pode controlar o nível de taxa de transferência de entrada definindo o valor máximo para o qual a janela
de recepção TCP pode crescer. Os níveis correspondem aos valores máximos a seguir.

N ÍVEL DE TA XA DE T RA N SF ERÊN C IA DE EN T RA DA M Á XIM O

0 64 KB

1 256 KB

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 da rede.
P a ra d e f i n i r a j a n e l a d o l a d o d e re c e b i me n t o TC P

1. em 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
Configurações de qos avançado .
2. Em TCP recebendo taxa de transferência , selecione Configurar taxa de transferência de
recebimento de TCP e, em seguida, selecione o nível de taxa de transferência desejado.
3. Vincule o GPO à UO.
Configurações de QoS avançadas: substituição de marcação DSCP
A substituição de marcação DSCP restringe a capacidade dos aplicativos de especificar — ou "marcar" —
valores de DSCP diferentes daqueles especificados nas políticas de QoS. Ao especificar 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, os 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 de DSCP; aplicativos e dispositivos que não usam as
APIs de QoS não são substituídos.
Va l o r e s d e m u l t i m í d i a e d e D SC P se m fi o

A Wi-Fi Alliance estabeleceu uma certificação para WMM de multimídia sem fio ( ) que define quatro categorias
( de acesso WMM_AC ) para priorizar o tráfego de rede transmitido em uma - rede sem fio Wi-Fi. As categorias
de acesso incluem para a ( prioridade mais alta para a mais baixa ) : voz, vídeo, melhor esforço e plano de fundo;
respectivamente abreviados como vo, vi, ser e BK. A especificação WMM define quais valores de DSCP
correspondem a cada uma das quatro categorias de acesso:

VA LO R DE DSC P C AT EGO RIA DE A C ESSO DO W M M

48-63 Voz (VO)

32-47 Vídeo (VI)

24-31, 0-7 Melhor esforço (ser)

 VA LO R DE DSC P C AT EGO RIA DE A C ESSO DO W M M

8-23 Segundo plano (BK)

Você pode criar políticas de QoS que usam esses valores de DSCP para garantir que computadores portáteis
com - ™ de Certificação Wi-Fi para adaptadores sem fio WMM recebam tratamento priorizado quando
associados a Wi - Fi CERTIFIED para pontos de acesso do 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, somente 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 o local em que as taxas de limitaçã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 a rede quintuple; e entre a rede quintuple.
Por quintuple de rede, 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 de nível de 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 em conflito definidas, porque, se houver um conflito, a política de nível de usuário
sempre terá precedência.

NOTE
Uma política de QoS de nível de 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 ter precedência sobre a rede quintuple

Quando várias políticas de QoS correspondem ao tráfego específico, a política mais específica é 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 a rede quintuple para
encontrar a melhor correspondência.
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 rede quintuple, 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 entram ( em conflitoapp.exe envia o tráfego para um
endereço IP dentro do intervalo de 192.168.4.0/24 ) , policy_A é aplicado.
Mais especificidades têm precedência na rede quintuple
Para conflitos de política dentro da rede quintuple, a política com a maioria das condições de correspondência
tem precedência. Por exemplo, suponha que 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 que 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 corresponder
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 (mas não a mesma) parte da rede quintuple. Entre a rede quintuple, a ordem a seguir é
de maior ou menor precedência:
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 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 deste guia, consulte eventos e erros de política de QoS.
Para o primeiro tópico deste guia, consulte política de QoS (qualidade de serviço).
 Mensagens de evento e erro de política de QoS
07/08/2021 • 7 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

A seguir estão as mensagens de erro e de evento associadas à Política de QoS.

Mensagens informativas
A seguir está uma lista de mensagens informativas da Política de QoS.

AT RIB UTO VA LO R

MessageId 16500

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_MACHINE_POLICY_REFRESH_NO_CHAN
GE

Idioma Inglês

Message Políticas de QoS do computador atualizadas com êxito.

Nenhuma alteração detectada.

AT RIB UTO VA LO R

MessageId 16501

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_MACHINE_POLICY_REFRESH_WITH_CH
ANGE

Idioma Inglês

Message Políticas de QoS do computador atualizadas com êxito.

Alterações de política detectadas.

AT RIB UTO VA LO R

MessageId 16502

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_USER_POLICY_REFRESH_NO_CHANGE

Idioma Inglês
AT RIB UTO VA LO R

Message Políticas de QoS do usuário atualizadas com êxito. Nenhuma

alteração detectada.

AT RIB UTO VA LO R

MessageId 16503

Gravidade Informativo

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.

AT RIB UTO VA LO R

MessageId 16504

Gravidade Informativo

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.

AT RIB UTO VA LO R

MessageId 16505

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_OFF

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 da configuração é Nível 0 (taxa de transferência
mínima).

AT RIB UTO VA LO R

MessageId 16506
AT RIB UTO VA LO R

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_HIGHLY_RESTRICTE
D

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 da configuração é Nível 1.

AT RIB UTO VA LO R

MessageId 16507

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_RESTRICTED

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 da configuração é Nível 2.

AT RIB UTO VA LO R

MessageId 16508

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_TCP_AUTOTUNING_NORMAL

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 da configuração é Nível 3 (produtividade máxima).

AT RIB UTO VA LO R

MessageId 16509

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_APP_MARKING_NOT_CONFIGURED

Idioma Inglês
 AT RIB UTO VA LO R

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.

AT RIB UTO VA LO R

MessageId 16510

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_APP_MARKING_IGNORED

Idioma Inglês

Message A Configuração avançada de QoS para marcação DSCP

substitui as 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.

AT RIB UTO VA LO R

MessageId 16511

Gravidade Informativo

SymbolicName EVENT_EQOS_INFO_APP_MARKING_ALLOWED

Idioma Inglês

Message A Configuração avançada de QoS para marcação DSCP

substitui as substituições atualizadas com êxito. Os
aplicativos podem definir valores DSCP independentemente
das políticas de QoS.

AT RIB UTO VA LO R

MessageId 16512

Gravidade Informativo

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.

AT RIB UTO VA LO R

MessageId 16600

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_TEST_1

Idioma Inglês

Message EQOS: **_Testing [, com uma cadeia _ * * de caracteres] "%2".

AT RIB UTO VA LO R

MessageId 16601

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_TEST_2

Idioma Inglês

Message EQOS: **_Testing [, com duas cadeias de _ * * caracteres,

string1 é] "%2"[, string2 is] "%3".

AT RIB UTO VA LO R

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.

AT RIB UTO VA LO R

MessageId 16603

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_VERSION

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.
AT RIB UTO VA LO R

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.

AT RIB UTO VA LO R

MessageId 16605

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_PROFILE_NOT_SPEC
IFIED

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.

AT RIB UTO VA LO R

MessageId 16606

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_QUOTA_EXCEE
DED

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.

AT RIB UTO VA LO R

MessageId 16607

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_QUOTA_EXCEEDED
AT RIB UTO VA LO R

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.

AT RIB UTO VA LO R

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.

AT RIB UTO VA LO R

MessageId 16609

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_CONFLICT

Idioma Inglês

Message A política de QoS de usuário "%2" pode estar em conflito

com outras políticas de QoS. Consulte a documentação para
obter regras sobre qual política será aplicada.

AT RIB UTO VA LO R

MessageId 16610

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_MACHINE_POLICY_NO_FULLPATH
_APPNAME

Idioma Inglês

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 de rede mapeada.
 AT RIB UTO VA LO R

MessageId 16611

Gravidade Aviso

SymbolicName EVENT_EQOS_WARNING_USER_POLICY_NO_FULLPATH_APP
NAME

Idioma Inglês

Message A política de QoS de 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 de rede mapeada.

Mensagens de erro
A seguir está uma lista de mensagens de erro de política de QoS.

AT RIB UTO VA LO R

MessageId 16700

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_REFERESH

Idioma Inglês

Message Falha ao atualizar as políticas de QoS do computador. Código

de erro: "%2".

AT RIB UTO VA LO R

MessageId 16701

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_USER_POLICY_REFERESH

Idioma Inglês

Message Falha ao atualizar as políticas de QoS de usuário. Código de

erro: "%2".

AT RIB UTO VA LO R

MessageId 16702

Gravidade Erro
AT RIB UTO VA LO R

SymbolicName EVENT_EQOS_ERROR_OPENING_MACHINE_POLICY_ROOT_
KEY

Idioma Inglês

Message Falha de QoS ao abrir a chave raiz no nível da máquina para

políticas de QoS. Código de erro: "%2".

AT RIB UTO VA LO R

MessageId 16703

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_OPENING_USER_POLICY_ROOT_KEY

Idioma Inglês

Message Falha do QoS ao abrir a chave raiz no nível do usuário para

políticas de QoS. Código de erro: "%2".

AT RIB UTO VA LO R

MessageId 16704

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_KEYNAME_TOO_L
ONG

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".

AT RIB UTO VA LO R

MessageId 16705

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_USER_POLICY_KEYNAME_TOO_LONG

Idioma Inglês

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".
AT RIB UTO VA LO R

MessageId 16706

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_MACHINE_POLICY_KEYNAME_SIZE_ZE
RO

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".

AT RIB UTO VA LO R

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".

AT RIB UTO VA LO R

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".

AT RIB UTO VA LO R

MessageId 16709

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_OPENING_USER_POLICY_SUBKEY
AT RIB UTO VA LO R

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".

AT RIB UTO VA LO R

MessageId 16710

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_PROCESSING_MACHINE_POLICY_FIEL
D

Idioma Inglês

Message Falha de QoS ao ler ou validar o campo "%2" para a política

de QoS do computador "%3".

AT RIB UTO VA LO R

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".

AT RIB UTO VA LO R

MessageId 16712

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_SETTING_TCP_AUTOTUNING

Idioma Inglês

Message Falha de QoS ao ler ou definir o nível de taxa de

transferência TCP de entrada, código de erro: "%2".

AT RIB UTO VA LO R

MessageId 16713
 AT RIB UTO VA LO R

Gravidade Erro

SymbolicName EVENT_EQOS_ERROR_SETTING_APP_MARKING

Idioma Inglês

Message Falha de 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 deste guia, consulte perguntas frequentes sobre a política de QoS.
Para o primeiro tópico deste guia, consulte política de QoS (qualidade de serviço).
 SDN na visão geral do Windows Server
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

A Rede Definida pelo Software (SDN) fornece um método para configurar e gerenciar centralmente dispositivos
de rede física e virtual, como roteadores, comutadores e gateways no seu data center. Você pode usar seus
dispositivos compatíveis com SDN existentes para obter uma integração mais profunda entre a rede virtual e a
rede física. Elementos de rede virtual, como o Com switch virtual do Hyper-V, a Virtualização de Rede Hyper-V e
o Gateway ras, foram projetados para serem elementos integrais da infraestrutura do SDN.

NOTE
Hosts Hyper-V e VMs (máquinas virtuais) que executam servidores de infraestrutura SDN, como os nós controlador de
rede e balanceamento de carga de software, devem ter o Windows Server 2019 ou 2016 Datacenter Edition instalado.
Hosts Hyper-V que contêm apenas VMs de carga de trabalho de locatário conectadas a redes controladas por SDN
podem usar Windows Server 2019 ou 2016 Standard Edition.

O SDN é possível porque os planos de rede não estão mais vinculados aos próprios dispositivos de rede. No
entanto, outras entidades, como o software de gerenciamento de datacenter, como System Center 2016 usam
planos de rede. O SDN permite que você gerencie sua rede de datacenter dinamicamente, fornecendo uma
maneira automatizada e centralizada de atender aos requisitos de seus aplicativos e cargas de trabalho.
Você pode usar o SDN para:
Criar, proteger e conectar sua rede dinamicamente para atender às necessidades em evolução de seus
aplicativos
Acelerar a implantação de suas cargas de trabalho de maneira sem interrupções
Conter vulnerabilidades de segurança da distribuição pela rede
Definir e controlar políticas que controlam redes físicas e virtuais
Implementar políticas de rede consistentemente em escala
O SDN permite que você realize tudo isso, reduzindo também os custos gerais de infraestrutura.

Entre em contato com a equipe do produto Datacenter e Rede de

Nuvem
Se você estiver interessado em discutir tecnologias de SDN com a Microsoft ou outros clientes SDN, há uma
variedade de métodos para fazer contato.
Para obter mais informações, consulte Entrar em contato com a equipe de rede de nuvem e datacenter.
 Tecnologias de SDN
11/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

os tópicos nesta seção fornecem uma visão geral e informações técnicas sobre as tecnologias de rede definidas
pelo Software que estão 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 interfaces de
programação de aplicativo (APIs):
1. API Southbound – permite que o controlador de rede se comunique com a rede.
2. API Nor thbound – permite que você se comunique com o controlador de rede.
você pode usar Windows PowerShell, a API REST (representational State Transfer) 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 de multilocatários RAS (serviço de acesso remoto)
Balanceadores de Carga

Virtualização de rede Hyper-V

A HNV (virtualização de rede) do 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 encaminhar seus investimentos existentes, você pode configurar redes virtuais no equipamento de rede
existente. Além disso, as redes virtuais são compatíveis com VLANs (redes locais virtuais).

Comutador Virtual do Hyper-V

O comutador virtual do Hyper-V é um comutador de rede Ethernet de camada 2 baseado em software que está
disponível no Gerenciador do Hyper-V após a instalação da 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 comutador virtual do Hyper-V fornece imposição de políticas para segurança,
isolamento e níveis de serviço.
Você também pode implantar o comutador virtual do Hyper-V com o switch Embedded teaming (SET) e acesso
remoto direto à memória (RDMA). Para obter mais informações, consulte a seção RDMA (acesso remoto direto à
memória) e comutador inserido de equipe (Set) neste tópico.

Serviço DNS interno (iDNS) 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 iDNS, você pode fornecer locatários com serviços de resolução de nomes
DNS para namespaces e recursos locais isolados e de Internet.

Virtualização de função de rede

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. 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 de virtualização de função de rede a seguir estão disponíveis.
Load Balancer de software (SLB) e conversão de endereços de rede (NAT) . Aprimore a taxa de
transferência ao dar suporte ao retorno de 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 de RAS para Sdn . Rotear o tráfego de rede entre a rede física e os recursos da rede VM,
independentemente do local. Você pode rotear o tráfego de rede no mesmo local físico ou em vários
locais diferentes. Para obter mais detalhes, consulte Gateway de 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
comutador Virtual do Hyper-V com ou sem a opção de agrupamento incorporado (SET). Isso permite que você
use menos adaptadores de rede quando desejar usar RDMA e definido ao mesmo tempo.
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
das funcionalidades de agrupamento NIC ao comutador virtual Hyper-V.
SET permite que você agrupe entre um e oito adaptadores de rede Ethernet física 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. O conjunto de adaptadores de rede de membros
deve ser instalado no mesmo host do Hyper-V físico a ser colocado em uma equipe.
além disso, você pode usar Windows PowerShell comandos para habilitar a ponte do data Center (DCB), criar
um comutador virtual do hyper-v com uma NIC virtual RDMA (vNIC) e criar um comutador virtual do hyper-v
com SET e RDMA vNICs. Para obter mais informações, consulte acesso remoto direto à memória (RDMA) e
Comutador incorporado (Set).

BGP (Border Gateway Protocol)

O Border Gateway Protocol (BGP) é um protocolo de roteamento dinâmico que aprende automaticamente as
rotas entre sites que usam conexões VPN site a site. Portanto, o BGP reduz a configuração manual dos
roteadores. Quando você configura o gateway RAS, o BGP permite gerenciar o roteamento do tráfego de rede
entre as redes de VM e os sites remotos de seus locatários.

SLB (balanceamento de carga do software) para SDN

Os CSPs (provedores de serviços de nuvem) e as empresas que implantam SDN podem usar o SLB
(balanceamento de carga de software) para distribuir uniformemente o tráfego de rede do cliente 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 Os 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 do contêiner. Cada contêiner tem seu
próprio sistema operacional, processos, sistema de arquivos, registro e endereços IP, os quais você pode se
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.
 Virtualização de Rede Hyper-V
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e 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 estes tópicos:
Visão geral da virtualização de rede Hyper-V no Windows Server 2016
O que há de novo na virtualização de rede 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 por meio de VPN site a site e estender Active Directory para um
controlador de domínio de VM IaaS no Azure|
 Visão geral da Virtualização de Rede Hyper-V no
Windows Server
12/08/2021 • 13 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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 Azure Pack para Windows Ser ver fornece um portal voltado para locatários para criar
redes virtuais e um portal administrativo para gerenciar redes virtuais.
Vir tual 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 Vir tualização de Rede Hyper-V oferece a infraestrutura necessária para virtualizar o tráfego da
rede.
Os gateways de Vir tualizaçã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 no 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 A Virtualização de Rede Hyper-V fornece virtualização de rede controlada por software
baseada em políticas que reduz a sobrecarga de gerenciamento enfrentada pelas empresas ao expandir nuvens
IaaS dedicadas e 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.
VL ANs
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 VL ANs
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 compar tilhada
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 ser vidores 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 ser vidor/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:

T IP O DE C O N T EÚDO REF ERÊN C IA S

Recursos da comunidade - Blog da arquitetura de nuvem privada

-Faça perguntas: cloudnetfb@microsoft.com

RFC -VXLAN- RFC 7348

Tecnologias relacionadas - Controlador de rede

- visão geral da virtualização de rede Hyper-V (Windows
Server 2012 R2)
 detalhes técnicos da virtualização de rede Hyper-V
no Windows Server
12/08/2021 • 26 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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 um recurso semelhante, no 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 funciona
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

Na HNV (virtualização de rede) do Hyper-V, um cliente ou locatário é definido como o "proprietário" de um
conjunto de sub-redes IP que são implantadas em uma empresa ou Datacenter. Um cliente pode ser uma
corporação 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 que é 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
HNVv1 é compatível com Windows Server 2012 r2 e System Center 2012 r2 Virtual Machine Manager
(VMM). a configuração para HNVv1 se baseia no gerenciamento WMI e Windows PowerShell cmdlets
(facilitado por meio do System Center VMM) para definir configurações de isolamento e mapeamentos
de endereço de cliente (CA)-rede virtual-para endereço físico (PA) e roteamento. nenhum recurso
adicional foi adicionado ao HNVv1 no Windows Server 2016 e nenhum recurso novo está planejado.
 DEFINIR o agrupamento e o HNV v1 não são compatíveis com a plataforma.
o para usar gateways NVGRE de HA, os usuários precisam usar a equipe do LBFO ou nenhuma equipe.
Ou
o use gateways implantados do controlador de rede com o comutador conjunto agrupado.
HNVv2
Um número significativo de novos recursos está incluído no HNVv2, que é implementado usando a
extensão de encaminhamento da plataforma de filtragem virtual do Azure (VFP) no comutador do Hyper-
V. o HNVv2 é totalmente integrado ao Microsoft Azure stack, que inclui o novo controlador de rede na
pilha de SDN (rede definida pelo Software). A política de rede virtual é definida por meio do controlador
de rede da Microsoft usando uma API RESTful Northbound (NB) e encanada para um agente de host por
meio de várias interfaces Southbound (SBI), incluindo OVSDB. A política de programas do agente de host
na extensão VFP do comutador do Hyper-V em que é imposta.

IMPORTANT
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 em uma rede virtual só podem se comunicar entre si.
Tradicionalmente, esse isolamento foi imposto usando VLANs com um intervalo de endereços IP
segregado e uma marca 802.1 q ou ID de VLAN. Mas com HNV, o isolamento é imposto usando o
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. Este RDID
basicamente mapeia para uma ID de recurso para identificar o recurso REST de rede virtual no
controlador de rede. O recurso REST da rede virtual é referenciado usando um namespace Uniform
Resource Identifier (URI) com a ID de 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 rede virtual (RDID) 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 vantagem importante da rede virtual e do domínio de roteamento é que ele 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 onde a Contoso Corp tem duas redes separadas, Rede P&D e Rede de Vendas. 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. a 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 do Hyper-V. Os pacotes de entrada de uma máquina
virtual no VSID 5001 são enviados para um VPort específico no comutador do Hyper-V. As regras de entrada
(por exemplo, encap) e mapeamentos (por exemplo, cabeçalho de encapsulamento) são aplicadas pelo
comutador do Hyper-V para esses pacotes. Os pacotes são encaminhados para um VPort diferente na opção do
Hyper-V (se a máquina virtual de destino estiver anexada ao mesmo host) ou em um comutador Hyper-V
diferente em um host diferente (se a máquina virtual de destino estiver localizada em um host diferente).
Roteamento de 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 em cada VSwitch do host Hyper-
V. Ao entregar o pacote para o comutador do 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, os
adaptadores de rede virtual com RDID1 não podem enviar pacotes para adaptadores de rede virtual com RDID2
sem atravessar um gateway.

NOTE
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 a mesma coisa de forma conceitual.

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 o MAC pelos
endereços de cada VM que estão no mesmo VSID.

NOTE
quando Windows Server 2016 são fornecidos, difusões e multicast de 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 é
conectado a uma porta de comutador do Hyper-V que terá regras de ACL aplicadas diretamente à porta
(recurso de virtualNetworkInterface REST) ou à sub-rede virtual (VSID) da qual ela faz parte.
A porta do comutador do Hyper-V deve ter uma regra ACL aplicada. Essa ACL pode ser permitir todos, negar
tudo ou ser mais específica para permitir apenas certos tipos de tráfego com base em correspondência de 5
tuplas (IP de origem, IP de destino, porta de origem, porta de destino, protocolo) correspondente.

NOTE
Extensões de comutador Hyper-V não funcionarão com HNVv2 na nova pilha de SDN (rede definida pelo 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.

Alternando e roteando na virtualização de rede Hyper-V

O HNVv2 implementa a alternância de camada 2 (L2) correta e a semântica de roteamento de camada 3 (L3)
para funcionar assim 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 sub-
rede virtual (VSID), primeiro será necessário aprender o endereço MAC da AC 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 difusão ARP com uma solicitação para o endereço MAC correspondente ao endereço IP da
máquina virtual de destino a ser retornado. A opção Hyper-V interceptará essa solicitação e a enviará ao agente
do host. O agente do host procurará em seu banco de dados local um endereço MAC correspondente para o
endereço IP da máquina virtual de destino solicitada.

NOTE
O agente de host, agindo como o servidor OVSDB, usa uma variante do esquema VTEP para armazenar mapeamentos
CA-PA, tabela MAC e assim por diante.

Se um endereço MAC estiver disponível, o agente de host injetará uma resposta ARP e a enviará 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 Hyper-V correspondente na opção V-. Internamente, o
comutador do Hyper-V testa esse quadro em relação às regras de correspondência de N-tupla atribuídas à
porta V e aplica determinadas transformações ao quadro com base nessas regras. O mais importante é que 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 do host, um mapeamento de CA-PA é usado para determinar o endereço IP do host
Hyper-V onde reside a máquina virtual de destino. A opção Hyper-V garante que as regras de roteamento e as
marcas de VLAN corretas 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 deseja criar uma conexão com uma máquina virtual
em uma sub-rede virtual diferente (VSID), o pacote precisa ser roteado de acordo. O HNV pressupõe uma
topologia em estrela em que há apenas um endereço IP no espaço da autoridade de certificação usado como o
próximo salto para alcançar todos os prefixos de 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 os 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 (IP: mapa de endereços 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
de MAC aprendidas da 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 uma interface de rede.
Além disso, um "gateway padrão" geralmente é configurado para ser o endereço IP de 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 existirem 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 pressupõe uma topologia em estrela, o roteador distribuído HNV atua como um gateway padrão
único para todo o tráfego que está indo entre sub-redes virtuais que fazem parte da mesma rede VSID. O
endereço usado como padrão do gateway padrão é 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 todo o tráfego dentro de
uma rede VSID ser 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 PA
Ao contrário do HNVv1 que alocou um endereço IP PA para cada sub-rede virtual (VSID), o HNVv2 agora usa
um endereço IP PA por membro da equipe NIC de Switch-Embedded (conjunto). A implantação padrão assume
uma equipe de duas NICs e atribui dois endereços IP PA por host. Um único host tem IPs PA atribuídos da
mesma sub-rede lógica do PA (provedor) na mesma VLAN. Duas VMs de locatário na mesma sub-rede virtual
podem realmente 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 de TCP/IP do host para ARP para o gateway PA padrão e
cria os cabeçalhos de Ethernet externos com base na resposta ARP. Normalmente, essa resposta ARP vem da
interface SVI no comutador físico ou do roteador L3 onde o host está conectado. O HNV, portanto, 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 de HNV são necessários para o roteamento de camada 3 entre redes internas
e externas (incluindo NAT) ou entre diferentes sites e/ou nuvens (privadas ou públicas) que usam um túnel de
VPN IPSec ou GRE.
Os gateways podem ser fornecidos em diferentes fatores forma físicos. eles podem ser criados em Windows
Server 2016, incorporados a um TOR (Top of Rack) switch atuando como um Gateway VXLAN, acessado por
meio de um VIP (IP Virtual) 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 gateway de ras.

Encapsulamento de Pacote
Cada adaptador de rede virtual da HNV está associado a dois endereços IP:
Endereço do cliente (CA) 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 ela
não tivesse sido movida 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 os
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 da autoridade de
certificação, 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" em volta dos pacotes de dados
contoso e Fabrikam com os rótulos de envio verdes (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)
correspondentes à contoso e às autoridades de certificação da Fabrikam, como o "envelope" é colocado em
volta dos pacotes e como os hosts de destino podem desencapsular os pacotes e entregar às máquinas virtuais
de destino da Contoso e da Fabrikam corretamente.
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 da autoridade de certificação, que são
colocados em um "envelope" com uma origem PA e um par de destino 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 de
host mantém o banco de dados de mapeamento usando o esquema de 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 sobreposição de redes de locatário usando o NVGRE (encapsulamento de roteamento
genérico de virtualização de rede) ou a VXLAN (rede local extensível virtual). VXLAN é o padrão.
VXLAN (rede local extensível virtual)
O protocolo VXLAN (rede local extensível) (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 pela IANA para VXLAN é 4789 e a porta de origem UDP deve ser um hash de
informações do pacote interno a ser usado para a difusão de ECMP. Depois do cabeçalho UDP, um cabeçalho
VXLAN é anexado ao pacote, que inclui um campo de 4 bytes reservado seguido por um campo de 3 bytes para
o VNI (identificador de rede VXLAN)-VSID-seguido por outro campo de 1 byte reservado. Depois do cabeçalho
VXLAN, o quadro L2 da CA original (sem o FCS de quadro Ethernet da CA) é acrescentado.

Encapsulamento de roteamento genérico (NVGRE)

Esse mecanismo de virtualização de rede usa o encapsulamento de roteamento genérico (NVGRE) como parte
do cabeçalho de túnel. No 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 de sub-rede virtual permite que os hosts identifiquem a máquina virtual do cliente para qualquer pacote
específico, mesmo que o PA e as autoridades de certificação 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 PA para o Windows Server 2012 R2 é um PA por VSID por host. por Windows
Server 2016 o esquema é um PA por membro da equipe NIC.
com o Windows Server 2016 e posterior, o HNV dá suporte total a NVGRE e VXLAN prontos para uso; Ele não
requer atualização ou compra de novo hardware de rede, como NICs (adaptadores de rede), comutadores ou
roteadores. Isso ocorre porque esses pacotes na transmissão são um pacote de IP regular no espaço PA, que é
compatível com a infraestrutura de rede de hoje. 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 na
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 pressupor que o provedor de serviço de hospedagem criou anteriormente a rede lógica de provedor
(PA) por meio do controlador de rede para corresponder à topologia de rede física. O controlador de rede aloca
dois endereços IP PA do prefixo IP da sub-rede lógica onde os hosts estão conectados. O controlador de rede
também indica a marca de 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).
As duas empresas recebem a seguinte VSID (ID de sub-rede virtual) pelo controlador de rede, conforme
indicado abaixo. O agente de host em cada um dos hosts do Hyper-V recebe os endereços IP PA alocados do
controlador de rede e cria dois vNICs de host PA em um compartimento de rede não padrão. Uma interface de
rede é atribuída a cada um desses vNICs de host onde o endereço IP PA é atribuído, conforme mostrado abaixo:
as máquinas virtuais da Contoso Corp VSID e PAs: VSID é 5001, SQL PA é 192.168.1.10, o Web PA é
192.168.2.20
 as máquinas virtuais VSID e PAs da Fabrikam Corp: VSID é 6001, SQL PA é 192.168.1.10, o Web PA é
192.168.2.20
O controlador de rede hospeda todas as políticas de rede (incluindo o mapeamento de CA-PA) para o agente de
host SDN, que manterá a política em um repositório persistente (em tabelas de banco de dados OVSDB).
quando a máquina virtual da Contoso Corp (10.1.1.12) no Host do Hyper-V 2 cria uma conexão TCP com a SQL
Server em 10.1.1.11, acontece o seguinte:
ARPs VM para o endereço MAC de destino de 10.1.1.11
A extensão VFP no vSwitch intercepta esse pacote e o envia para o agente de host SDN
O agente de host SDN examina seu repositório de política para o endereço MAC para 10.1.1.11
Se um MAC for encontrado, o agente de host injetará uma resposta ARP de volta para a 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 de IP e Ethernet de CA 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 de 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 a pesquisa de tabela de fluxo para cada
camada (por exemplo, camada de rede virtual) com base nos cabeçalhos IP e Ethernet.
A regra de combinação na camada de rede virtual faz referência a um espaço de mapeamento CA-PA e
executa o encapsulamento.
O tipo de encapsulamento (VXLAN ou NVGRE) é especificado na camada VNet junto com o VSID.
No caso do encapsulamento VXLAN, um header UDP externo é construído com o VSID de 5001 no título
VXLAN. Um título 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
armazenamento de políticas do Agente 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 fará referência ao compartimento de rede usado para 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
hyper-V 1 corretamente.
Após o recebimento do pacote encapsulado, o Host hyper-V 1 recebe o pacote no compartimento de
rede pa e encaminha-o para o vSwitch.
O VFP processa o pacote por meio de suas camadas de VFP e cria uma nova entrada de fluxo na tabela
de fluxo unificado do VFP.
O mecanismo VFP corresponde às regras de entrada na camada de rede virtual e retira os headers
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 o PA para o tráfego de entrada e saída da máquina virtual 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 Comutamento Hyper-V. O conceito principal do VFP é o de um
mecanismo Match-Action fluxo com uma API interna exposta ao Agente host SDN para programação de política
de rede. O próprio Agente de Host SDN recebe a política de rede do Controlador de Rede nos canais de
comunicação OVSDB e WCF SouthBound. Não apenas a política de rede virtual (por exemplo, mapeamento ca-
PA) é programada usando vFP, mas política adicional, 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
Descarregas de hardware NIC
Regras de encaminhamento global
Porta
Egress de encaminhamento para fixar pelos
Listas de espaços para mapeamentos e pools de NAT
Tabela Flow unificada
Camada VFP
Flow tabela
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ínseco 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 são atribuídos a 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 a extensão VFP é a seguinte:
Processamento de entrada (entrada do ponto de vista do pacote que entra em uma porta)
Encaminhando
 Egress processamento (saída do ponto de vista do pacote que sai de uma porta)
O VFP dá suporte ao encaminhamento mac interno para tipos de encapsulamento NVGRE e VXLAN, bem como
encaminhamento baseado em VLAN mac externo.
A extensão VFP tem um caminho lento e um caminho rápido para a travessia do pacote. O primeiro pacote em
um fluxo deve percorrer todos os grupos de regras em cada camada e fazer uma pesquisa de regra, que é uma
operação cara. No entanto, depois que um fluxo é registrado na tabela de fluxo unificado com uma lista de
ações (com base nas regras que corresponderam), todos os pacotes subsequentes serão processados com base
nas entradas da tabela de fluxo unificado.
A política de 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. A HNV encapsula o quadro de AC em um
quadro 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, a HNV
é executado no datacenter de hoje e opera com sua infraestrutura VXLAN existente. Os clientes com HNV agora
podem consolidar seus datacenters em uma nuvem privada ou estender seus datacenters perfeitamente para o
ambiente de um provedor de servidores de hospedagem com uma nuvem híbrida.

Confira também
Para saber mais sobre o HNVv2, confira os seguintes links:
T IP O DE C O N T EÚDO REF ERÊN C IA S

Recursos da comunidade - Blog de arquitetura de nuvem privada

- Faça perguntas: cloudnetfb@microsoft.com

RFC - RFC de rascunho NVGRE

- VXLAN – RFC 7348

Tecnologias relacionadas - Para obter detalhes técnicos da Virtualização de Rede

Hyper-V no Windows Server 2012 R2, consulte Detalhes
técnicos da Virtualização de Rede Hyper-V
- Controlador de rede
 O que há de novo na virtualização de rede Hyper-V
no Windows Server 2016
13/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Este tópico descreve a funcionalidade de HNV (virtualização de rede) do Hyper-V que é nova ou alterada no
Windows Server 2016.

Atualizações no HNV
O HNV oferece suporte aprimorado nas seguintes áreas:

REC URSO / F UN C IO N A L IDA DE N O VO O U M EL H O RA DO DESC RIÇ Ã O

Comutador Hyper-V programável Novo A política de HNV é programável por

meio do controlador de rede da
Microsoft.

Suporte ao encapsulamento VXLAN Novo HNV agora dá suporte ao

encapsulamento VXLAN.

Interoperabilidade do SLB (software Novo O HNV é totalmente integrado ao

Load Balancer) Load Balancer de software da
Microsoft.

Cabeçalhos de Ethernet IEEE em Melhoria de Em conformidade com os padrões IEEE

conformidade Ethernet

Comutador Hyper-V programável

O HNV é um bloco de construção fundamental da solução de SDN (rede definida pelo software) atualizada pela
Microsoft e é totalmente integrado à pilha SDN.
O novo controlador de rede da Microsoft envia políticas de HNV para um agente de host em execução em cada
host usando o protocolo OVSDB (Open vSwitch Database Management) como SBI (interface SouthBound). O
agente de host armazena essa política usando uma personalização das regras de fluxo complexo de programas
e esquema VTEP em um mecanismo de fluxo de alto desempenho no comutador Hyper-V.
o mecanismo de fluxo dentro da opção Hyper-V é o mesmo mecanismo usado no Microsoft Azure ™ , que foi
comprovado em hiperescala na nuvem pública Microsoft Azure. além disso, toda a pilha do SDN através do
controlador de rede e do provedor de recursos de rede (detalhes em breve) é consistente com Microsoft Azure,
o que traz o poder da nuvem pública Microsoft Azure para nossos clientes do provedor de serviços corporativos
e de hospedagem.

NOTE
Para obter mais informações sobre OVSDB, consulte RFC 7047.

A opção Hyper-V dá suporte a regras de fluxo com e sem estado com base na ' ação de correspondência '
simples no mecanismo de fluxo da Microsoft.

Suporte ao encapsulamento VXLAN

O protocolo VXLAN- RFC 7348(rede local extensível virtual) foi amplamente adotado no mercado, com suporte
de fornecedores como Cisco, Brocade, Dell, HP e outros. O HNV também 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 de cliente ou CA)
para os endereços IP de rede física underlay (endereço do provedor ou PA). Os descarregamentos de tarefas
NVGRE e VXLAN têm suporte para melhorar o desempenho por meio de drivers de terceiros.
Interoperabilidade do SLB (software Load Balancer)
o Windows Server 2016 inclui um SLB (balanceador de carga de software) com suporte completo para tráfego
de rede virtual e interação direta com o HNV. O SLB é implementado por meio do mecanismo de fluxo de
desempenho na opção v-switch do plano de dados e controlado pelo controlador de rede para mapeamentos
de IP virtual (VIP)/IP dinâmico (DIP).
Cabeçalhos de Ethernet IEEE em conformidade
O HNV implementa cabeçalhos Ethernet L2 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 em conformidade em todos os campos para garantir essa interoperabilidade. Além
disso, o suporte para quadros Jumbo (MTU > 1780) na rede de L2 física será necessário para considerar a
sobrecarga de pacotes introduzida pelos protocolos de encapsulamento (NVGRE, VXLAN), ao mesmo tempo em
que garante que as máquinas virtuais convidadas anexadas a uma rede virtual HNV mantenham um MTU de
1514.

Referências adicionais
Visão Geral da Virtualização de Rede Hyper-V
Detalhes técnicos da Virtualização de Rede Hyper-V
Rede definida pelo software
 Serviço DNS interno (iDNS) para SDN
07/08/2021 • 7 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Se você trabalhar para um CSP do Provedor de Serviços de Nuvem ou um Enterprise que está planejando
implantar o SDN de Rede Definida pelo Software no servidor Windows, poderá fornecer serviços DNS para suas
cargas de trabalho de locatário hospedadas usando o iDNS dns interno, que é integrado ao ( ) ( ) ( ) SDN.
As VMs e aplicativos de máquinas virtuais hospedadas 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 de Redes Virtuais de locatário, além 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 dentro do espaço de nome do locatário
Serviço DNS recursivo para resolução de nomes de Internet de VMs de locatário.
Se desejar, 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, 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 do 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
resolvedores de 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 o 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 de Nomes de Domínio Totalmente Qualificados da VM do Locatário consistem no nome do
computador e na cadeia de caracteres do sufixo DNS para a Rede ( ) Virtual, no formato GUID. Por exemplo, se
você tiver uma VM de locatário chamada TENANT1 que está na Rede Virtual contoso,local, o FQDN da VM será
TENANT1. vn-guid.contoso.local, em que vn-guid é a cadeia de caracteres de sufixo DNS para a Rede Virtual.

NOTE
Se você for um administrador de malha, poderá usar sua infraestrutura CSP ou dns Enterprise como servidores iDNS em
vez de implantar novos servidores DNS especificamente para uso como servidores iDNS. Independentemente de 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 Windows que é executado em cada host e que encaminha o tráfego DNS da Rede Virtual do
locatário para o servidor iDNS.
A ilustração a seguir ilustra os caminhos de tráfego DNS de Redes Virtuais do locatário por meio do proxy iDNS
para o servidor iDNS e a Internet.

Como implantar o iDNS

Quando você implanta o SDN Windows Server 2016 usando scripts, o iDNS é incluído automaticamente em sua
implantação.
Para obter mais informações, consulte estes tópicos.
Implantar uma infraestrutura de rede definida pelo software usando scripts
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.
A seguir está um resumo das etapas necessárias para implantar o iDNS.

NOTE
Se você tiver implantado o SDN usando scripts, não precisará executar nenhuma dessas etapas. As etapas são fornecidas
apenas para fins de informações e solução de problemas.

Etapa 1: Implantar DNS

Você pode implantar um servidor DNS usando o comando Windows PowerShell exemplo a seguir.

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-o 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"
}
}

NOTE
Este é um trecho da seção Configuration 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
de locatários e a rede física em que os servidores iDNS estão localizados. As chaves do Registro a seguir devem
ser criadas em cada host hyper-V.
Por ta DNS: Porta fixa 53
Chave do Registro =
HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService"
 ValueName = "Port"
ValueData = 53
ValueType = "Dword"
Por ta proxy DNS: Porta fixa 53
Chave do Registro =
HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService"
ValueName = "ProxyPort"
ValueData = 53
ValueType = "Dword"
IP DNS: Corrigido o endereço IP configurado no interface de rede, caso o locatário opte por usar o serviço
iDNS
Chave do Registro =
HKLM\SYSTEM\CurrentControlSet\Services\NcHostAgent\Parameters\Plugins\Vnet\InfraServices\DnsProxyService"
ValueName = "IP"
ValueData = "169.254.169.254"
ValueType = "String"
Endereço Mac: Endereço de Controle de Acesso à 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"
ValueType = "String"
Endereço do ser vidor 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"
ValueType = "String"

NOTE
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 de agente de host do controlador de rede

Você pode usar o comando Windows PowerShell a seguir para reiniciar o Serviço de Agente de Host do
Controlador de Rede.

Restart-Service nchostagent -Force

Para obter mais informações, consulte Restart-Service.

Habilitar regras de firewall para o serviço de proxy DNS
Você pode usar o comando Windows PowerShell a seguir para criar uma regra de firewall que permite que
exceções para o proxy se comuniquem com a VM e o servidor iDNS.
 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 uma rede virtual de locatário ou VLAN.
Se você quiser que a VM de locatário use o serviço iDNS, deixe a configuração do Servidor DNS dos interfaces
de rede da VM em branco e permita que as interfaces usem o DHCP.
Depois que a VM com esse interface de rede é iniciada, ela recebe automaticamente uma configuração que
permite que a VM use iDNS e a VM imediatamente começa a executar a 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 do interface de rede e
as informações do Servidor DNS Alternativo em branco, o Controlador de Rede fornece à VM um endereço IP e
executa 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 da Rede Virtual para
o serviço iDNS.
O proxy DNS também garante que as consultas de VM de locatário sejam 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.

NOTE
Essas informações estão incluídas na seção Configuration AttachToVir tualNetwork no SDNExpressTenant.ps1. Para
obter mais informações, consulte Implantar uma infraestrutura de rede definida pelo software usando scripts.
 Alta disponibilidade do controlador de rede
12/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar este tópico para saber mais sobre a configuração de alta disponibilidade e escalabilidade do
Controlador de Rede para o ( SDN de 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 de
Qualidade de Serviço para ( políticas de SDN, políticas de rede híbrida e muito ) mais.
Como o Controlador de Rede é a base do gerenciamento de SDN, é essencial que as implantações do
Controlador de Rede forneçam alta disponibilidade e a capacidade de escalar ou rebanhar facilmente os nós do
Controlador de Rede com suas necessidades de datacenter.
Embora seja possível implantar o Controlador de Rede como um único cluster de computador, para alta
disponibilidade e failover, você deve implantar o Controlador de Rede em um cluster de vários computador com,
no mínimo, três máquinas.

NOTE
Você pode implantar o Controlador de Rede em computadores servidores ou em VMs de máquinas virtuais que estão ( )
executando Windows Server 2016 Datacenter Edition. 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 no Windows Server 2016 Standard Edition.

Controlador de rede como um Service Fabric aplicativo

Para obter alta disponibilidade e escalabilidade, o Controlador de Rede depende Service Fabric. Service Fabric
fornece uma plataforma de sistemas distribuídos para criar aplicativos escalonáveis, confiáveis e facilmente
gerenciados.
Como uma plataforma, Service Fabric fornece 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.

NOTE
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 máquinas, o Controlador de Rede é executado como
um único Service Fabric aplicativo em um cluster Service Fabric rede. Você pode formar um Service Fabric
cluster 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 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ário fornecem alta disponibilidade em
circunstâncias em que a réplica primária está desabilitada ou não disponível por algum motivo.
A ilustração a seguir ilustra um cluster de Service Fabric controlador de rede com cinco máquinas. Quatro
serviços são distribuídos entre os cinco máquinas: Serviço de Firewall, Serviço de Gateway, Serviço de
Balanceamento de Carga de Software SLB e serviço ( ) ( VNET de rede ) virtual. Cada um dos quatro serviços
inclui uma réplica de serviço primária e duas réplicas de serviço secundário.

Vantagens de usar Service Fabric

A seguir estão as principais vantagens de usar Service Fabric para clusters do Controlador de Rede.
Alta disponibilidade e escalabilidade
Como o Controlador de Rede é o núcleo de uma rede de datacenter, ele deve ser resiliente a falhas 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ários 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 para a réplica
primária.
Agilidade da escala . Você pode dimensionar facil e rapidamente esses serviços confiáveis de algumas
instâncias para milhares de instâncias e, em seguida, voltar para algumas instâncias, dependendo das suas
necessidades de recursos.
Armazenamento persistente
O aplicativo Controlador de Rede tem grandes requisitos de armazenamento para sua configuração e estado. O
aplicativo também deve ser usável em paralisações planejadas e não planejadas. Para essa finalidade, Service
Fabric fornece uma Key-Value Store KVS que é um armazenamento 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 de Balanceamento de Carga de
Software pode ser atualizado sem afetar nenhum dos outros serviços ou a operação normal do Controlador
de Rede.
2. A modularidade do Controlador de Rede permite a adição de novos serviços, à medida que a rede evolui.
Novos serviços podem ser adicionados ao Controlador de Rede sem afetar os serviços existentes.

NOTE
No Windows Server 2016, não há suporte para a adição de serviços de terceiros ao Controlador de Rede.

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 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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Este tópico fornece instruções sobre como instalar a função de servidor do controlador de rede usando
Gerenciador do Servidor.

IMPORTANT
Não implante a função de servidor do controlador de rede em hosts físicos. Para implantar o controlador de rede, você
deve instalar a função de servidor do controlador de rede em uma VM de máquina virtual do Hyper-V ( ) instalada em
um host do 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 o SDN de rede definido pelo Software ( ) adicionando os hosts ao controlador de rede
usando o comando Windows PowerShell New-NetworkControllerSer ver . Ao fazer isso, você está permitindo que o
software SDN Load Balancer funcione. Para obter mais informações, consulte New-NetworkControllerServer.

depois de instalar o controlador de rede, você deve usar os comandos Windows PowerShell para configuração
adicional do controlador de rede. Para obter mais informações, consulte implantar o controlador de rede usando
Windows PowerShell.
Para instalar o controlador de rede
1. No Gerenciador do Servidor, clique em Gerenciar e depois em Adicionar Funções e Recursos . O
assistente Adicionar funções e recursos é aberto. Clique em Próximo .
2. Em Selecionar tipo de instalação , mantenha a configuração padrão e clique em Avançar .
3. Em selecionar ser vidor de destino , escolha o servidor no qual você deseja instalar o controlador de
rede e clique em Avançar .
4. Em selecionar funções de ser vidor , 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 ser vidor , clique em Avançar .

 7. Em selecionar recursos , clique em Avançar .
8. Em 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
exige que você reinicie o computador após a execução do assistente. Por isso, clique em reiniciar o
ser vidor de destino automaticamente, se necessário . A caixa de diálogo Assistente de adição de
funções e recursos é aberta. Clique em Sim .

10. Em Confirmar seleções de instalação , clique em Instalar .

11. A função de servidor do 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
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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 VMs de máquinas virtuais 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 EKU de Uso Aprimorado de Chave 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
nos outros nós.
Para obter mais informações, consulte Controlador de Rede.
 Virtualização de função de rede
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar este tópico para saber mais sobre a virtualização de função de rede, que permite implantar
dispositivos de rede virtual, como o Firewall do datacenter, o gateway de RAS multilocatário e o multiplexador
SLB de balanceamento de carga de software ( ) ( MUX ) .

NOTE
Além deste tópico, a documentação de virtualização de 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 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 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 mercado totalmente novo. Eles continuam gerando interesse e conquistam impulso nas plataformas
de virtualização e nos serviços de nuvem.
a Microsoft incluiu um gateway autônomo como um dispositivo virtual a partir do 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 de virtualização é dinâmica e fácil de alterar, pois é uma máquina virtual predefinida e
personalizada. Pode ser uma ou mais máquinas virtuais empacotadas, atualizadas e mantidas como uma
unidade. Junto com a SDN (rede definida pelo software), você obtém a agilidade e a flexibilidade necessárias na
infraestrutura atual baseada em nuvem. 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 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 soluções
previamente integradas.
Os clientes podem facilmente mover o dispositivo virtual para qualquer lugar na nuvem.
Os clientes podem dimensionar dispositivos virtuais vertical ou horizontalmente com base na
demanda.
Para obter mais informações sobre o Microsoft SDN, 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 de serviço distribuída)
IPS/IDS (sistema de prevenção de intrusão/sistemas de detecção de intrusão)
Otimizadores de aplicativo/WAN
Edge
Gateway site a site
Gateways L3
Roteadores
Opções
NAT
Balanceadores de carga (não necessariamente na borda)
Proxy HTTP

Por que a Microsoft é uma excelente plataforma para dispositivos

virtuais

A plataforma da Microsoft foi projetada para ser uma ótima plataforma para criar e implantar dispositivos
virtuais. Veja por quê:
A Microsoft fornece as principais funções de rede virtualizadas com Windows Server 2016.
Você pode implantar um dispositivo virtual 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 o Windows Server 2016:
Balanceador de carga de software
Um balanceador de carga de camada 4 operando na escala do datacenter. Esta é 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 Load Balancer de software da Microsoft, consulte balanceamento de carga de software
(SLB) 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 funções de gateway a seguir.
Gateway site a site
O gateway de RAS fornece um gateway de multilocatário com capacidade de Border Gateway Protocol
(BGP) que permite que seus locatários acessem e gerenciem seus recursos em conexões VPN site a site
de sites remotos e que permite o fluxo de tráfego de rede entre os recursos virtuais nas redes físicas de
locatário e nuvem. Para obter mais informações sobre o gateway de RAS, consulte gateway de RAS de
alta disponibilidade e Gateway de Ras.
Gateway de encaminhamento
O gateway RAS roteia o tráfego entre as 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 com os serviços de que precisam. Para obter mais informações, consulte gateway de RAS de alta
disponibilidade e Gateway de 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 o GRE está disponível na maioria dos dispositivos de rede,
ele se torna uma opção ideal para encapsular onde 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) do Hyper-V é a entidade lógica centralizada no plano
de controle, que transporta todas as rotas de plano de endereço do cliente e aprende e atualiza dinamicamente
os roteadores de gateway de RAS distribuídos na rede virtual. Para obter mais informações, consulte gateway
de RAS de alta disponibilidade e Gateway de Ras.
Firewall de vários locatários 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 de locatário e o controlador de rede as distribui para todos os hosts aplicáveis. Para obter mais
informações sobre o firewall de vários locatários distribuído, consulte visão geral do firewall do datacenter.
 Arquitetura de implantação do Gateway de RAS
07/08/2021 • 12 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar este tópico para saber mais sobre a implantação do CSP (provedor de serviços de nuvem) do
gateway de RAS, incluindo pools de gateway de 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 de RAS para que
você possa entender como usar esses recursos no design de sua implantação de gateway.
Além disso, um exemplo de implantação é fornecido, incluindo informações sobre o processo de adição de
novos locatários, sincronização de rotas e roteamento do plano de dados, failover do refletor de gateway e rota
e muito mais.
Este tópico inclui as seções a seguir.
Usando novos recursos do gateway de RAS para projetar sua implantação
Exemplo de implantação
Adicionar novos locatários e espaço de CA (endereço do cliente) emparelhamento EBGP
Sincronização de rotas e roteamento do plano de dados
Como o controlador de rede responde ao gateway RAS e ao failover de refletor de rota
Vantagens de usar novos recursos de gateway de RAS

Usando novos recursos do gateway de RAS para projetar sua

implantação
O gateway de 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 de refletor de rota Border Gateway Protocol (BGP) agora está incluída no gateway de RAS e
fornece uma alternativa à topologia de malha completa do BGP que normalmente é necessária para a
sincronização de rota entre roteadores. Com a sincronização de malha completa, 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
de clientes de refletor de rota BGP, simplificando assim a sincronização de rota 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 de Ras.
Pools de gateway
no Windows Server 2016, você pode criar vários pools de gateway de tipos diferentes. Pools de gateway
contêm muitas instâncias do gateway de RAS e roteiam o tráfego de rede entre redes físicas e virtuais.
Para obter mais informações, consulte novidades no gateway RAS e alta disponibilidade do gateway RAS.
Escalabilidade do pool de gateway
Você pode facilmente dimensionar um pool de gateway para cima ou para baixo adicionando ou removendo
VMs de gateway no pool. A remoção ou a 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 novidades no gateway RAS e alta disponibilidade do gateway RAS.
M + N redundância de pool de gateway
Cada pool de gateway é M + N redundante. Isso significa que o backup de um ' M' de VMs de gateway ativo é
feito 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 que você precisa ao implantar o gateway RAS.
Para obter mais informações, consulte novidades no gateway RAS e alta disponibilidade do gateway RAS.

Exemplo de implantação
A ilustração a seguir fornece um exemplo com emparelhamento eBGP em 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 de
infraestrutura de gateway para encerrar o site contoso los Angeles em GW3 em vez de GW2. Por isso, as
conexões VPN da Contoso de sites diferentes terminam no datacenter do CSP em dois gateways diferentes.
Ambos os gateways, GW2 e GW3, foram os primeiros gateways de RAS configurados pelo controlador de rede
quando o CSP adicionou os locatários contoso e Woodgrove à sua infraestrutura. Por isso, esses dois gateways
são configurados como refletores de rota para esses clientes (ou locatários) correspondentes. GW2 é o refletor
de rota da Contoso e GW3 é o refletor de rota do Woodgrove, além de ser o ponto de término do gateway de
RAS do CSP para a conexão VPN com o site de HQ de los da Contoso Angeles.

NOTE
Um gateway RAS pode rotear o tráfego de rede virtual e física para até 100 locatários diferentes, dependendo dos
requisitos de largura de banda de cada locatário.

Como os refletores de rota, o GW2 envia rotas de espaço de CA da Contoso para o controlador de rede e GW3
envia rotas de espaço da AC do Woodgrove para o controlador de rede.
O controlador de rede envia políticas de virtualização de rede Hyper-V para as redes virtuais contoso e
Woodgrove, bem como políticas de RAS para os gateways RAS e políticas de balanceamento de carga para os
multiplexadores (MUXes) configurados como um pool de balanceamento de carga de software.

Adicionar novos locatários e espaço de CA (endereço do cliente)

emparelhamento eBGP
Quando você assina um novo cliente e adiciona o cliente como um novo locatário em seu datacenter, você pode
usar o processo a seguir, grande parte do qual é executado automaticamente pelo controlador de rede e pelos
roteadores eBGP do gateway de RAS.
1. Provisione uma nova rede virtual e cargas de trabalho de acordo com os requisitos do seu locatário.
2. se necessário, configure a conectividade remota entre o site Enterprise do locatário remoto e sua rede
virtual em seu datacenter. Quando você implanta uma conexão VPN site a site para o locatário, o
controlador de rede seleciona automaticamente uma VM de gateway RAS disponível do pool de gateway
disponível e configura a conexão.
3. Ao configurar a VM do gateway de 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 um
gateway e refletor de rota para outros locatários.
4. Dependendo se o roteamento de espaço da autoridade de certificação está configurado para usar redes
configuradas estaticamente ou roteamento de BGP dinâmico, o controlador de rede configura as rotas
estáticas correspondentes, vizinhos de BGP ou ambos na VM de gateway RAS e refletor de rota.

NOTE
Depois que o controlador de rede tiver configurado um gateway RAS e um 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 nessa 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 de gateway de
RAS. Se a VM do gateway de 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 de
gateway de RAS associada ao locatário se torna o cliente de refletor de rota do refletor de rota de gateway
RAS de locatário original.
como os pools de Gateway de RAS estão protegidos pelos balanceadores de carga de Software (SLBs), os
endereços VPN site a site dos locatários usam um único endereço ip público, chamado de VIP (endereço ip
virtual), que é convertido pelo SLBs em um endereço ip interno de datacenter, chamado de DIP (endereço
ip dinâmico), para um Gateway RAS que roteia Enterprise o tráfego para o locatário esse mapeamento de
endereço IP público para privado por SLB garante que os túneis VPN site a site sejam corretamente
estabelecidos entre os sites Enterprise e os gateways RAS de CSP e os refletores de rota.
Para obter mais informações sobre SLB, VIPs e DIPs, consulte balanceamento de carga de Software () SLB
para Sdn.

5. depois que o túnel VPN site a site entre o site do Enterprise e o Gateway de RAS do datacenter do CSP for
estabelecido para o novo locatário, as rotas estáticas associadas aos túneis serão automaticamente
provisionadas nos lados Enterprise e CSP do túnel.
6. com o roteamento de BGP de espaço da CA, o emparelhamento eBGP entre os sites Enterprise e o
refletor de rota de Gateway RAS do CSP também é estabelecido.

Sincronização de rotas e roteamento do plano de dados

depois que o emparelhamento eBGP é estabelecido entre Enterprise sites e o refletor de rota de Gateway RAS
do CSP, o refletor de rota aprende todas as rotas de Enterprise usando o roteamento de BGP dinâmico. O
refletor de rota sincroniza essas rotas entre todos os clientes de refletor de rota para que eles sejam todos
configurados com o mesmo conjunto de rotas.
O refletor de rota também atualiza essas rotas consolidadas, usando a sincronização de rota para o controlador
de rede. O controlador de rede converte as rotas nas políticas de virtualização de rede 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 de locatário acessível a partir do locatário Enterprise sites.
Para o roteamento do plano de dados, os pacotes que atingem as 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
de gateway de RAS participantes.
da mesma forma, com as políticas de virtualização de rede do Hyper-V em vigor, a rede virtual de locatário
roteia os pacotes diretamente para as VMs do Gateway de RAS (sem a necessidade de saber mais sobre o
refletor de rota) e, em seguida, para os sites Enterprise nos túneis VPN site a site.
Além disso. retornar o tráfego da rede virtual de locatário para o locatário remoto Enterprise site ignora o SLBs,
um processo chamado DSR (retorno de servidor direto).

Como o controlador de rede responde ao gateway RAS e ao failover

de refletor de rota
A seguir estão dois cenários de failover possíveis: um para clientes de refletor de rota de gateway de RAS e
outro para os refletores de rota de gateway de RAS-incluindo informações sobre como o controlador de rede
lida com failover para VMs em qualquer configuração.
Falha de VM de um cliente de refletor de rota BGP de gateway de RAS
O controlador de rede executa as seguintes ações quando um cliente do refletor de rota de gateway RAS falha.

NOTE
Quando um gateway de RAS não é um refletor de rota para a infraestrutura BGP de um locatário, ele é um cliente de
refletor de rota na infraestrutura BGP do locatário.

O controlador de rede seleciona uma VM de gateway de RAS em espera disponível e provisiona a nova
VM de gateway de RAS com a configuração da VM de gateway de RAS com falha.
O controlador de rede atualiza a configuração de SLB correspondente para garantir que os túneis de VPN
site a site de sites de locatário para o gateway de RAS com falha sejam estabelecidos corretamente com o
novo gateway de RAS.
O controlador de rede configura o cliente de refletor de rota BGP no novo gateway.
O controlador de rede configura o novo cliente de refletor de rota BGP de gateway de RAS como ativo. o
Gateway de 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 de gateway de RAS
O controlador de rede executa as seguintes ações quando um refletor de rota BGP de gateway RAS falha.
O controlador de rede seleciona uma VM de gateway de RAS em espera disponível e provisiona a nova
VM de gateway de RAS com a configuração da VM de gateway de RAS com falha.
 O controlador de rede configura o refletor de rota na nova VM de gateway de RAS e atribui a 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 de VPN
site a site de sites de locatário para o gateway de RAS com falha sejam estabelecidos corretamente com o
novo gateway de RAS.
O controlador de rede configura a nova VM de refletor de rota BGP de gateway de RAS como ativa.
O refletor de rota fica imediatamente ativo. o túnel VPN site a site para a Enterprise é estabelecido e o
refletor de rota usa o emparelhamento eBGP e as rotas de troca com os roteadores de site Enterprise.
Após a seleção de rota de BGP, o refletor de rota BGP de gateway de RAS atualiza os clientes de refletor
de rota de locatário no datacenter e sincroniza as rotas com o controlador de rede, disponibilizando o
caminho de dados de ponta a ponta para o tráfego de locatário.

Vantagens de usar novos recursos de gateway de RAS

A seguir estão algumas das vantagens de usar esses novos recursos de gateway de RAS ao projetar sua
implantação de gateway de RAS.
Escalabilidade do gateway de RAS
Como você pode adicionar tantas VMs de gateway de RAS quanto precisar para pools de gateway de RAS, você
pode dimensionar facilmente sua implantação de gateway de 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 afunilamentos de capacidade sem tempo de inatividade.
gerenciamento simplificado de Gateway de Site Enterprise
quando seu locatário tem vários sites Enterprise, o locatário pode configurar todos os sites com um endereço ip
de VPN site a site remoto e um único endereço ip vizinho remoto-seu CSP datacenter RAS Gateway de BGP
Route reflector 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 rápida de failover, você pode configurar o tempo de parâmetro BGP KeepAlive entre
rotas de borda e o roteador de controle em um intervalo de tempo curto, como menor ou igual a dez segundos.
Com esse intervalo curto de Keep Alive, se um roteador de borda BGP de 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
12/08/2021 • 13 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar este tópico para saber mais sobre configurações de alta disponibilidade para o SDN (Gateway
Multilotador ras para rede definida pelo software).
Este tópico inclui as seções a seguir.
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 de RAS no modo multi locatá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 de RAS no modo multitenatário como um gateway de borda para rotear o
tráfego de rede do cliente do locatário para recursos e redes virtuais 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. No Windows Server 2012 R2, todas as VMs de gateway formaram um único
pool, o que dificultava um pouco a separação lógica da implantação do gateway. Windows Server 2012 O
gateway R2 oferecia uma implantação de redundância 1:1 para as VMs do gateway, o que resultou na
subutilização da capacidade disponível para conexões VPN site a site (S2S).
Esse problema é resolvido no Windows Server 2016, que fornece vários Pools de Gateway , que podem ser de
tipos diferentes 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 ras, consulte Gateway ras.

Visão geral dos pools de gateway

No 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 tem redundância M+N. Isso significa que um número 'M' de VMs de gateway ativo é feito 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 – Chave de Internet 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 facilmente escalar um pool de gateway para cima ou para baixo adicionando ou removendo
VMs de gateway no pool. A remoção ou a 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 terminar em vários pools e vários gateways em um pool. No
entanto, se um locatário tiver conexões terminando em um pool de gateway todos os tipos, ele não
poderá assinar outros pools de gateway de tipo All ou individuais.
Os pools de gateway também fornecem a 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 vender 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
baixa 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
de 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 terminar 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 também é aplicável a outras funções de gateway, como gateways L3 e GRE.
Na ilustração, o dispositivo MT BGP é um Gateway Multitenant RAS com BGP. O BGP multitenant é usado para
roteamento dinâmico. O roteamento para um locatário é centralizado – um único ponto, chamado de RR
(refletor de rota), lida com o peering BGP para todos os sites de locatário. O próprio RR é distribuído entre 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 peering 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, que permite que a nuvem atue
como um ponto de trânsito para roteamento entre dois sites de locatário. Essas funcionalidades de 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 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 o tráfego de rede flui para um gateway em espera em caso de falha do gateway
As seções a seguir fornecem informações detalhadas sobre o Gateway de RAS e o Controlador de Rede.
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 de "melhor ajuste" para escolher conexões com eficiência em um pool. O ponto de peering BGP para
a conexão também será designado neste momento se esta 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 IKEv2 S2S, o Controlador
de Rede também provisiona uma regra NAT (Conversão de Endereços de Rede) no pool de SLB; essa regra NAT
no pool de SLB direciona 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.

NOTE
As conexões L3 e GRE ignoram o SLB e se conectam diretamente ao Gateway ras designado. Essas conexões exigem que
o roteador de ponto de extremidade remoto (ou outro dispositivo de terceiros) deve ser configurado corretamente para
se conectar ao Gateway ras.

Se o roteamento BGP estiver habilitado para a conexão, o peering 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
configuradas estaticamente se o BGP não for usado) são enviadas ao Controlador de Rede. Em seguida, o
Controlador de Rede ressuvia 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 associadas de Virtualização de Rede Hyper-V que especificam locais de gateway e as rebabece para
os hosts Hyper-V.
Alta disponibilidade para IKEv2 S2S
Um Gateway ras em um pool consiste em conexões e no par BGP de locatários diferentes. Cada pool tem
gateways ativos 'M' e gateways em espera 'N'.
O Controlador de Rede lida com a falha de gateways da seguinte maneira.
O Controlador de Rede pinga constantemente 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 de
Gateway RAS.
Falha na VM do Gateway ras
Falha do host Hyper-V no qual o Gateway ras está em execução
Falha de 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 localizadas em outros gateways, mas cujo RR reside no gateway com falha. O tempo de in
queda das últimas conexões é menor que o primeiro. Quando o Controlador de Rede detecta um
gateway com falha, ele executa as tarefas a seguir.
Remove as rotas das conexões impactadas dos hosts de computação.
Remove as políticas de Virtualização de Rede 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 SLB para apontar conexões para o novo gateway.
Simultaneamente, à medida que a configuração é exibida no novo gateway ativo, as conexões S2S IKEv2
e o emparelhamento via protocolo BGP são restabelecidas. As conexões e o emparelhamento via
protocolo 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 do Hyper-V associadas aos hosts do Hyper-V onde 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, mas só ocorre em uma escala maior.
Alta disponibilidade para GRE
O processo de resposta de failover do gateway de RAS por controlador de rede-incluindo detecção de falha,
copiar a configuração de conexão e roteamento para o gateway em espera, o failover do roteamento de
BGP/estático das conexões afetadas (incluindo a retirada e o redirecionamento de rotas em hosts de
computação e reemparelhamento de BGP) e a reconfiguração de políticas de virtualização de rede do Hyper-V
em hosts de computação-é a mesma para gateways e conexões GRE. No entanto, a redefinição de conexões GRE
acontece de modo diferente, e a solução de alta disponibilidade para o GRE tem alguns requisitos adicionais.

No momento da implantação do gateway, cada VM de gateway de RAS recebe um endereço IP dinâmico (DIP).
Além disso, cada VM de gateway também recebe um endereço IP virtual (VIP) para alta disponibilidade do GRE.
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 para a parte superior dos comutadores de rack (TOR) usando o BGP, que anuncia
ainda mais os VIPs para a rede física de nuvem. Isso torna os gateways acessíveis a partir de roteadores
remotos ou dispositivos de terceiros em que a outra extremidade da conexão GRE reside. Esse emparelhamento
via protocolo BGP é diferente do emparelhamento via protocolo BGP no nível de 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 é
então 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 em espera. Quando o gateway em espera se torna ativo, ele anuncia o VIP para
seu comutador TOR e ainda mais na rede física. Roteadores remotos continuam conectando 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 L3 de virtualização de rede Hyper-V é 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 de cliente) altamente disponível (da rede lógica marcada pela VLAN do locatário). O
endereço IP é usado como o endereço IP do par no gateway remoto (rede física) e é o próximo salto para
alcançar a rede de virtualização de rede do Hyper-V do locatário.
Ao contrário das conexões de rede IPsec ou GRE, a opção TOR não aprenderá dinamicamente a rede marcada de
VLAN do locatário. O roteamento para a rede marcada por VLAN do locatário precisa ser configurado no
comutador TOR e todos os comutadores intermediários e roteadores entre a infraestrutura física e o gateway
para garantir a conectividade de ponta a ponta. A seguir está um exemplo de configuração de rede virtual do
CSP, conforme ilustrado na ilustração a seguir.

REDE SUB - REDE ID DA VL A N GAT EWAY PA DRÃ O

Rede lógica contoso L3 10.127.134.0/24 1001 10.127.134.1

Rede lógica do Woodgrove 10.127.134.0/24 1002 10.127.134.1

L3

Veja a seguir exemplos de configurações de gateway de locatário, conforme ilustrado na ilustração a seguir.

EN DEREÇ O IP DO GAT EWAY

N O M E DO LO C ATÁ RIO L3 ID DA VL A N EN DEREÇ O IP DO PA R

Contoso 10.127.134.50 1001 10.127.134.55

Woodgrove 10.127.134.60 1002 10.127.134.65

A seguir está a ilustração dessas configurações em um datacenter CSP.

As falhas de gateway, detecção de falha e o processo de failover de gateway no contexto de um gateway de

encaminhamento L3 são semelhantes aos processos para gateways de RAS IKEv2 e GRE. As diferenças estão no
modo como os endereços IP externos são manipulados.
Quando o estado da VM do gateway se tornar não íntegro, o controlador de rede selecionará um dos gateways
em espera do pool e reprovisionará as conexões de rede e o roteamento no gateway em espera. Ao mover as
conexões, o endereço IP do espaço de CA altamente disponível do gateway de encaminhamento L3 também é
movido para a nova VM do gateway junto com o endereço IP do BGP do espaço da autoridade de certificação
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 de BGP, como o endereço IP de
BGP de espaço de CA é 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.
NOTE
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 maneira. Por isso, o pool de gateway L3 deve ser configurado cuidadosamente e a configuração manual deve ser
concluída separadamente.
 Agrupamento incorporado do comutador para
SDN
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

O 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 2019 e
2016. SET integra algumas 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.
Para obter mais informações, consulte Remote Direct Memory Access (RDMA) e Switch Embedded Teaming
(SET).
 Visão geral de rede de contêineres
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, damos 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 que são 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.

IMPORTANT
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, você cria um compartimento de rede para cada
Windows Server e contêiner do 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 parauma rede virtual de locatário: saiba como criar e gerenciar redes de contêiner
para sobrepor redes virtuais com SDN.
 Implantar uma infraestrutura de rede definida pelo
software
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Implantar a infraestrutura de SDN (Rede Definida pelo Software) da Microsoft.

Essas implantações incluem todas as tecnologias de que você precisa para uma infraestrutura totalmente
funcional, incluindo HNV (Virtualização de Rede Hyper-V), controladores de rede, SLB/MUX (balanceadores de
carga de software) e gateways.

Configurar a infraestrutura de SDN na malha do VMM

Configurar uma infraestrutura SDN (rede definida pelo software) na malha do VMM
Use esse método se você quiser incorporar System Center VMM (Virtual Machine Manger) para
gerenciar sua infraestrutura de SDN.

Implantar a infraestrutura SDN usando scripts

Implantar uma infraestrutura de rede definida pelo software usando scripts
Use esse método se você não quiser usar o VMM para gerenciar sua infraestrutura de SDN ou se tiver
outro método de gerenciamento.

Implantar tecnologias SDN individuais em vez de uma infraestrutura

inteira
Se você quiser implantar tecnologias SDN individuais em vez de uma infraestrutura inteira, consulte: Implantar
tecnologias de rede definidas pelo software usando Windows PowerShell.

Tópicos relacionados
SDN (rede definida pelo software)
Tecnologias SDN
Planejar SDN
Gerenciar SDN
Segurança para SDN
Solucionar problemas de SDN
 Implantar uma infraestrutura de rede definida pelo
software usando scripts
11/08/2021 • 9 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, você implanta uma infraestrutura de SDN (Rede Definida pelo Software) da Microsoft usando
scripts. A infraestrutura inclui um controlador de rede (HA) altamente disponível, um SLB (Software Load
Balancer 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 quiser que suas cargas de trabalho de locatário se comuniquem fora de suas redes virtuais, você poderá
configurar regras NAT SLB, túneis de Gateway Site a Site ou Encaminhamento de Camada 3 para roteamento
entre cargas de trabalho virtuais e físicas.
Você também pode implantar uma infraestrutura SDN usando Virtual Machine Manager (VMM). Para obter
mais informações, consulte Configurar uma infraestrutura de SDN (Rede Definida pelo Software) na malha do
VMM.

Pré-implantação
IMPORTANT
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 comutamento virtual Hyper-V e a atribuição de endereço IP do host Hyper-V
(servidores físicos). Qualquer tipo de armazenamento compatível com o Hyper-V, compartilhado ou local pode
ser usado.
Instalar a rede de host
1. Instale os drivers de rede mais recentes disponíveis para seu hardware NIC.
2. Instale a função Hyper-V em todos os hosts (para obter mais informações, consulte Get started with
Hyper-V on Windows Server 2016.

Install-WindowsFeature -Name Hyper-V -ComputerName <computer_name> -IncludeManagementTools -Restart

3. Crie o com switch virtual do Hyper-V.

Use o mesmo nome de comutadores 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 propagação máxima de entrada ocorre ao usar duas NICs.
 New-VMSwitch "<switch name>" -NetAdapterName "<NetAdapter1>" [, "<NetAdapter2>" -
EnableEmbeddedTeaming $True] -AllowManagementOS $True

TIP
Você poderá 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 pelo software ) e
trabalhe com o administrador de rede para obteraID da VLAN de Gerenciamento. Anexe a vNIC de
Gerenciamento do Com switch virtual recém-criado à VLAN de Gerenciamento. Esta etapa poderá ser
omitida se seu ambiente não usar marcas de VLAN.

Set-VMNetworkAdapterIsolation -ManagementOS -IsolationMode Vlan -DefaultIsolationID <Management VLAN>

-AllowUntaggedTraffic $True

5. Consulte o tópico de planejamento ( Planejar uma infraestrutura de rede definida pelosoftware)e

trabalhar 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:

New-NetIPAddress -InterfaceAlias "vEthernet (<switch name>)" -IPAddress <IP> -DefaultGateway <Gateway

IP> -AddressFamily IPv4 -PrefixLength <Length of Subnet Mask - for example: 24>

6. [Opcional] Implantar 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 máquina virtual do Servidor DNS/Active Directory para a VLAN de Gerenciamento:

Set-VMNetworkAdapterIsolation -VMName "<VM Name>" -Access -VlanId <Management VLAN> -

AllowUntaggedTraffic $True

b. Instale Active Directory Domain Services e DNS.

NOTE
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 finalidades diferentes (embora apenas um seja necessário).

7. Insinue todos os hosts hyper-V ao domínio. Verifique se a entrada do servidor DNS para o adaptador de
rede que tem um endereço IP atribuído à rede de gerenciamento aponta para um servidor DNS que pode
resolver o nome de domínio.

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 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 a opção VM foi criada com êxito:

Get-VMSwitch "<switch name>"

2. Verifique se a vNIC de gerenciamento na opção VM está conectada à VLAN de Gerenciamento:

NOTE
Relevante somente se o tráfego de Gerenciamento e Locatário compartilhar a mesma NIC.

Get-VMNetworkAdapterIsolation -ManagementOS

3. Valide todos os hosts Hyper-V e recursos de gerenciamento externos, por exemplo, servidores DNS.
Verifique se eles estão acessíveis por meio de ping usando seu endereço IP de gerenciamento e/ou 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 fornece acesso a todos os servidores.

winrm id -r:<Hyper-V Host FQDN>

Executar scripts do SDN Express

1. Acesse o Repositório de GitHub SDN da Microsoft para 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, em seguida, clique em Baixar ZIP.

NOTE
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 Todos ler/gravar .
5. Navegue até a pasta C:\SDNExpress .
Você verá as seguintes pastas:

N O M E DA PA STA DESC RIÇ Ã O

AgentConf Contém novas cópias de esquemas OVSDB usados pelo

Agente de Host SDN em cada Windows Server 2016
host Hyper-V para programar a política de rede.

Certificados Local compartilhado temporário para o arquivo de

certificado NC.
N O M E DA PA STA DESC RIÇ Ã O

Imagens Vazio, coloque a imagem Windows Server 2016 vhdx

aqui

Ferramentas Utilitários para solução de problemas e depuração.

Copiado para os hosts e máquinas virtuais.
Recomendamos que você coloque Monitor de Rede ou
Wireshark aqui para que ele seja disponibilizado, se
necessário.

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 de 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
balanceado 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 que estão conectados à carga
de trabalho de locatário criada anteriormente. Os
gateways IPSec e GRE estão disponíveis para
conectividade sobre o endereço IP VIP
correspondente e o gateway de encaminhamento L3
sobre o 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 carga
de trabalho de locatário e configuração de gateway
S2S.
- SDNExpressUndo.ps1
Limpa o ambiente de 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 ao 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
Enterprise gateway site a site e configuração de VM
cliente.
 N O M E DA PA STA DESC RIÇ Ã O

TenantApps Arquivos usados para implantar cargas de trabalho de

locatário de exemplo.

6. Verifique se Windows Server 2016 arquivo VHDX está na pasta Imagens.

7. Personalize o arquivo SDNExpress\scripts\FabricConfig.psd1 alterando as marcas<< Substituir >>por
valores específicos para se 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 de 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 do SDN Express foi concluído sem relatar erros, você pode executar a etapa a seguir para
garantir que os recursos de malha foram implantados corretamente e estão disponíveis para implantação de
locatário.
Use 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 sua implantação de 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 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 da 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<< Substituir >> por
valores específicos (por exemplo: nome da imagem VHD, nome REST do controlador de rede, nome do
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 undo. 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 efetuar ping no endereço IP de uma
das máquinas virtuais da camada da Web (verifique se Windows Firewall está desligado 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 em 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

em que é o endereço IP VIP da camada <VIP IP address> da Web configurado no arquivo

TenantConfig.psd1.

TIP
Pesquise VIPIP a variável TenantConfig.psd1.

Execute isso várias vezes para ver a opção do 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, abra uma nova instância e navegue novamente. Você
verá a página azul e a página verde alternativa, exceto quando o navegador armazenar em cache a
página antes que o cache esnoque.
 Implantar tecnologias de rede definidas pelo
software usando o Windows PowerShell
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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
10/08/2021 • 15 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

este tópico fornece instruções sobre como usar Windows PowerShell para implantar o controlador de rede em
uma ou mais máquinas virtuais (VMs) que estão executando o Windows Server 2019 ou 2016.

IMPORTANT
Não implante a função de servidor do controlador de rede em hosts físicos. Para implantar o controlador de rede, você
deve instalar a função de servidor do controlador de rede em uma VM de máquina virtual do Hyper-V ( ) instalada em
um host do 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 o SDN de rede definido pelo Software ( ) adicionando os hosts ao controlador de rede
usando o comando Windows PowerShell New-NetworkControllerSer ver . Ao fazer isso, você está permitindo que o
software SDN Load Balancer funcione. Para obter mais informações, consulte New-NetworkControllerServer.

Este tópico inclui as seções a seguir.

Instalar a função de servidor do controlador de rede
Configurar o cluster do controlador de rede
Configurar o aplicativo do controlador de rede
Validação de implantação do controlador de rede
comandos de Windows PowerShell adicionais para o controlador de rede
Exemplo de script de configuração do controlador de rede
Etapas pós-implantação para implantações não Kerberos

Instalar a função de servidor do controlador de rede

Você pode usar este procedimento para instalar a função de servidor do controlador de rede em uma VM de
máquina virtual ( ) .

IMPORTANT
Não implante a função de servidor do controlador de rede em hosts físicos. Para implantar o controlador de rede, você
deve instalar a função de servidor do controlador de rede em uma VM de máquina virtual do Hyper-V ( ) instalada em
um host do 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 o Sdn de rede definido pelo software ( ) adicionando os hosts ao controlador de rede. Ao
fazer isso, você está permitindo que o software SDN Load Balancer funcione.

A associação em Administradores , ou equivalente, é o requisito mínimo para executar este procedimento.

 NOTE
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 do 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 do controlador de rede fornece alta disponibilidade e escalabilidade para o aplicativo do controlador
de rede, que você pode configurar depois de criar o cluster e que é hospedado na parte superior do cluster.

NOTE
você pode executar os procedimentos nas seções a seguir diretamente na VM em que você instalou o controlador de
rede ou pode usar o Ferramentas de Administração de Servidor Remoto para Windows Server 2016 para executar os
procedimentos de um computador remoto que esteja executando Windows Server 2016 ou Windows 10. Além disso, a
associação em Administradores , ou equivalente, é o requisito mínimo necessário para executar esse procedimento. Se o
computador ou a VM na qual você instalou o controlador de rede estiver ingressado em um domínio, sua conta de
usuário deverá ser membro de usuários de domínio .

Você pode criar um cluster de controlador de rede criando um objeto de nó e, em seguida, configurando o
cluster.
Criar um objeto de nó
Você precisa criar um objeto de nó para cada VM que seja membro do cluster do controlador de rede.
para criar um objeto de nó, digite o seguinte comando no prompt de comando Windows PowerShell e
pressione ENTER. Certifique-se de adicionar valores para cada parâmetro que são apropriados 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

.

PA RÂ M ET RO DESC RIÇ Ã O

Nome O parâmetro Name especifica o nome amigável do servidor

que você deseja adicionar ao cluster
 PA RÂ M ET RO DESC RIÇ Ã O

Servidor O parâmetro Ser ver 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 causada por 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 que provavelmente falham juntos em um ponto
mais alto na árvore de domínio de falha. Durante o tempo
de execução, 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", em que
DC1 é o nome do datacenter, Rack1 é o nome do rack e
Host1 é o nome do host onde o nó é colocado.

RestInterface O parâmetro RestInterface especifica o nome da interface

no nó em que a comunicação de transferência de estado de
reapresentação (REST) é encerrada. Essa interface de
controlador de rede recebe solicitações de API Northbound
da camada de gerenciamento da rede.

NodeCertificate O parâmetro NodeCer tificate especifica o certificado que o

controlador de rede usa para autenticação do 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 seguinte comando no prompt de comando Windows PowerShell e pressione
ENTER. Certifique-se de adicionar valores para cada parâmetro que são apropriados 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 .

PA RÂ M ET RO DESC RIÇ Ã O
PA RÂ M ET RO DESC RIÇ Ã O

ClusterAuthentication O parâmetro ClusterAuthentication especifica o tipo de

autenticação que é usado para proteger a comunicação
entre os 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 esse comando.

ManagementSecurityGroup O parâmetro ManagementSecurityGroup especifica o

nome do grupo de segurança que contém os 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 de controlador

de rede que você criou usando o comando New-
NetworkControllerNodeObject .

DiagnosticLogLocation O parâmetro DiagnosticLogLocation especifica o local de

compartilhamento onde 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 que são necessárias para acessar o local de
compartilhamento onde os logs são armazenados.

CredentialEncryptionCertificate O parâmetro CredentialEncr yptionCer tificate especifica

o certificado que o controlador de rede usa para criptografar
as credenciais que são usadas para acessar os 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 não
criptografado e podem ser usadas inalteradas por qualquer
usuário não autorizado.

Credencial Esse parâmetro será necessário somente se você estiver

executando esse comando de 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.
 PA RÂ M ET RO DESC RIÇ Ã O

CertificateThumbprint Esse parâmetro será necessário somente se você estiver

executando esse comando de um computador remoto. O
parâmetro Cer tificateThumbprint 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 só será necessário se você estiver

executando esse comando em um computador remoto. O
parâmetro UseSSL especifica o protocolo protocolo SSL
(SSL) 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á 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 é 3 dias.

Configurar o aplicativo controlador de rede

Para configurar o aplicativo Controlador de Rede, digite o seguinte comando no prompt Windows PowerShell
comando e pressione ENTER. Certifique-se de adicionar 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.

PA RÂ M ET RO DESC RIÇ Ã O

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 Nenhum. A autenticação Kerberos usa
contas de domínio e só poderá ser usada se os nós do
Controlador de Rede ingressarem no domínio. Se você
especificar a autenticação baseada em X509, deverá fornecer
um certificado no objeto NetworkControllerNode. Além
disso, você deve provisioná-lo manualmente antes de
executar esse comando.
PA RÂ M ET RO DESC RIÇ Ã O

Nó O parâmetro Node especifica a lista de nós do

Controlador de Rede que você criou usando o comando
New-NetworkControllerNodeObject.

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
ClientCer tificateThumbprint especifica a impressão
digital do certificado que é inscrito nos clientes na camada
Northbound.

ServerCertificate O parâmetro Ser verCer tificate 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 de Uso
Aprimorado 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 implantação de nó único 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 assunto de
Ser verCer tificate 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 estão na mesma
sub-rede. Se os nós estão em sub-redes diferentes, você
deve 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 só será
necessário 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 só será necessário 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.
 PA RÂ M ET RO DESC RIÇ Ã O

CertificateThumbprint Esse parâmetro só será necessário se você estiver

executando esse comando em um computador remoto. O
parâmetro Cer tificateThumbprint 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 só será necessário se você estiver

executando esse comando em um computador remoto. O
parâmetro UseSSL especifica o protocolo protocolo SSL
(SSL) 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, a 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 ao
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. Certifique-se de adicionar 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 que você adicionou ao Controlador de Rede, digite o comando a seguir e
pressione ENTER. Certifique-se de adicionar valores para cada parâmetro apropriado para sua
implantação.

Get-NetworkControllerCredential -ConnectionUri https://networkcontroller -ResourceId cred1

4. Revise 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

NOTE
Ao executar o comando Get-NetworkControllerCredential, você pode atribuir a saída do comando a uma
variável usando o operador dot para listar as propriedades das credenciais. Por exemplo, $cred. Propriedades.

Comandos Windows PowerShell adicionais para o Controlador de

Rede
Depois de implantar o Controlador de Rede, você pode 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
Gerencie nós de cluster do Controlador de Rede, incluindo adicionar, remover, habilenciar e desabilitar
nós.
A tabela a seguir fornece a sintaxe Windows PowerShell comandos que você pode usar para realizar essas
tarefas.

TA REFA C O M A N DO SIN TA XE

Modificar configurações de cluster do Set-NetworkControllerCluster Set-NetworkControllerCluster [-

Controlador de Rede ManagementSecurityGroup
<string>][-Credential
<PSCredential>] [-computerName
<string>][-CertificateThumbprint
<String> ] [-UseSSL]

Modificar configurações de aplicativo Set-NetworkController Set-NetworkController [-

do Controlador de Rede ClientAuthentication
<ClientAuthentication>] [-
Credential <PSCredential>] [-
ClientCertificateThumbprint
<string[]>] [-
ClientSecurityGroup <string>] [-
ServerCertificate
<X509Certificate2>] [-
RestIPAddress <String>] [-
ComputerName <String>][-
CertificateThumbprint <String> ]
[-UseSSL]

Modificar configurações de nó do Set-NetworkControllerNode Set-NetworkControllerNode -Name

Controlador de Rede <string> > [-RestInterface
<string>] [-NodeCertificate
<X509Certificate2>] [-Credential
<PSCredential>] [-ComputerName
<string>][-CertificateThumbprint
<String> ] [-UseSSL]
 TA REFA C O M A N DO SIN TA XE

Modificar configurações de diagnóstico Set-NetworkControllerDiagnostic Set-NetworkControllerDiagnostic

do Controlador de Rede [-LogScope <string>] [-
DiagnosticLogLocation <string>]
[-LogLocationCredential
<PSCredential>] [-
UseLocalLogLocation] >] [-
LogLevel <loglevel>][-
LogSizeLimitInMBs <uint32>] [-
LogTimeLimitInDays <uint32>] [-
Credential <PSCredential>] [-
ComputerName <string>][-
CertificateThumbprint <String> ]
[-UseSSL]

Remover o aplicativo controlador de Uninstall-NetworkController Uninstall-NetworkController [-

rede Credential <PSCredential>][-
ComputerName <string>] [-
CertificateThumbprint <String> ]
[-UseSSL]

Remover o cluster do Controlador de Uninstall-NetworkControllerCluster Uninstall-

Rede NetworkControllerCluster [-
Credential <PSCredential>][-
ComputerName <string>][-
CertificateThumbprint <String> ]
[-UseSSL]

Adicionar um nó ao cluster do Add-NetworkControllerNode Add-NetworkControllerNode -

Controlador de Rede FaultDomain <String> -Name
<String> -RestInterface <String>
-Server <String> [-
CertificateThumbprint <String> ]
[-ComputerName <String> ] [-
Credential <PSCredential> ] [-
Force] [-NodeCertificate
<X509Certificate2> ] [-PassThru]
[-UseSsl]

Desabilitar um nó de cluster do Disable-NetworkControllerNode Disable-NetworkControllerNode -

Controlador de Rede Name <String> [-
CertificateThumbprint <String> ]
[-ComputerName <String> ] [-
Credential <PSCredential> ] [-
PassThru] [-UseSsl]

Habilitar um nó de cluster do Enable-NetworkControllerNode Enable-NetworkControllerNode -

Controlador de Rede Name <String> [-
CertificateThumbprint <String> ]
[-ComputerName <String> ] [-
Credential <PSCredential> ] [-
PassThru] [-UseSsl]

Remover um nó do Controlador de Remove-NetworkControllerNode Remove-NetworkControllerNode [-

Rede de um cluster CertificateThumbprint <String> ]
[-ComputerName <String> ] [-
Credential <PSCredential> ] [-
Force] [-Name <String> ] [-
PassThru] [-UseSsl]

NOTE
Windows PowerShell comandos para o Controlador de Rede estão na Biblioteca do 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 $cert de dados seleciona um certificado do
armazenamento de certificados do computador local que corresponde à cadeia de caracteres de nome da
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 -FaultDomain fd:/rack1/host2 -
RestInterface Internal
$c = New-NetworkControllerNodeObject -Name Node3 -Server NCNode3.contoso.com -FaultDomain fd:/rack1/host3 -
RestInterface Internal

$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 Etapas pós-implantação para o controlador de rede.
 Gerenciar SDN
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar os tópicos desta seção para gerenciar a rede definida pelo software, incluindo cargas de
trabalho de locatário e redes virtuais.

NOTE
Para obter uma documentação adicional de rede definida pelo software, você pode usar as seções de biblioteca a seguir.
Tecnologias de SDN
Planejar SDN
Implantar SDN
Segurança para SDN
Solucionar problemas de SDN

Esta seção contém os seguintes tópicos.

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
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

Você pode usar os tópicos nesta seção para gerenciar Redes Virtuais de Virtualização de Rede Hyper-V do
Locatário depois de implantar a Rede Definida pelo Software usando o tópico Implantar uma infraestrutura de
rede definida pelo software usando scripts.
Esta seção contém os seguintes tópicos.
Noções básicas sobre o uso de redes virtuais e VLANs
Usar 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
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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 baseia-se na política de programação para
sobrepor 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.
 Criar, excluir ou atualizar redes virtuais do locatário
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, você aprenderá a criar, excluir e atualizar redes virtuais de virtualização de rede Hyper-V depois de
implantar o SDN (rede definida pelo software). A virtualização de rede Hyper-V ajuda você a isolar redes de
locatários para que cada rede de locatários 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 do
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 fazem referência a 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 do locatário é encapsulado.
3. Crie pelo menos uma sub-rede virtual para cada prefixo IP que você identificou na etapa 1.
4. Adicional 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. A Fabrikam do
locatário tem duas sub-redes virtuais, enquanto o locatário da Contoso tem três sub-redes virtuais.

N O M E DO LO C ATÁ RIO ID DE SUB - REDE VIRT UA L P REF IXO DE SUB - REDE VIRT UA L

Fabrikam 5001 24.30.1.0/24

Fabrikam 5002 24.30.2.0/20

Contoso 6001 24.30.1.0/24

Contoso 6002 24.30.2.0/24

Contoso 6003 24.30.3.0/24

o script de exemplo a seguir usa Windows PowerShell comandos exportados do módulo NetworkController
para criar a rede virtual da Contoso e uma sub-rede:
 import-module networkcontroller
$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 rede ou sub-rede Virtual existente.
Quando você executa o script de exemplo a seguir, os recursos atualizados são simplesmente colocados no
controlador de rede com a mesma ID de recurso. Se o locatário contoso quiser adicionar uma nova sub-rede
virtual (24.30.2.0/24) à sua rede virtual, você ou o administrador da Contoso poderão usar o script a seguir.

$acllist = Get-NetworkControllerAccessControlList -ConnectionUri $uri -ResourceId "AllowAll"

$vnet = Get-NetworkControllerVirtualNetwork -ResourceId "Contoso_VNet1" -ConnectionUri $uri

$vnet.properties.AddressSpace.AddressPrefixes += "24.30.2.0/24"

$vsubnet = new-object Microsoft.Windows.NetworkController.VirtualSubnet

$vsubnet.ResourceId = "Contoso_DBTier"
$vsubnet.Properties = new-object Microsoft.Windows.NetworkController.VirtualSubnetProperties
$vsubnet.Properties.AccessControlList = $acllist
$vsubnet.Properties.AddressPrefix = "24.30.2.0/24"

$vnet.properties.Subnets += $vsubnet

New-NetworkControllerVirtualNetwork -ResourceId "Contoso_VNet1" -ConnectionUri $uri -properties

$vnet.properties

Excluir uma rede virtual

você pode usar Windows PowerShell para excluir uma rede Virtual.
o exemplo a seguir Windows PowerShell exclui uma rede Virtual de locatário emitindo uma exclusão HTTP para
o URI da ID do recurso.

Remove-NetworkControllerVirtualNetwork -ResourceId "Contoso_Vnet1" -ConnectionUri $uri

 Adicionar um gateway virtual a uma rede virtual de
locatário
12/08/2021 • 9 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Saiba como usar Windows PowerShell 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 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, Border Gateway Protocol (BGP). Quando você fornece conectividade
site a site, seus clientes podem conectar sua rede virtual de locatário a uma rede externa, como uma rede
corporativa de locatário, uma rede de provedor de serviços ou a Internet.
Ao implantar um Gateway Vir tual de Locatário, você tem as seguintes opções de configuração:

O P Ç Õ ES DE C O N EXÃ O DE REDE O P Ç Õ ES DE C O N F IGURA Ç Ã O DE B GP

VPN (rede virtual privada) site a site do IPSec Configuração do roteador BGP
GRE (Encapsulamento de Roteamento Genérico) Configuração de par BGP
Encaminhamento de camada 3 Configuração de políticas de roteamento BGP

Os Windows PowerShell exemplo de scripts e comandos neste tópico demonstram como implantar um gateway
virtual de locatário em um Gateway ras com cada uma dessas opções.

IMPORTANT
Antes de executar qualquer um dos comandos Windows PowerShell e scripts 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.

$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 fora 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.
 $uri = "https://ncrest.contoso.com"

# Retrieve the Tenant Virtual Network configuration

$Vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId "Contoso_Vnet1"

# Display in JSON format

$Vnet | ConvertTo-Json -Depth 4

# Retrieve the Tenant Virtual Subnet configuration

$RoutingSubnet = Get-NetworkControllerVirtualSubnet -ConnectionUri $uri -ResourceId
"Contoso_WebTier" -VirtualNetworkID $vnet.ResourceId

# Display in JSON format

$RoutingSubnet | ConvertTo-Json -Depth 4

3. Crie um novo objeto para o gateway virtual de locatário e, em seguida, 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, atualize o restante das propriedades do objeto do
gateway virtual e adicione o novo gateway virtual para o locatário.

# 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).

TIP
Opcionalmente, você pode combinar todas as etapas anteriores e configurar um gateway virtual de locatário com
todas 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

 # 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.PerfectForwardSecrecy = "PFS2048"
$nwConnectionProperties.IpSecConfiguration.QuickMode.AuthenticationTransformationConstant =
"SHA256128"
$nwConnectionProperties.IpSecConfiguration.QuickMode.CipherTransformationConstant = "DES3"
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeSeconds = 1233
$nwConnectionProperties.IpSecConfiguration.QuickMode.IdleDisconnectSeconds = 500
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeKiloBytes = 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 da VPN GRE

 # Create a new object for the Tenant Network Connection
$nwConnectionProperties = New-Object Microsoft.Windows.NetworkController.NetworkConnectionProperties

# Update the common object properties

$nwConnectionProperties.ConnectionType = "GRE"
$nwConnectionProperties.OutboundKiloBitsPerSecond = 10000
$nwConnectionProperties.InboundKiloBitsPerSecond = 10000

# Update specific properties depending on the Connection Type

$nwConnectionProperties.GreConfiguration = New-Object
Microsoft.Windows.NetworkController.GreConfiguration
$nwConnectionProperties.GreConfiguration.GreKey = 1234

# 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.2.20.1/32"
$ipv4Route.metric = 10
$nwConnectionProperties.Routes += $ipv4Route

# Tunnel Destination (Remote Endpoint) Address

$nwConnectionProperties.DestinationIPAddress = "10.127.134.122"

# L3 specific configuration (leave blank for GRE)

$nwConnectionProperties.L3Configuration = New-Object
Microsoft.Windows.NetworkController.L3Configuration
$nwConnectionProperties.IPAddresses = @()
$nwConnectionProperties.PeerIPAddresses = @()

# Add the new Network Connection for the tenant

New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId
$virtualGW.ResourceId -ResourceId "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.

# 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.

# Create a new object for the Tenant Network Connection

$nwConnectionProperties = New-Object
Microsoft.Windows.NetworkController.NetworkConnectionProperties

# Update the common object properties

$nwConnectionProperties.ConnectionType = "L3"
$nwConnectionProperties.OutboundKiloBitsPerSecond = 10000
$nwConnectionProperties.InboundKiloBitsPerSecond = 10000

# GRE specific configuration (leave blank for L3)

$nwConnectionProperties.GreConfiguration = New-Object
Microsoft.Windows.NetworkController.GreConfiguration

# Update specific properties depending on the Connection Type

$nwConnectionProperties.L3Configuration = New-Object
Microsoft.Windows.NetworkController.L3Configuration
$nwConnectionProperties.L3Configuration.VlanSubnet = $vlanNetwork.properties.Subnets[0]

$nwConnectionProperties.IPAddresses = @()
$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")

# 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.2.20.1/32"
$ipv4Route.metric = 10
$nwConnectionProperties.Routes += $ipv4Route

# Add the new Network Connection for the tenant

New-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId
$virtualGW.ResourceId -ResourceId "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.

# 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 de BGP para esse locatário, correspondente à Conexão de Rede VPN site a site
adicionada acima.
 # 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:

# 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 Microsoft.Windows.NetworkController.NetworkConnectionProperties
$ipSecConnection.Properties.ConnectionType = "IPSec"
$ipSecConnection.Properties.OutboundKiloBitsPerSecond = 10000
$ipSecConnection.Properties.InboundKiloBitsPerSecond = 10000

$ipSecConnection.Properties.IpSecConfiguration = New-Object
Microsoft.Windows.NetworkController.IpSecConfiguration

$ipSecConnection.Properties.IpSecConfiguration.AuthenticationMethod = "PSK"
$ipSecConnection.Properties.IpSecConfiguration.SharedSecret = "P@ssw0rd"

$ipSecConnection.Properties.IpSecConfiguration.QuickMode = New-Object
Microsoft.Windows.NetworkController.QuickMode

$ipSecConnection.Properties.IpSecConfiguration.QuickMode.PerfectForwardSecrecy = "PFS2048"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.AuthenticationTransformationConstant = "SHA256128"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.CipherTransformationConstant = "DES3"
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.SALifeTimeSeconds = 1233
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.IdleDisconnectSeconds = 500
$ipSecConnection.Properties.IpSecConfiguration.QuickMode.SALifeTimeKiloBytes = 2000

$ipSecConnection.Properties.IpSecConfiguration.MainMode = New-Object
Microsoft.Windows.NetworkController.MainMode
$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 = @()

$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo

$ipv4Route.DestinationPrefix = "14.1.10.1/32"
$ipv4Route.metric = 10
$ipSecConnection.Properties.Routes += $ipv4Route

$ipSecConnection.Properties.DestinationIPAddress = "10.127.134.121"

# GRE Connection configuration

$greConnection = New-Object Microsoft.Windows.NetworkController.NetworkConnection
$greConnection.ResourceId = "Contoso_GreGW"

$greConnection.Properties = New-Object Microsoft.Windows.NetworkController.NetworkConnectionProperties

$greConnection.Properties.ConnectionType = "GRE"
$greConnection.Properties.OutboundKiloBitsPerSecond = 10000
$greConnection.Properties.InboundKiloBitsPerSecond = 10000

$greConnection.Properties.GreConfiguration = New-Object Microsoft.Windows.NetworkController.GreConfiguration

$greConnection.Properties.GreConfiguration.GreKey = 1234

$greConnection.Properties.IPAddresses = @()
$greConnection.Properties.PeerIPAddresses = @()

$greConnection.Properties.Routes = @()

$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo

$ipv4Route.DestinationPrefix = "14.2.20.1/32"
$ipv4Route.metric = 10
$greConnection.Properties.Routes += $ipv4Route

$greConnection.Properties.DestinationIPAddress = "10.127.134.122"

$greConnection.Properties.L3Configuration = New-Object Microsoft.Windows.NetworkController.L3Configuration

# L3 Forwarding connection configuration

$l3Connection = New-Object Microsoft.Windows.NetworkController.NetworkConnection
$l3Connection.ResourceId = "Contoso_L3GW"

$l3Connection.Properties = New-Object Microsoft.Windows.NetworkController.NetworkConnectionProperties

$l3Connection.Properties.ConnectionType = "L3"
$l3Connection.Properties.OutboundKiloBitsPerSecond = 10000
$l3Connection.Properties.InboundKiloBitsPerSecond = 10000

$l3Connection.Properties.GreConfiguration = New-Object Microsoft.Windows.NetworkController.GreConfiguration

$l3Connection.Properties.L3Configuration = New-Object Microsoft.Windows.NetworkController.L3Configuration
$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 = @()
$ipv4Route = New-Object Microsoft.Windows.NetworkController.RouteInfo
$ipv4Route.DestinationPrefix = "14.2.20.1/32"
$ipv4Route.metric = 10
 $ipv4Route.metric = 10
$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 Microsoft.Windows.NetworkController.VGwBgpPeerProperties

$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 Microsoft.Windows.NetworkController.VGwBgpPeerProperties

$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 Microsoft.Windows.NetworkController.VGwBgpPeerProperties

$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

$nwConnection = Get-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId

"Contoso_VirtualGW" -ResourceId "Contoso_IPSecGW"

Navegue até a estrutura da variável para acessar a propriedade necessária e defini-la como o
valor de atualizações

$nwConnection.properties.IpSecConfiguration.SharedSecret = "C0mplexP@ssW0rd"

Adicione a configuração modificada para substituir a configuração mais antiga no Controlador de

Rede

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 recursos de gateway individuais ou o
gateway inteiro.
Remover uma conexão de rede

Remove-NetworkControllerVirtualGatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId

"Contoso_VirtualGW" -ResourceId "Contoso_IPSecGW" -Force

Remover um par BGP

Remove-NetworkControllerVirtualGatewayBgpPeer -ConnectionUri $uri -VirtualGatewayId "Contoso_VirtualGW" -

BgpRouterName "Contoso_BgpRouter1" -ResourceId "Contoso_IPSec_Peer" -Force

Remover um roteador BGP

Remove-NetworkControllerVirtualGatewayBgpRouter -ConnectionUri $uri -VirtualGatewayId "Contoso_VirtualGW" -

ResourceId "Contoso_BgpRouter1" -Force

Remover um gateway

Remove-NetworkControllerVirtualGateway -ConnectionUri $uri -ResourceId "Contoso_VirtualGW" -Force

 Conectar pontos de extremidade do contêiner a
uma rede virtual do locatário
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, mostraremos como conectar pontos de extremidade do contêiner a uma rede virtual de locatário
existente criada por meio de SDN. use o driver de rede l2bridge (e, opcionalmente, l2tunnel) disponível com o
plug-in Windows libnetwork para o docker para criar uma rede de contêiner na VM de locatário.
No tópico drivers de rede do contêiner , discutimos que os vários drivers de rede estão disponíveis por meio do
Docker no Windows. Para SDN, use os drivers l2bridge e l2tunnel . Para ambos os drivers, cada ponto de
extremidade do contêiner está na mesma sub-rede virtual que a máquina virtual do host do contêiner
(locatário).
O serviço de rede de host (HNS), 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 do 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ço da camada 2.
A política de rede (ACLs, encapsulamento e QoS) para esses pontos de extremidade de contêiner são impostas
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:

L 2B RIDGE L 2T UN N EL

Pontos de extremidade do contêiner que residem em: Todo o tráfego de rede entre dois pontos de extremidade de
A mesma máquina virtual do host do contêiner e na contêiner é encaminhado para o host do Hyper-V físico,
mesma sub-rede têm todo o tráfego de rede ponte independentemente do host ou da sub-rede. A política de
dentro do comutador virtual do Hyper-V. rede se aplica a tráfego de rede entre sub-redes e entre
VMs de host de contêiner diferentes ou em sub- hosts.
redes diferentes têm seu tráfego encaminhado para o
host do Hyper-V físico.
A política de rede não é imposta, pois o tráfego de rede
entre os contêineres no mesmo host e na mesma sub-rede
não flui para o host físico. A política de rede aplica-se
somente ao tráfego de rede do contêiner entre hosts ou
entre sub-redes.

NOTE
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 de 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 recurso de contêiner Windows habilitado, docker
instalado e recurso do Hyper-V habilitado. O recurso Hyper-V é necessário para instalar vários binários
para redes l2bridge e l2tunnel.

# To install HyperV feature without checks for nested virtualization

dism /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V /All

NOTE
A virtualização aninhada e a exposição de extensões de virtualização não são necessárias, a menos que usem contêineres
Hyper-V.

Fluxo de trabalho
1. Adicione várias configurações de IP a um recurso de NIC de VM existente por meio do controlador de rede
(host Hyper-V) 2. Habilite o proxy de rede no host para alocar endereços IP de CA para pontos de extremidade
de contêiner (host Hyper-V) 3. Instale o plug-in de nuvem privada para atribuir endereços IP de autoridade de
certificação aos pontos de extremidade do contêiner (VM do host do contêiner) 4. Criar uma rede l2bridge ou
l2tunnel usando o Docker (VM do host do contêiner)

NOTE
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 NIC da VM fora da banda
usando o PowerShell do controlador de rede.

1. adicionar várias configurações de IP

Nesta etapa, assumimos que a NIC da VM da máquina virtual de locatário tem uma configuração de IP com o
endereço IP de 192.168.1.9 e está anexada a uma ID de recurso de VNet de ' VNet1 ' e recurso de sub-rede 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-
192.168.1.110.
 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 -ResourceId "AllowAll"

foreach ($i in 1..10)

{
$newipconfig = new-object Microsoft.Windows.NetworkController.NetworkInterfaceIpConfiguration
$props = new-object Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationProperties

$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ê habilita o proxy de rede para alocar vários endereços IP para a máquina virtual do host do
contêiner.
Para habilitar o proxy de rede, execute o script ConfigureMCNP.ps1 no host Hyper-V que hospeda a máquina
virtual de host (locatário) do contêiner.

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 de InstallPrivateCloudPlugin.ps1 dentro da máquina vir tual de host
(locatário) do contêiner .

PS C:\> InstallPrivateCloudPlugin.ps1

4. criar uma rede de contêiner l2bridge

Nesta etapa, você usa o docker network create comando na máquina vir tual do host do contêiner
(locatário) para criar uma rede l2bridge.

# 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>

NOTE
A atribuição de IP estático não tem suporte com redes de contêiner l2bridge ou l2tunnel quando usadas com a pilha do
Microsoft Sdn.

Mais informações
Para obter mais detalhes sobre como implantar uma infraestrutura de SDN, consulte implantar uma
infraestrutura de rede definida pelo software.
 Configurar a criptografia para uma sub-rede virtual
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

A criptografia de rede virtual permite a criptografia do tráfego de rede virtual entre VMs que se comunicam
entre si em 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 que referencia a 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 cruze o limite da rede virtual também é enviado descriptografado.

NOTE
Ao se comunicar com outra VM na mesma sub-rede, esteja ela conectada ou conectada posteriormente, o tráfego é
criptografado automaticamente.

TIP
Se você tiver que restringir os aplicativos a se comunicarem apenas na sub-rede criptografada, poderá usar ACLs (Listas
de Controle de Acesso) somente para permitir a comunicação dentro da sub-rede atual. Para obter mais informações,
consulte Usar ACLs (listasde controle de acesso) para gerenciar o tráfego de rede do datacenter 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 será exibido na Minha loja:

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:\

Mode LastWriteTime Length Name

---- ------------- ------ ----
-a---- 9/22/2017 4:54 PM 543 EncryptedVirtualNetworks.cer
-a---- 9/22/2017 4:54 PM 1706 EncryptedVirtualNetworks.pfx

4. Instalando 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 meu
armazenamento de cada host Hyper-V.
6. Verifique a instalação do certificado.
Verifique os certificados verificando o conteúdo dos armazenamentos 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
---------- -------
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks

PSParentPath: Microsoft.PowerShell.Security\Certificate::localmachine\root

Thumbprint Subject
---------- -------
5EFF2CE51EACA82408572A56AE1A9BCC7E0843C6 CN=EncryptedVirtualNetworks

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 que
contém 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 Microsoft.Windows.NetworkController.CredentialProperties

$credproperties.Type = "X509Certificate"
$credproperties.Value = $thumbprint
New-networkcontrollercredential -connectionuri $uri -resourceid "EncryptedNetworkCertificate" -properties
$credproperties -force

TIP
Você pode reutilizar essa credencial para cada rede virtual criptografada ou pode implantar e usar um certificado exclusivo
para cada locatário.

Etapa 3. Configurando uma rede virtual para criptografia

Esta etapa pressu que você já criou 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.
 NOTE
Ao se comunicar com outra VM na mesma sub-rede, esteja ela conectada ou conectada posteriormente, o tráfego é
criptografado automaticamente.

1. Recupere os objetos Rede Virtual e Credencial 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 habilita 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 de 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 essas etapas.

 Saída de medição em uma rede virtual
12/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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.

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.
 $vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceID "VNet1"
$vnet.Properties.UnbilledAddressRanges = "10.10.2.0/24,10.10.3.0/24"

TIP
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.

New-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId "VNet1" -Properties

$unbilled.Properties -PassInnerException

Sua saída será semelhante a esta:

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 : Microsoft.Windows.NetworkController.VirtualNetworkProperties

3. Verifique a Rede Virtual para ver o UnbilledAddressRanges configurado.

(Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceID "VNet1").properties

Sua saída agora será semelhante a esta:

AddressSpace : Microsoft.Windows.NetworkController.AddressSpace
DhcpOptions :
UnbilledAddressRanges : 10.10.2.0/24,192.168.2.0/24
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

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:

(Get-NetworkControllerVirtualNetwork -ConnectionURI $URI -ResourceId "VNet1").properties.subnets.properties

| ft AddressPrefix,BilledEgressBytes,UnbilledEgressBytes

Sua saída será semelhante a esta:

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
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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 a 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 Load Balancer de software para balanceamento de carga e NAT (conversão de endereços de
rede)
Usar dispositivos de rede virtual 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
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, você cria uma VM de locatário e a conecta a uma rede virtual que você criou com a virtualização
de rede Hyper-V ou a uma rede de área local virtual (VLAN). 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 na rede virtual.
as seções neste tópico incluem o exemplo Windows PowerShell comandos que contêm valores de exemplo para
muitos parâmetros. Certifique-se de substituir os valores de exemplo nesses comandos por valores apropriados
para sua implantação antes de executar esses comandos.

Pré-requisitos
1. Adaptadores de rede 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 falhe.
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 esse adaptador de rede, crie a ACL agora usando as
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 VM que tenha um endereço MAC estático.
 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.

$vnet = get-networkcontrollervirtualnetwork -connectionuri $uri -ResourceId "Contoso_WebTier"

3. Crie um objeto de interface de rede no controlador de rede.

TIP
Nesta etapa, você usa a ACL personalizada.

$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 Microsoft.Windows.NetworkController.NetworkInterfaceIpConfiguration

$ipconfiguration.resourceid = "MyVM_IP1"
$ipconfiguration.properties = new-object
Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationProperties
$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.

$nic = Get-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId "MyVM_Ethernet1"

5. Defina a ID da interface na porta do adaptador de rede da VM do Hyper-V.

NOTE
Você deve executar esses comandos no host do Hyper-V onde a VM está instalada.
 #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 $vmNic

}

6. Inicie a VM.

Get-VM -Name "MyVM" | Start-VM

Você criou uma VM com êxito, conectou a VM a uma rede virtual de locatário 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 o

NetworkControllerRESTWrappers
1. Crie a VM e atribua um endereço MAC estático à VM.

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.

Set-VMNetworkAdapterIsolation –VMName "MyVM" -AllowUntaggedTraffic $true -IsolationMode VLAN -

DefaultIsolationId 123

3. Obtenha a sub-rede da rede lógica e crie a interface de rede.

 $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 Microsoft.Windows.NetworkController.NetworkInterfaceIpConfiguration

$ipconfiguration.resourceid = "MyVM_Ip1"
$ipconfiguration.properties = new-object
Microsoft.Windows.NetworkController.NetworkInterfaceIpConfigurationProperties
$ipconfiguration.properties.PrivateIPAddress = "10.127.132.177"
$ipconfiguration.properties.PrivateIPAllocationMethod = "Static"

$ipconfiguration.properties.Subnet = new-object Microsoft.Windows.NetworkController.Subnet

$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 Hyper-V.

#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 $vmNic

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 $vmNic

}
else
{
$CurrentFeature.SettingData.ProfileId = "{$InstanceId}"
$CurrentFeature.SettingData.ProfileData = 1

Set-VMSwitchExtensionPortFeature -VMSwitchExtensionFeature $CurrentFeature -VMNetworkAdapter

$vmNic
}

5. Inicie a VM.
 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
20/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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:
OutboundReser vedValue – se outboundReservedMode 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:

$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:

$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:

$NwInterface.Properties.PortSettings.QosSettings=
[Microsoft.Windows.NetworkController.VirtualNetworkInterfaceQosSettings]::new()
$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 Compute tipo de
tentativa. Para obter mais informações, consulte simplificar a rede do host com a rede ATC.

NOTE
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.

IMPORTANT
Você deve garantir que o QosOffload 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:
 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.

$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:

$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.

IMPORTANT
O descarregamento de QoS dá suporte apenas a OutboundMaximumMbps . Você não pode usar
OutboundReser vedValue ou InboundMaximumMbps com descarregamento de QoS.

$NwInterface.Properties.PortSettings.QosSettings=
[Microsoft.Windows.NetworkController.VirtualNetworkInterfaceQosSettings]::new()
$NwInterface.Properties.PortSettings.QosSettings. EnableHardwareLimits=$true
$NwInterface.Properties.PortSettings.QosSettings.OutboundMaximumMbps ="1000"
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId $NwInterface.ResourceId -Properties
$NwInterface.Properties

NOTE
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.
 Configurar o balanceador de carga de software
para balanceamento de carga e Conversão de
endereços de rede (NAT)
12/08/2021 • 7 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar este tópico para aprender a usar o SLB do balanceador de carga de software de rede definido
pelo software ( Sdn ) ( ) para fornecer ( NAT ) de conversão de endereços 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 software SDN Load Balancer ( SLB ) oferece alta disponibilidade e desempenho de rede para seus aplicativos.
É um TCP de camada 4 ( , ) balanceador de carga 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 a carga do tráfego de entrada externo a uma rede virtual para VMs de 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 VM da rede virtual para destinos externos usando a NAT (conversão de
endereços de rede), também chamada de NAT de saída.
Encaminhe o tráfego externo para uma VM específica, também chamada de 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 às solicitações para o VIP. Este exemplo de código 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.

import-module NetworkController

$URI = "https://sdn.contoso.com"

$LBResourceId = "LB2"

$LoadBalancerProperties = new-object Microsoft.Windows.NetworkController.LoadBalancerProperties

2. Atribua um endereço IP de front-end, comumente conhecido como VIP (IP virtual).

O VIP deve ser de um IP não utilizado em um dos pools de IP de rede lógica fornecidos ao Gerenciador
 de balanceadores de carga.

$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/$($FrontEndIPConfig.ResourceId)"

$FrontEndIPConfig.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfigurationProperties
$FrontEndIPConfig.Properties.Subnet = new-object Microsoft.Windows.NetworkController.Subnet
$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.

$BackEndAddressPool = new-object Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPool

$BackEndAddressPool.ResourceId = "BE1"
$BackEndAddressPool.ResourceRef =
"/loadBalancers/$LBResourceId/backendAddressPools/$($BackEndAddressPool.ResourceId)"

$BackEndAddressPool.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPoolProperties

$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 200 para 11 consultas
consecutivas para que a investigação considere o IP de back-end a ser íntegro. Se o IP de back-end não
estiver íntegro, ele não receberá o tráfego do balanceador de carga.

IMPORTANT
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ê aplicar 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.

 $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 de 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:

$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:

$LoadBalancerResource = New-NetworkControllerLoadBalancer -ConnectionUri $URI -ResourceId

$LBResourceId -Properties $LoadBalancerProperties -Force -PassInnerException

7. Siga o exemplo a seguir para adicionar as interfaces de rede a esse pool de back-ends.

Exemplo: usar SLB para NAT de saída

Neste exemplo, você configura o SLB com um pool de back-end para fornecer o recurso de NAT de saída para
uma VM no espaço de endereço privado de uma rede virtual para alcançar 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.
 import-module NetworkController
$URI = "https://sdn.contoso.com"

$LBResourceId = "OutboundNATMMembers"
$VIPIP = "10.127.134.6"

$VIPLogicalNetwork = get-networkcontrollerlogicalnetwork -ConnectionUri $uri -resourceid "PublicVIP"

-PassInnerException

$LoadBalancerProperties = new-object Microsoft.Windows.NetworkController.LoadBalancerProperties

$FrontEndIPConfig = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfiguration
$FrontEndIPConfig.ResourceId = "FE1"
$FrontEndIPConfig.ResourceRef =
"/loadBalancers/$LBResourceId/frontendIPConfigurations/$($FrontEndIPConfig.ResourceId)"

$FrontEndIPConfig.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfigurationProperties
$FrontEndIPConfig.Properties.Subnet = new-object Microsoft.Windows.NetworkController.Subnet
$FrontEndIPConfig.Properties.Subnet.ResourceRef =
$VIPLogicalNetwork.Properties.Subnets[0].ResourceRef
$FrontEndIPConfig.Properties.PrivateIPAddress = $VIPIP
$FrontEndIPConfig.Properties.PrivateIPAllocationMethod = "Static"

$LoadBalancerProperties.FrontEndIPConfigurations += $FrontEndIPConfig

$BackEndAddressPool = new-object Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPool

$BackEndAddressPool.ResourceId = "BE1"
$BackEndAddressPool.ResourceRef =
"/loadBalancers/$LBResourceId/backendAddressPools/$($BackEndAddressPool.ResourceId)"
$BackEndAddressPool.Properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPoolProperties

$LoadBalancerProperties.backendAddressPools += $BackEndAddressPool

2. Defina a regra NAT de saída.

$OutboundNAT = new-object Microsoft.Windows.NetworkController.LoadBalancerOutboundNatRule

$OutboundNAT.ResourceId = "onat1"

$OutboundNAT.properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerOutboundNatRuleProperties
$OutboundNAT.properties.frontendipconfigurations += $FrontEndIPConfig
$OutboundNAT.properties.backendaddresspool = $BackEndAddressPool
$OutboundNAT.properties.protocol = "ALL"

$LoadBalancerProperties.OutboundNatRules += $OutboundNAT

3. Adicione o objeto de balanceador de carga no controlador de rede.

$LoadBalancerResource = New-NetworkControllerLoadBalancer -ConnectionUri $URI -ResourceId

$LBResourceId -Properties $LoadBalancerProperties -Force -PassInnerException

4. Siga o exemplo a seguir para adicionar as interfaces de rede às quais você deseja fornecer acesso à
Internet.

Exemplo: adicionar interfaces de rede ao pool de back-ends

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 uma única interface 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 de 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-ends para adicionar uma interface
de rede.

$lbresourceid = "LB2"
$lb = get-networkcontrollerloadbalancer -connectionuri $uri -resourceID $LBResourceId -
PassInnerException

2. Obtenha a interface de rede e adicione o pool backendaddress à matriz

loadbalancerbackendaddresspools.

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -resourceid 6daca142-7d94-0000-

1111-c38c0141be06 -PassInnerException
$nic.properties.IpConfigurations[0].properties.LoadBalancerBackendAddressPools +=
$lb.properties.backendaddresspools[0]

3. Coloque a interface de rede para aplicar a alteração.

new-networkcontrollernetworkinterface -connectionuri $uri -resourceid 6daca142-7d94-0000-1111-

c38c0141be06 -properties $nic.properties -force -PassInnerException

Exemplo: usar o Load Balancer de software para o tráfego de

encaminhamento
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ê tiver definido o VIP e o DIP como a mesma sub-rede, isso será equivalente a executar o
encaminhamento L3 sem NAT.

NOTE
Esse processo não exige que você crie um objeto de balanceador de carga. A atribuição do PublicIPAddress à interface de
rede é suficiente para que o software Load Balancer execute sua configuração.

1. Crie um objeto IP público para conter o VIP.

$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 uma interface de rede.

 $nic = get-networkcontrollernetworkinterface -connectionuri $uri -resourceid 6daca142-7d94-0000-
1111-c38c0141be06
$nic.properties.IpConfigurations[0].Properties.PublicIPAddress = $publicIP
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId $nic.ResourceId -Properties
$nic.properties -PassInnerException

Exemplo: usar o Load Balancer de software para encaminhar o tráfego

com um VIP alocado dinamicamente
Este exemplo repete a mesma ação do exemplo anterior, mas aloca automaticamente o VIP do pool de VIPs
disponível 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.

$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.

(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 : {}
ConfigurationState :
IpAddress : 10.127.134.2
PublicIPAddressVersion : IPv4
PublicIPAllocationMethod : Dynamic
IdleTimeoutInMinutes : 4
DnsSettings :
ProvisioningState : Succeeded
IpConfiguration :
PreviousIpConfiguration :

3. Atribua o PublicIPAddress a uma interface de rede.

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -resourceid 6daca142-7d94-0000-

1111-c38c0141be06
$nic.properties.IpConfigurations[0].Properties.PublicIPAddress = $publicIP
New-NetworkControllerNetworkInterface -ConnectionUri $uri -ResourceId $nic.ResourceId -Properties
$nic.properties -PassInnerException

Exemplo: remover um endereço PublicIP que está sendo usado

para encaminhar o tráfego e retorná-lo para o pool VIP
Este exemplo remove o recurso PublicIPAddress que foi criado pelos exemplos anteriores. Depois que o
PublicIPAddress for removido, a referência ao PublicIPAddress será automaticamente removida do
adaptador de rede, o tráfego deixará de ser encaminhado e o endereço IP será retornado para o pool de
VIP público para reutilização.
4. Remover o PublicIP
Remove-NetworkControllerPublicIPAddress -ConnectionURI $uri -ResourceId "MyPIP"
 Usar dispositivos virtuais de rede em uma rede
virtual
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, você aprenderá a implantar dispositivos de rede virtual em redes virtuais de locatário. Você pode
adicionar soluções de virtualização de rede a redes que executam funções de espelhamento de porta e
roteamento definidas pelo usuário.

Tipos de dispositivos de rede virtual

Você pode usar um dos dois tipos de dispositivos virtuais:
1. Roteamento definido pelo usuário – substitui os roteadores distribuídos na rede virtual pelos
recursos de roteamento do dispositivo virtual. 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.
2. Espelhamento de por ta – todo o tráfego de rede que está entrando ou saindo da porta monitorada é
duplicado e enviado a um dispositivo virtual para análise.

Implantando uma solução de virtualização de rede

Para implantar uma solução de virtualização de rede, você deve primeiro 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 uma rede Virtual de locatário ou VLAN.
Alguns dispositivos exigem vários adaptadores de rede virtual. Normalmente, um adaptador de rede dedicado
ao gerenciamento de dispositivo, enquanto adaptadores adicionais processam o tráfego. Se seu 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 a solução de virtualização de rede, você pode usar o dispositivo para roteamento definido,
portamento de espelhamento 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 maior correspondência de prefixo (LPM) entre
as rotas definidas pelo usuário e as rotas do sistema. Se houver mais de uma rota com a mesma
correspondência de LPM, a rota definida pelo usuário será selecionada primeiro-antes da rota do sistema.
Procedure
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.

$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 a solução de virtualização em 192.168.1.10.
O dispositivo deve ter um adaptador de rede virtual conectado à rede virtual com esse IP atribuído a uma
interface de rede.

$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

TIP
Se você quiser adicionar mais rotas, repita essa etapa para cada rota que você deseja definir.

3. Adicione a tabela de roteamento ao controlador de rede.

$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 Tenant1_Vnet1
rede usa a tabela de rotas. Você pode atribuir a tabela de rotas para o máximo de sub-redes na rede
virtual que desejar.

$vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -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 uma
maneira apropriada para o 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 a outra como a VM a ser monitorada com o
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 recebe mais o tráfego destinado à interface IP configurada
lá.
Procedure
1. Obtenha a rede virtual na qual suas VMs estão localizadas.

$vnet = Get-NetworkControllerVirtualNetwork -ConnectionUri $uri -ResourceId "Tenant1_VNet1"

2. Obtenha as interfaces de rede do controlador de rede para a origem e o destino do espelhamento.

$dstNic = get-networkcontrollernetworkinterface -ConnectionUri $uri -ResourceId "Appliance_Ethernet1"

$srcNic = get-networkcontrollernetworkinterface -ConnectionUri $uri -ResourceId "MyVM_Ethernet1"

3. Crie um objeto iminsertproperties para conter as regras de espelhamento de porta e o elemento que
representa a interface de destino.

$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 origem/destinos específicos.

$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]::new()

$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.DestinationPortRangeStart = "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.

 $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 a interface de rede do dispositivo especificado na
etapa anterior é interrompido.

$portMirror = New-NetworkControllerServiceInsertion -ConnectionUri $uri -Properties $portmirror -

ResourceId "MirrorAll"

7. Atualize a interface de rede da origem a ser espelhada.

$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 de Appliance_Ethernet1 espelha o tráfego da interface

MyVM_Ethernet1.
 Clustering convidado em uma rede virtual
13/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

As máquinas virtuais conectadas a uma rede virtual só têm permissão para usar os endereços IP que o
Controlador de Rede atribuiu para se comunicar na rede. As tecnologias de clustering que exigem um endereço
IP flutuante, como o Clustering de Failover da Microsoft, exigem algumas etapas adicionais para funcionar
corretamente.
O método para tornar o IP flutuante acessível é usar um VIP de IP virtual Load Balancer ( ) ( ) SLB. O balanceador
de carga de software deve ser configurado com uma investigação de saúde em uma porta nesse IP para que o
SLB direciona o tráfego para o computador que atualmente tem esse IP.

Exemplo: configuração do balanceador de carga

Este exemplo presume que você já criou as VMs que se tornarão nós de cluster e as anexou a uma Rede Virtual.
Para obter diretrizes, consulte Criar uma VMe Conexão uma Rede Virtual de Locatário 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 saúde 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 usada ou reservado na
mesma sub-rede que os nós de cluster. O VIP deve corresponder ao endereço flutuante do cluster.

$VIP = "192.168.2.100"
$subnet = "Subnet2"
$VirtualNetwork = "MyNetwork"
$ResourceId = "MyNetwork_InternalVIP"

2. Crie o objeto de propriedades do balanceador de carga.

$LoadBalancerProperties = new-object Microsoft.Windows.NetworkController.LoadBalancerProperties

3. Crie um endereço - IP de front-end.

$LoadBalancerProperties.frontendipconfigurations += $FrontEnd = new-object

Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfiguration
$FrontEnd.properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerFrontendIpConfigurationProperties
$FrontEnd.resourceId = "Frontend1"
$FrontEnd.resourceRef = "/loadBalancers/$ResourceId/frontendIPConfigurations/$($FrontEnd.resourceId)"
$FrontEnd.properties.subnet = new-object Microsoft.Windows.NetworkController.Subnet
$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.

 $BackEnd = new-object Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPool
$BackEnd.properties = new-object
Microsoft.Windows.NetworkController.LoadBalancerBackendAddressPoolProperties
$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.

NOTE
A consulta de investigação no endereço permanente da VM na porta definida abaixo. A porta só deve responder
no nó ativo.

$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 seja definido
como $true porque isso informa ao balanceador de carga para enviar o pacote para o nó com o VIP
original em uso.

$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.

$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 quantos nós ao pool for necessário para o cluster.
 # Cluster Node 1

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -resourceid "ClusterNode1_Network-

Adapter"
$nic.properties.IpConfigurations[0].properties.LoadBalancerBackendAddressPools +=
$lb.properties.backendaddresspools[0]
$nic = new-networkcontrollernetworkinterface -connectionuri $uri -resourceid $nic.resourceid -
properties $nic.properties -force

# Cluster Node 2

$nic = get-networkcontrollernetworkinterface -connectionuri $uri -resourceid "ClusterNode2_Network-

Adapter"
$nic.properties.IpConfigurations[0].properties.LoadBalancerBackendAddressPools +=
$lb.properties.backendaddresspools[0]
$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. Instalar e configurar propriedades para um cluster de failover.

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ó.

New-Cluster -Name $ClusterName -NoStorage -Node $nodes[0]

3. Pare o recurso de cluster.

Stop-ClusterResource "Cluster Name"

4. Definir 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.

Get-ClusterResource "Cluster IP Address" | Set-ClusterParameter -Multiple

@{"Address"="$ILBIP";"ProbePort"="59999";"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkNam
e";"EnableDhcp"=0}
5. Inicie os recursos do cluster.

Start-ClusterResource "Cluster IP Address" -Wait 60

Start-ClusterResource "Cluster Name" -Wait 60

6. Adicione os nós restantes.

Add-ClusterNode $nodes[1]

O 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
SDN
11/08/2021 • 8 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Neste tópico, você aprenderá a atualizar, fazer backup e restaurar uma infraestrutura de SDN.

Atualizar a infraestrutura de SDN

a infraestrutura de 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, conforme mencionado na seção "atualizar a
infraestrutura de SDN". Antes da atualização, é recomendável fazer um backup do banco de dados do
controlador de rede.
Para computadores do controlador 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ó retorna ao status "para cima" antes de atualizar os outros
nós. Depois de atualizar todos os nós do controlador de rede, o controlador de rede atualiza os microserviços
em execução no cluster do controlador de rede dentro de uma hora. Você pode disparar uma atualização
imediata usando o cmdlet Update-networkcontroller.
instale as mesmas Windows atualizações em todos os componentes do sistema operacional do sistema de rede
definida pelo Software (SDN), que inclui:
Hosts Hyper-V habilitados para SDN
VMs do controlador de rede
VMs do software Load Balancer MUX
VMs de gateway de RAS

IMPORTANT
se você usar System Center gerenciador Virtual, deverá atualizá-lo com os pacotes cumulativos de atualizações 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 do PowerShell do
controlador de rede. Incluindo em qualquer lugar que você tenha a função RSAT-NetworkController
instalada por si só. Excluindo as VMs do controlador de rede propriamente ditas; Você os atualiza na
próxima etapa.
2. Na primeira VM do controlador de rede, instale todas as atualizações e reinicie o.
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ó do controlador de rede fique inativo e volte
novamente.
Após a reinicialização da VM, pode levar vários minutos antes de retornar ao status de backup . Para
obter um exemplo da saída, consulte
5. Instale atualizações em cada VM MUX do SLB, uma de cada vez, para garantir a disponibilidade contínua
da infraestrutura do balanceador de carga.
6. Atualize os hosts e gateways RAS do Hyper-V, começando com os hosts que contêm os gateways RAS
que estão no modo de espera .
As VMs de gateway de RAS não podem ser migradas ao vivo sem perder as conexões de locatário.
Durante o ciclo de atualização, você deve ter cuidado para minimizar o número de vezes que o failover de
conexões de locatário para um novo gateway de RAS. Ao coordenar a atualização de hosts e gateways de
RAS, cada locatário falha ao longo de uma vez, no máximo.
a. Evacuar o host de VMs que são capazes de migração dinâmica.
As VMs de gateway de RAS devem permanecer no host.
b. Instale atualizações em cada VM de gateway neste host.
c. Se a atualização exigir que a VM de gateway seja reinicializada, reinicialize a VM.
d. Instale atualizações no host que contém a VM de gateway que acabou de ser atualizada.
e. Reinicialize o host se exigido pelas atualizações.
f. Repita para cada host adicional que contém um gateway em espera.
Se nenhum gateway em espera permanecer, siga estas mesmas etapas para todos os hosts restantes.
Exemplo: Use o cmdlet Get-networkcontrollernode
Neste exemplo, você vê a saída para a get-networkcontrollernode execução do cmdlet 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 = down
NCNode2.contoso.com = up
NCNode3.contoso.com = up

IMPORTANT
Você deve aguardar vários minutos até que o status do nó seja alterado para ativo antes de atualizar qualquer nó
adicional, um de cada vez.

Depois de atualizar todos os nós do controlador de rede, o controlador de rede atualiza os microserviços em
execução no cluster do controlador de rede dentro de uma hora.

TIP
Você pode disparar uma atualização imediata usando o update-networkcontroller cmdlet.
 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
RestInterface : Ethernet
NodeCertificate :
Status : Up

Name : NCNode3.Contoso.com
Server : NCNode3.Contoso.com
FaultDomain : fd:/ NCNode3.Contoso.com
RestInterface : Ethernet
NodeCertificate :
Status : Up

Exemplo: Use o cmdlet Update -networkcontroller

Neste exemplo, você vê a saída do update-networkcontroller cmdlet para forçar a atualização do controlador de
rede.

IMPORTANT
Execute este cmdlet quando não houver mais atualizações a serem instaladas.

PS C:\> update-networkcontroller
NetworkControllerClusterVersion NetworkControllerVersion
------------------------------- ------------------------
10.1.1 10.1.15

Fazer backup da infraestrutura de SDN

Os backups regulares do banco de dados do 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 nos 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 arquivos e
compartilhamento.
Opcionalmente, você pode usar uma conta de serviço gerenciado de grupo (GMSA) se o controlador de rede
tiver sido instalado usando um GMSA também.
Procedure
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.
Fazer 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 o System Center Virtual Machine Manager (scvmm), interrompa o serviço do SCVMM
 e faça o backup por meio de SQL Server.
A meta aqui é garantir que nenhuma atualização seja feita no SCVMM durante esse tempo, o que poderia
criar uma inconsistência entre o backup do controlador de rede e o SCVMM.

IMPORTANT
Não reinicie o serviço do 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 êxito do backup com o get-networkcontrollerbackup cmdlet.
5. Se estiver usando o SCVMM, inicie o serviço do SCVMM.
Exemplo: fazendo backup do banco de dados do controlador de rede

$URI = "https://NC.contoso.com"
$Credential = Get-Credential

# 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 Microsoft.Windows.NetworkController.CredentialProperties
$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

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\"",
"ResourceMetadata": null,
"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/servers/4c4c4544-0058-5810-8057-
b4c04f395931",
"/networking/v1/servers/4c4c4544-0058-5910-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",
 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",
"/networking/v1/loadBalancers/24fa1af9-88d6-4cdc-aba0-
66e38c1a7bb8_10.127.132.3",
"/networking/v1/loadBalancers/24fa1af9-88d6-4cdc-aba0-
66e38c1a7bb8_10.127.132.4"
],
"InProgressResourcesList": [

],
"ProvisioningState": "Succeeded",
"Credential": {
"Tags": null,
"ResourceRef": "/credentials/BackupUser",
"InstanceId": "00000000-0000-0000-0000-000000000000",
"Etag": null,
"ResourceMetadata": null,
"ResourceId": null,
"Properties": null
}
}
}

Restaurar a infraestrutura de SDN de um backup

Quando você restaura todos os componentes necessários do backup, o ambiente de SDN retorna para um
estado operacional.

IMPORTANT
As etapas variam dependendo do número de componentes restaurados.

1. Se necessário, reimplante os hosts Hyper-V e o armazenamento necessário.

2. Se necessário, restaure as VMs do controlador de rede, as VMs do gateway de RAS e as VMs do MUX do
backup.
3. Interrompa o agente de host NC e o agente de host SLB em todos os hosts Hyper-V:

stop-service slbhostagent

stop-service nchostagent
 4. Interrompa as VMs do gateway de RAS.
5. Interrompa as VMs MUX SLB.
6. Restaure o controlador de rede com o new-networkcontrollerrestore cmdlet.
7. Verifique o ProvisioningState de restauração para saber quando a restauração foi concluída com êxito.
8. Se estiver usando o SCVMM, restaure o banco de dados do 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 Debug-networkcontrollerconfigurationstate.

$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

$URI = "https://NC.contoso.com"
$Credential = Get-Credential

$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

 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\"",
"ResourceMetadata": null,
"ResourceId": "2017-04-26T15_04_44",
"Properties": {
"RestorePath": "\\\\sa18fs\\sa18n22\\NetworkController\\2017-04-25T16_53_13",
"ErrorMessage": null,
"FailedResourcesList": null,
"SuccessfulResourcesList": null,
"ProvisioningState": "Succeeded",
"Credential": null
}
}

para obter informações sobre as mensagens de estado de configuração que podem aparecer, consulte
solucionar problemas da pilha de rede definida pelo Software Windows Server 2016.
 Segurança para SDN
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar os tópicos nesta seção para saber mais sobre segurança no SDN de Rede Definida pelo Software
().

NOTE
Para obter documentação adicional de Rede Definida pelo Software, você pode usar as seguintes seções de biblioteca:
Tecnologias SDN
Planejar SDN
Implantar SDN
Gerenciar SDN
Solucionar problemas de SDN

Esta seção contém os seguintes tópicos:

Segurança do controlador de rede
Gerenciar certificados para rede definida pelo software
 Proteger o controlador de rede
12/08/2021 • 10 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

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 a comunicação Northbound no plano de
gerenciamento, a comunicação de cluster entre ( VMs ) de máquinas virtuais de controlador de rede em um
cluster e a comunicação Southbound no plano de dados.
1. Comunicação Nor thbound . 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
diretiva de rede e criar um estado de meta para a rede, no qual você pode comparar a configuração de
rede real para colocar a configuração real em paridade com o estado da 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 Southbound . 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
máquinas de host. Você pode usar o controlador de rede para configurar e gerenciar esses dispositivos
Southbound para que eles mantenham o estado da meta que você configurou para a rede.

Comunicação Northbound
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 nós de
cluster do controlador de rede e clientes de gerenciamento verifiquem a identidade do dispositivo com o qual
estão se comunicando.
O controlador de rede dá suporte aos três modos de autenticação a seguir entre os clientes de gerenciamento e
os nós do controlador de rede.

NOTE
se você estiver implantando o controlador de rede com o 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 Active Directory. O domínio de Active Directory deve ter contas de
domínio usadas para autenticação.
2. X509 . Use o X509 para - autenticação baseada em certificado para clientes de gerenciamento que não
ingressaram em um domínio Active Directory. Você deve registrar certificados para 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 dos outros.
3. None . Use nenhum 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á nenhuma 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 válido .
Autorização
Ao configurar a autorização para a comunicação Northbound do controlador de rede, você permite que nós de
cluster do controlador de rede e clientes de gerenciamento verifiquem se o dispositivo com o qual estão se
comunicando é confiável e tem permissão para participar da comunicação.
Use os métodos de autorização a seguir para cada um dos modos de autenticação com suporte do 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ê estiver usando o método de autenticação X509, o controlador de rede só aceita
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á nenhuma autenticação executada entre nós e clientes de
gerenciamento. Use nenhum 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 Northbound usa protocolo SSL ( SSL ) para criar um canal criptografado entre os clientes de
gerenciamento e os 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 a autenticação do
servidor e as finalidades de autenticação do cliente nas extensões EKU do 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 nome de domínio
totalmente qualificado (FQDN) 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 rest 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 -Ser verCer tificate do comando Install-NetworkController Windows PowerShell. Se você
já tiver instalado o controlador de rede, poderá atualizar a configuração a qualquer momento usando o
comando set-NetworkController .

NOTE
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 é sobre Windows Communication Foundation ( WCF ) e 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 comunicação de cluster do controlador de rede, você permite que nós de
cluster do controlador de rede verifiquem a identidade dos outros nós com os quais estão se comunicando.
O controlador de rede dá suporte aos três modos de autenticação a seguir entre os nós do controlador de rede.

NOTE
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 são ingressados em um domínio Active Directory, com contas de domínio usadas para autenticação.
2. X509 . O X509 é uma - autenticação baseada em certificado. Você pode usar a autenticação X509 quando
os nós de cluster do controlador de rede não tiverem ingressado em um domínio Active Directory. Para
usar o 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 comunicação de 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 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 com suporte do controlador de rede, os métodos de autorização a
seguir 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á nenhuma 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 do 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 estes tópicos.
Como: proteger um serviço com credenciais do Windows
Como: proteger um serviço com certificados X. 509.

Comunicação Southbound
O Controlador de Rede interage com diferentes tipos de dispositivos para comunicação de 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
southbound.

DISP O SIT IVO / SERVIÇ O DE

SO UT H B O UN D P ROTO C O LO A UT EN T IC A Ç Ã O USA DA

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 de southbound, os seguintes protocolos e métodos de autenticação são usados.
1. WCF/TCP/OVSDB . Para esses protocolos, a autenticação é executada usando certificados X509. Tanto o
Controlador de Rede quanto os pares MUX /host do multiplexador de balanceamento de carga de
software apresentam seus certificados uns aos outros para ( ) ( ) autenticação mútua. Cada certificado
deve ser confiável para o par remoto.
Para autenticação de southbound, você pode usar o mesmo certificado SSL configurado para criptografar
a comunicação com os clientes de Northbound. Você também deve configurar um certificado nos
dispositivos SLB MUX e host. O nome da assunto do certificado deve ser o mesmo que o nome DNS do
dispositivo.
2. WinRM . Para esse protocolo, a autenticação é executada usando Kerberos para máquinas ingressadas no
domínio e usando certificados para máquinas ( ) não ( ingressadas no domínio ) .
Autorização
Para comunicação de southbound, os seguintes protocolos e métodos de autorização são usados.
1. WCF/TCP. Para esses protocolos, a autorização é baseada no nome da entidade do 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 assunto 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 Kerberos estiver sendo usado, a conta de cliente WinRM deverá estar presente em um grupo
predefinido no Active Directory ou no grupo Administradores Locais no servidor. Se os certificados estão
sendo usados, o cliente apresenta um certificado para o servidor que o servidor autoriza usando o
nome/emissor da assunto e o servidor usa uma conta de usuário mapeada para executar a autenticação.
3. OVSDB . Não há autorização fornecida para esse protocolo.
Criptografia
Para comunicação de 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 que está
inscrito no cliente ou servidor.
2. WinRM . O tráfego winRM é criptografado por padrão usando o provedor de suporte de segurança
Kerberos ( SSP ) . Você pode configurar criptografia adicional, na forma de SSL, no servidor WinRM.
 Gerenciar certificados para rede definida pelo
software
13/08/2021 • 11 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Você pode usar este tópico para aprender a gerenciar certificados para comunicações de Northbound e
Southbound do Controlador de Rede ao implantar o SDN de Rede Definida pelo Software no datacenter do (
Windows Server 2019 ou 2016 e estiver usando o SCVMM do System Center Virtual Machine Manager como
seu ) cliente de gerenciamento do ( ) SDN.

NOTE
Para obter informações de visão geral sobre o Controlador de Rede, consulte Controlador de rede.

Se você não estiver usando o 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 autoatendados e
assinados pela AC da Autoridade de ) Certificação. Este tópico fornece instruções passo a passo para criar esses
certificados e aplicação deles para proteger os canais de comunicação de Northbound do Controlador de Rede
com clientes de gerenciamento e comunicações de southbound 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 que - é usado das seguintes maneiras.
1. Criptografando a comunicação de northbound com protocolo SSL SSL 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 southbound, como hosts Hyper-
V e SLBs de Balanceadores de Carga ( de Software ) .

Criando e registrando um certificado X.509

Você pode criar e registrar um certificado auto assinado ou um certificado - emitido por uma AC.

NOTE
Ao usar o SCVMM para implantar o Controlador de Rede, você deve especificar o certificado X.509 usado para
criptografar as comunicações de northbound 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 do Nome de Domínio Totalmente Qualificado do
Controlador de ( Rede ou o endereço ) IP.
O valor restEndPoint deve corresponder ao nome da assunto ( Nome Comum, CN do certificado ) X.509.
Criando um certificado - X.509 auto assinado
Você pode criar um certificado X.509 auto-assinado 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 autoatendados, 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 requer que os nós do Controlador de Rede fiquem todos
localizados em uma única sub-rede de gerenciamento, por exemplo, em um único ( rack)
Para várias implantações de NC de nó, o nome DNS especificado se tornará o FQDN dos registros A do Host
DNS do Cluster do Controlador de Rede criados ( automaticamente.)
Para implantações de Controlador de Rede de nó único, o nome DNS pode ser o nome do 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 criar um certificado - autoatendido.
Sintaxe

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -

FriendlyName "<YourNCComputerName>" -DnsName @("<NCRESTName>")

Exemplo de uso

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -

FriendlyName "MultiNodeNC" -DnsName @("NCCluster.Contoso.com")

Nó único
Você pode usar o comando New-SelfSignedCertificate Windows PowerShell criar um certificado - autoatendido.
Sintaxe

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -

FriendlyName "<YourNCComputerName>" -DnsName @("<NCFQDN>")

Exemplo de uso

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -

FriendlyName "SingleNodeNC" -DnsName @("SingleNodeNC.Contoso.com")

Criando um certificado - X.509 assinado pela AC

Para criar um certificado usando uma AC, você já deve ter implantado uma PKI de infraestrutura de chave
pública com Serviços de Certificados do Active Directory ( ) AD CS ( ) .

NOTE
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 AD CS. Para saber como usar uma AC ou ferramenta de
terceiros, confira 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 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 assunto do certificado deve ser o FQDN do host Hyper-V
2. O certificado deve ser colocado no armazenamento pessoal do computador local (Meu –
cert:\localmachine\my)
3. O certificado deve ter autenticação de servidor (EKU: 1.3.6.1.5.5.7.3.1) e EKU (Autenticação de Cliente:
1.3.6.1.5.5.7.3.2) Políticas de aplicativo.

NOTE
Se o personal My – cert:\localmachine\my certificate store no host Hyper V tiver mais de um certificado X.509 com CN
(Nome da Assunto) como o FQDN do nome de domínio totalmente qualificado do host, verifique se o certificado que será
usado pelo SDN tem uma propriedade adicional personalizada uso de chave aprimorada 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

NOTE
Antes de executar este procedimento, você deve revisar os requisitos de certificado e os modelos de certificado
disponíveis no console modelos de certificado. Você pode modificar um modelo existente ou criar uma duplicata de um
modelo existente e, em seguida, modificar sua cópia do modelo. É recomendável criar uma cópia de um modelo existente.

1. No servidor onde o AD CS está instalado, no Gerenciador do Servidor, clique em Ferramentas e, em seguida,

clique em Autoridade de Cer tificação . A Autoridade de Certificação Console de Gerenciamento Microsoft (
MMC ) é aberta.
2. No MMC, clique duas vezes no nome da AC, clique com o botão direito do mouse em Modelos de
Cer tificado 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 Assunto, 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 a opção
Permitir que a chave privada a ser expor tada 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 de 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 Autenticação de Cliente e Autenticação de Ser vidor estão
listados.
12. Salve a cópia do modelo de certificado com um nome exclusivo, como modelo do Controlador de Rede .
Para solicitar um certificado da AC
Você pode usar o snap-in Certificados para solicitar certificados. Você pode solicitar qualquer tipo de certificado
pré-configurado e disponibilizado por um administrador da AC que processa a solicitação de certificado.
 Usuários ou Administradores locais é a associação de grupo mínima necessária para concluir este
procedimento.
1. Abra o snap-in Certificados para um computador.
2. Na árvore de console, clique em Cer tificados ( Computador Local. ) Selecione o Armazenamento 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 Cer tificado configurada pelo administrador e clique em Próximo.
5. Selecione a Política de Registro do Active Director y com base no modelo de AC que você ( configurou
na seção ) anterior.
6. Expanda a seção Detalhes e configure os itens a seguir.
a. Cer tifique-se de que o uso da chave inclua a Assinatura Digital ** e a **Chave de
encipherment .
b. Verifique se as políticas de aplicativo incluem a Autenticação do 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 assunto, em Tipo , selecione Nome comum . Em Valor, especifique Ponto
de Extremidade REST do Controlador de Rede .
9. Clique em Aplicar e em OK .
10. Clique em Registrar .
No MMC de Certificados, clique no armazenamento Pessoal para exibir o certificado que você registrou da AC.

Exportando e copiando o certificado para a biblioteca SCVMM

Depois de criar um certificado auto assinado ou assinado pela AC, você deve exportar o certificado com a chave
privada no formato .pfx e sem a chave privada no - - formato ( ) ( .cer base-64 do ) snap-in Certificados.
Em seguida, você deve copiar os dois arquivos exportados para as pastas Ser verCer tificate.cr e
NCCer tificate.cr que você especificou no momento em que importou o Modelo de Serviço NC.
1. Abra o snap-in Certificados (certlm.msc) e localize o certificado no armazenamento de certificados pessoal
do computador local.
2. Clique - com o botão direito do mouse no certificado, clique em Todas as Tarefas e, em seguida, clique em
Expor tar . 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 Próximo.
4. Escolha Informações Pessoais Exchange – PKCS #12 (. PFX) e aceite o padrão para Incluir todos os
cer tificados no caminho de cer tificaçã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ê copiou esses certificados.
Continue com a Configuração e a Implantação do Modelo de Serviço do Controlador de Rede.

Autenticando dispositivos e serviços de 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 é por meio do protocolo OVSDB enquanto a comunicação com os dispositivos SLB
MUX é por meio do protocolo WCF.
Comunicação do host Hyper-V com o controlador de rede
Para comunicação com os hosts Hyper-V por OVSDB, o Controlador de Rede precisa apresentar um certificado
para os máquinas host. Por padrão, o SCVMM escolhe o certificado SSL configurado no Controlador de Rede e o
usa para comunicação de southbound com os hosts.
Esse é o motivo pelo qual o certificado SSL deve ter a EKU de Autenticação de Cliente configurada. Esse
certificado é configurado no recurso REST "Servidores" (hosts Hyper-V são representados no Controlador de
Rede como um recurso de servidor) e pode ser exibido executando o comando Windows PowerShell Get-
NetworkControllerSer ver .
A seguir está um exemplo parcial do recurso REST do servidor.

"resourceId": "host31.fabrikam.com",
"properties": {
"connections": [
{
"managementAddresses": [
"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 de Autoridade de ( Certificação ) . Se um certificado baseado em
AC não for encontrado no computador host, o SCVMM criará um certificado auto-assinado e o provisiona no
computador host.
O Controlador de Rede e os certificados de host hyper-V devem ser confiáveis entre si. O certificado raiz do
certificado do host Hyper-V deve estar presente no armazenamento autoridades de certificação raiz confiáveis
do controlador de rede para o computador local e vice-versa.
Quando você está usando certificados auto assinados, o SCVMM garante que os certificados necessários estão
presentes no armazenamento 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 está presente no armazenamento autoridades de certificação raiz confiáveis do controlador de rede
para o computador local.
Comunicação de Load Balancer MUX com o controlador de rede
O software Load Balancer Multiplexor MUX e o Controlador de Rede se comunicam por meio do ( ) protocolo
WCF, usando certificados para autenticação.
Por padrão, o SCVMM escolhe o certificado SSL configurado no Controlador de Rede e o usa para comunicação
de southbound com os dispositivos Mux. Esse certificado é configurado no recurso REST
"NetworkControllerLoadBalancerMux" e pode ser exibido executando o cmdlet do PowerShell Get-
NetworkControllerLoadBalancerMux.
Exemplo de recurso REST de MUX ( ) parcial:
 "resourceId": "slbmux1.fabrikam.com",
"properties": {
"connections": [
{
"managementAddresses": [
"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 SLB MUX. Esse certificado é
configurado automaticamente pelo SCVMM quando você implanta o balanceador de carga de software usando
o SCVMM.

IMPORTANT
Nos nós de host e SLB, é essencial que o armazenamento de certificados autoridades de certificação confiáveis não inclua
nenhum certificado em que "Emitido para" não seja o mesmo que "Emitido por". Se isso ocorrer, a comunicação entre o
Controlador de Rede e o dispositivo de southbound falhará.

O Controlador de Rede e os certificados SLB MUX devem ser confiáveis entre si. O certificado raiz do certificado
SLB MUX deve estar presente no armazenamento de Autoridades de Certificação Raiz Confiáveis do
computador controlador de rede e ( vice-versa. ) Quando você está usando certificados auto assinados, o
SCVMM garante que os certificados necessários estão presentes no no armazenamento autoridades de
certificação raiz confiáveis para o - computador local.
 Kerberos com o nome da entidade de serviço (SPN)
13/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 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 é usado 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 de entidade de serviço.

Configurar SPN (Nomes de Entidade de Serviço)

O Controlador de Rede configura automaticamente o SPN. Tudo o que você precisa fazer é fornecer permissões
para que os máquinas do Controlador de Rede registrem e modifiquem o SPN.
1. No computador do Controlador de Domínio, inicie Usuários e Computadores do Active Director y .
2. Selecione 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 estão 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 grupo e clique em Editar .
b. Em Permissões, selecione Validar Ser viço de GravaçãoPrincipalName .
d. Scroll down e, em Propriedades, selecione:
Ler ser vicePrincipalName
Gravar ser vicePrincipalName
e. Clique em OK duas vezes.
7. Repita a etapa 3 a 6 para cada máquina do Controlador de Rede.
8. Feche Usuários e Computadores do Active Director y .

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 que os nós do Controlador de Rede registrem ou modifiquem o SPN, as
operações REST no Controlador de Rede falharão, impedindo que você gere 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 a transparência para
implantações de produção existentes.
Se o SPN não estiver registrado, a autenticação do cliente REST usará NTLM, que é menos seguro. Você também
recebe um evento crítico no canal administrador 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 registra o SPN automaticamente e todas as operações de cliente
usam Kerberos.

TIP
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 de Entidade de Serviço não poderão funcionar se os endereços IP são usados.
Se você estivesse usando o endereço IP para operações REST junto com a autenticação Kerberos no Windows Server
2016, a comunicação real teria sido por meio da 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 mover 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.
 Emparelhamento de rede virtual
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

O emparelhamento de rede virtual permite que você conecte duas redes virtuais diretamente. Uma vez
emparelhadas, 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 as máquinas virtuais nas redes virtuais emparelhadas é roteado por meio da
infraestrutura de backbone somente por meio de endereços IP privados . A comunicação entre as redes
virtuais não requer 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 rede virtual ao criar o emparelhamento.

Requisitos e restrições
O emparelhamento de rede virtual tem alguns requisitos e restrições:
As redes virtuais emparelhadas devem:
Ter espaços de endereço IP não sobrepostos
Ser gerenciado pelo mesmo controlador de rede
Depois de emparelhar uma rede virtual com outra rede virtual, você não poderá adicionar ou excluir
intervalos de endereços no espaço de endereço.

TIP
Se você precisar adicionar intervalos de endereços:
1. Remova o emparelhamento.
2. Adicione o espaço de endereço.
3. Adicione o emparelhamento novamente.

Como o emparelhamento de rede virtual está entre duas redes virtuais, não há nenhuma relação
transitiva derivada entre emparelhamentos. Por exemplo, se você emparelhar virtualNetworkA com
virtualNetworkB e virtualNetworkB com virtualNetworkC, o virtualNetworkA não será emparelhado com
virtualNetworkC.

Conectividade
Depois de emparelhar as redes virtuais, os recursos em qualquer rede virtual podem se conectar diretamente
com os recursos na rede virtual emparelhada.
 A latência de rede entre as máquinas virtuais nas redes virtuais emparelhadas é igual à latência em uma
única rede virtual.
A taxa de transferência de 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 emparelhadas é 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
emparelhada.
Você pode aplicar listas de controle de acesso (ACLs) 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
emparelhadas (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, confira 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 apontem para máquinas virtuais em redes virtuais
emparelhadas como o endereço IP do próximo salto, para habilitar o encadeamento de serviços. O
encadeamento de serviços permite direcionar o tráfego de uma rede virtual para uma solução de virtualização,
em uma rede virtual emparelhada, por meio de rotas definidas pelo usuário.
Você pode implantar redes Hub e spoke, em que a rede virtual do Hub pode hospedar componentes de
infraestrutura, como uma solução de virtualização de rede. Todas as redes virtuais spoke emparelhadas com a
rede virtual do Hub. O tráfego pode fluir por meio de dispositivos de rede virtual na rede virtual do Hub.
O emparelhamento 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 emparelhada. Para saber mais sobre as rotas definidas pelo
usuário, confira usar dispositivos de rede virtual em uma rede virtual.

Gateways e conectividade local

Cada rede virtual, independentemente de estar emparelhada com outra rede virtual, ainda pode ter seu próprio
gateway para se conectar a uma rede local. Ao emparelhar redes virtuais, você também pode configurar o
gateway na rede virtual emparelhada 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 emparelhada).

Monitoramento
Ao emparelhar duas redes virtuais, você deve configurar um emparelhamento para cada rede virtual no
emparelhamento.
Você pode monitorar o status da conexão de emparelhamento, que pode estar em um dos seguintes Estados:
Iniciado em: Mostrado quando você cria o emparelhamento da primeira rede virtual para a segunda
rede virtual.
Conectado: Mostrado depois de criar o emparelhamento 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 emparelhamento de rede
virtual com êxito.
Desconectado: Mostrado se uma rede virtual se desconectar de outra rede virtual.
[infográfico dos Estados]

Próximas etapas
configurar o emparelhamento de rede virtual: neste procedimento, você usa Windows PowerShell para localizar
a rede lógica do provedor HNV para criar duas redes virtuais, cada uma com uma sub-rede. Você também
configura o emparelhamento entre as duas redes virtuais.
 Configure emparelhamento de rede virtual
12/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

neste procedimento, você usa Windows PowerShell para criar duas redes virtuais, cada uma com uma sub-rede.
Em seguida, você configura o emparelhamento entre as duas redes virtuais para habilitar a conectividade entre
elas.
Etapa 1. Criar a primeira rede virtual
Etapa 2. Criar a segunda rede virtual
Etapa 3. Configurar o emparelhamento da primeira rede virtual para a segunda rede virtual
Etapa 4. Configurar o emparelhamento da segunda rede virtual para a primeira rede virtual

IMPORTANT
Lembre-se de atualizar as propriedades do seu ambiente.

Etapa 1. Criar sua primeira rede virtual

nesta etapa, você usa Windows PowerShell localizar a rede lógica do provedor 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.

#Find the HNV Provider Logical Network

$logicalnetworks = Get-NetworkControllerLogicalNetwork -ConnectionUri $uri

foreach ($ln in $logicalnetworks) {
if ($ln.Properties.NetworkVirtualizationEnabled -eq "True") {
$HNVProviderLogicalNetwork = $ln
}
}

#Create the Virtual Subnet

$vsubnet = new-object Microsoft.Windows.NetworkController.VirtualSubnet

$vsubnet.ResourceId = "Contoso"
$vsubnet.Properties = new-object Microsoft.Windows.NetworkController.VirtualSubnetProperties
$vsubnet.Properties.AddressPrefix = "24.30.1.0/24"
$uri=”https://restserver”

#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
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.

#Create the Virtual Subnet

$vsubnet = new-object Microsoft.Windows.NetworkController.VirtualSubnet

$vsubnet.ResourceId = "Woodgrove"
$vsubnet.Properties = new-object Microsoft.Windows.NetworkController.VirtualSubnetProperties
$vsubnet.Properties.AddressPrefix = "24.30.2.0/24"
$uri=”https://restserver”

#Create the Virtual Network

$vnetproperties = new-object Microsoft.Windows.NetworkController.VirtualNetworkProperties

$vnetproperties.AddressSpace = new-object Microsoft.Windows.NetworkController.AddressSpace
$vnetproperties.AddressSpace.AddressPrefixes = @("24.30.2.0/24")
$vnetproperties.LogicalNetwork = $HNVProviderLogicalNetwork
$vnetproperties.Subnets = @($vsubnet)
New-NetworkControllerVirtualNetwork -ResourceId "Woodgrove_VNet1" -ConnectionUri $uri -Properties
$vnetproperties

Etapa 3. Configurar o emparelhamento da primeira rede virtual para a

segunda rede virtual
Nesta etapa, você configura o emparelhamento entre a primeira rede virtual e a segunda rede virtual criada nas
duas etapas anteriores. O script de exemplo a seguir estabelece o emparelhamento de rede virtual de
Contoso_vnet1 para Woodgrove_vnet1 .

$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

IMPORTANT
Depois de criar esse emparelhamento, o status da vnet mostrará iniciado .

Etapa 4. Configurar o emparelhamento da segunda rede virtual para a

primeira rede virtual
Nesta etapa, você configura o emparelhamento 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 emparelhamento de rede virtual de
Woodgrove_vnet1 para Contoso_vnet1 .

$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 emparelhamento, o status de emparelhamento 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 emparelhada.
 Windows Desempenho do gateway do servidor
2019
13/08/2021 • 3 minutes to read

aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

em Windows Server 2016, uma das preocupações dos clientes foi 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 teve limitações com a taxa de transferência de conexão única para a conectividade IPsec de cerca de
300 Mbps e para a conectividade do GRE sendo cerca de 2,5 Gbps.
melhoramos significativamente no Windows Server 2019, com os números de soaring a 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 alto desempenho com muito menos utilização da CPU.

habilitar alto desempenho com gateways no Windows Server 2019

para conexões de GRE , depois de implantar/atualizar para o Windows Server 2019 se baseia nas VMs de
gateway, você deve 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 de SDN, vá para console de Ser viços (Services. msc).
2. Localize o serviço chamado ser viç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 neste failover de gateway para uma VM de gateway
redundante.
4. Repita as etapas anteriores para o restante das VMs de gateway.

TIP
Para obter os melhores resultados de desempenho, verifique se cipherTransformationConstant e
authenticationTransformConstant nas configurações do modo rápido da conexão IPsec usam o GCMAES256 Cipher
Suite.
Para obter o máximo de desempenho, 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 Westmere (32nm) e na CPU da Intel posterior, exceto
nos 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.

Abaixo está um exemplo REST de conexão IPsec com algoritmos de segurança ideais:
 # 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 = New-Object Microsoft.Windows.NetworkController.NetworkConnectionProperties

# Update the common object properties

$nwConnectionProperties.ConnectionType = "IPSec"
$nwConnectionProperties.OutboundKiloBitsPerSecond = 2000000
$nwConnectionProperties.InboundKiloBitsPerSecond = 2000000

# Update specific properties depending on the Connection Type

$nwConnectionProperties.IpSecConfiguration = New-Object
Microsoft.Windows.NetworkController.IpSecConfiguration
$nwConnectionProperties.IpSecConfiguration.AuthenticationMethod = "PSK"
$nwConnectionProperties.IpSecConfiguration.SharedSecret = "111_aaa"

$nwConnectionProperties.IpSecConfiguration.QuickMode = New-Object
Microsoft.Windows.NetworkController.QuickMode
$nwConnectionProperties.IpSecConfiguration.QuickMode.PerfectForwardSecrecy = "PFS2048"
$nwConnectionProperties.IpSecConfiguration.QuickMode.AuthenticationTransformationConstant = "GCMAES256"
$nwConnectionProperties.IpSecConfiguration.QuickMode.CipherTransformationConstant = "GCMAES256"
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeSeconds = 3600
$nwConnectionProperties.IpSecConfiguration.QuickMode.IdleDisconnectSeconds = 500
$nwConnectionProperties.IpSecConfiguration.QuickMode.SALifeTimeKiloBytes = 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 = 28800
$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 = "<<On premise subnet that must be reachable over the VPN tunnel. Ex:
10.0.0.0/24>>"
$ipv4Route.metric = 10
$nwConnectionProperties.Routes += $ipv4Route

# Tunnel Destination (Remote Endpoint) Address

$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

Testando resultados
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 que não são SDN. Você pode encontrar os resultados e os detalhes de configuração de teste
capturados no artigo do blog aqui.
 Alocação de largura de banda de gateway
12/08/2021 • 4 minutes to read

aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2; Windows Servidor 2019

no Windows Server 2016, a largura de banda de túnel individual para IPsec, GRE e L3 era 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, esperando isso fora da VM do gateway.
Além disso, a largura de banda máxima do túnel IPsec no gateway era limitada à * capacidade do gateway
(3/20) fornecida pelo cliente. Portanto, por exemplo, se você definir a capacidade do gateway como 100 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 trabalhado 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 é limitada devido a fatores
internos.
no Windows Server 2019, para um tipo de túnel, a taxa de transferência máxima é fixa:
IPsec = 5 Gbps
GRE = 15 Gbps
L3 = 5 Gbps
Portanto, mesmo que o host/VM do gateway dê suporte a NICs com uma taxa de transferência muito maior, a
taxa de transferência máxima do túnel disponível será corrigida. Outro problema que isso cuida é que o excesso
de provisionamento de gateways é arbitrariamente, o que acontece ao fornecer um número muito alto para a
capacidade do gateway.

Cálculo da capacidade do gateway

O ideal é definir a capacidade de taxa de transferência do gateway para 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 de NIC
de 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 o máximo de 5 Gbps de
taxa de transferência IPsec ou um máximo de 15 Gbps de taxa de transferência de GRE. Portanto, por exemplo,
se você provisionar 2 Gbps de taxa de transferência IPsec, terá 3 Gbps de taxa de transferência IPsec restante
para provisionamento no gateway ou 9 Gbps de taxa de transferência do GRE restante.
Para colocar isso em termos mais matemáticos:
Capacidade total do gateway = 25 Gbps
Capacidade IPsec total disponível = 5 Gbps (fixo)
 Capacidade do GRE total disponível = 15 Gbps (fixo)
Taxa de produtividade IPsec para este gateway = 25/5 = 5 Gbps
Taxa de taxa de transferência de GRE para este gateway = 25/15 = 5/3 Gbps
Por exemplo, se você alocar 2 Gbps de taxa de transferência IPsec para um cliente:
Capacidade disponível restante no gateway = total de capacidade do gateway – taxa de 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 de GRE restante que você pode alocar no gateway = capacidade restante da taxa de taxa
de transferência de gateway/GRE
15 * 3/5 = 9 Gbps
A taxa de taxa de transferência varia dependendo da capacidade total do gateway. Uma coisa a ser observada é
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 disponível do túnel, a capacidade total
disponível do túnel será definida como a capacidade do gateway. Por exemplo, se você definir a capacidade do
gateway para 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 para 1 Gbps.

comportamento de Windows Server 2016

o algoritmo de cálculo da 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 à capacidade do gateway (3/20) *
em um gateway. As taxas equivalentes para túneis GRE e L3 eram 1/5 e 1/2, respectivamente.
se você estiver atualizando de Windows Server 2016 para Windows Server 2019:
1. Túneis GRE e L3: a lógica de alocação do Windows Server 2019 entra em vigor quando os nós do
controlador de rede são atualizados para Windows Server 2019
2. Túneis IPsec: a lógica de alocação de gateway Windows Server 2016 continuará funcionando até que
todos os gateways no pool de gateway sejam atualizados para Windows Server 2019. Para todos os
gateways no pool de gateway, você deve definir o serviço de gateway do Azure como automático .

NOTE
é possível que, após a atualização para o Windows Server 2019, um gateway se torne excessivamente provisionado (já
que a lógica de alocação muda de Windows Server 2016 para Windows Server 2019). Nesse caso, as conexões existentes
no gateway continuam a existir. O recurso REST para o gateway gera um aviso de que o gateway está excessivamente
provisionado. Nesse caso, você deve mover algumas conexões para outro gateway.
 Solucionar problemas de SDN
12/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Os tópicos nesta seção fornecem informações sobre como solucionar problemas das tecnologias de SDN (Rede
Definida pelo Software) incluídas no Azure Stack HCI, no Windows Server 2019 e no Windows Server 2016.

NOTE
Para obter documentação adicional de Rede Definida pelo Software, você pode usar as seções de biblioteca a seguir.
Tecnologias SDN
Planejar SDN
Implantar SDN
Gerenciar SDN
Segurança para SDN

Esta seção contém os seguintes tópicos.

Solucionar problemas de pilha de rede definida pelo software do Windows Server
Postagem no blog Solução de problemas do SDN: falhas de comunicação UDP e alteração do certificado do
controlador de rede
Postagem no blog Solucionando problemas de certificado na SDN (Rede Definida pelo Software)
Postagem no blog Como encontrar o endereço local do gateway SDN para o peering BGP Windows Server
2016
Postagem no blog Solucionar problemas ao configurar a largura de banda de VPN do Gateway de RAS do
SDN Configurações no Virtual Machine Manager
 Solucionar problemas de pilha de rede definida do
Windows Server Software
13/08/2021 • 32 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Este guia examina os cenários comuns de falha e erros de SDN (Rede Definida pelo Software) 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 vistos com a 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 no Windows Server 2016 HNVv2 com a nova pilha de
SDN (Rede Definida pelo Software).
A maioria dos erros pode ser classificada em um pequeno conjunto de classes:
Configuração inválida ou sem supor te 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 um Migração ao Vivo).
Desa drift de configuração ou bug de software Problemas de caminho de dados resultando em
pacotes descartados.
Erro externo relacionado ao hardware/drivers NIC ou à malha de rede de subposição
Descarregamento de tarefa de comportamento indefatório (como VMQ) ou malha de rede de subposição
configurada inde forma (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), você deve primeiro
instalar o recurso RSAT-NetworkController e importar o NetworkControllerDiagnostics módulo:

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:
 # Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Diagnóstico do controlador de rede

Esses cmdlets estão documentados no TechNet no Tópico do Cmdlet deDiagnóstico do Controlador de Rede .
Eles ajudam a identificar problemas com a consistência da política de rede no caminho de controle entre os nós
do Controlador de Rede e entre o Controlador de Rede e os Agentes de 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 de NC podem ser
executados em qualquer host, que tenha conectividade com o Controlador de Rede e que está no Kerberos
(grupo de segurança de Gerenciamento de Controlador de Rede) ou tenha acesso ao certificado X.509 para
gerenciar o Controlador de Rede.
Diagnóstico de host hyper-V
Esses cmdlets estão documentados no TechNet no Tópico do Cmdlet de Diagnóstico de HNV (Virtualizaçãode
Rede Hyper-V). 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 de 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 baseam nesses
cmdlets in-box. Em particular, os scripts de diagnóstico podem ser encontrados na pasta Diagnóstico. Ajude-nos
a contribuir com esses scripts enviando solicitações de pull.

Solução de problemas de fluxos de trabalho e guias

[Hoster] Validar a saúde do sistema
Há um recurso inserido chamado Estado de Configuração em vários dos recursos do Controlador de Rede. O
estado de configuração fornece informações sobre a saúde 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.

NOTE
O valor do parâmetro NetworkController deve ser o FQDN ou o endereço IP com base no nome da assunto do
certificado X.509 >criado para o Controlador de Rede.
O parâmetro Credential só precisará 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 está no Grupo de Segurança de
Gerenciamento do Controlador de Rede.
 Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported

$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType: accessControlLists

Fetching ResourceType: servers
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:

Fetching ResourceType: servers

---------------------------------------------------------------------------------------------------------
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.
----------------------------------------------------------------------------------------------------------

NOTE
Há um bug no sistema em que os recursos de Interface de Rede para a NIC de VM de Trânsito do SLB Mux estão em um
estado de falha com o erro "Comutdor 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 de Interface de Rede para as NICs de VM do
Provedor de HNV do Gateway estão em um estado de falha com o erro "Comu switch 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 tomar com base
no estado de configuração observado.

C Ó DIGO M ESSA GE AÇÃO

Unknown Erro desconhecido

HostUnreachable O computador host não está acessível Verifique a conectividade de rede de

gerenciamento entre o Controlador de
Rede e o Host

PAIpAddressExted Os endereços IP de PA esgotados Aumentar o tamanho do pool de IP da

sub-rede lógica do provedor de HNV

PAMacAddressExted Os endereços PA Mac esgotados Aumentar o intervalo de pools do Mac

PAAddressConfigurationFailure Falha ao fazer a rolagem de endereços Verifique a conectividade de rede de

PA para o host gerenciamento entre o Controlador de
Rede e o Host.
C Ó DIGO
CertificateNotTrusted
CertificateNotAuthorized
PolicyConfigurationFailureOnVfp
PolicyConfigurationFailure
HostNotConnectedToController
MultipleVfpEnabledSwitches
PolicyConfigurationFailure
PolicyConfigurationFailure
PolicyConfigurationFailure
DistributedRouterConfigurationFailure
DhcpAddressAllocationFailure
M ESSA GE
O certificado não é confiável
Certificado não autorizado
Falha na configuração de políticas de
VFP
Falha ao efetuar o emissão de políticas
para os hosts, devido a falhas de
comunicação ou outros erros no
NetworkController.
O host ainda não está conectado ao
Controlador de Rede
Há vários Comutadores habilitados
para VFp no host
Falha ao fazer push de políticas de
VNet para uma VmNic devido a erros
de certificado ou erros de
conectividade
Falha ao push de políticas vSwitch para
uma VmNic devido a erros de
certificado ou erros de conectividade
Falha ao fazer push de políticas de
firewall para uma VmNic devido a erros
de certificado ou erros de
conectividade
Falha ao definir as configurações do
roteador distribuído na vNic do host
Falha na alocação de endereço DHCP
para uma VMNic
AÇÃO
Corrige os certificados usados para
comunicação com o host.
Corrige os certificados usados para
comunicação com o host.
Essa é uma falha de runtime. Nenhuma
solução alternativa definida. Coletar
logs.
Nenhuma ação definida. Isso ocorre
devido à falha no processamento do
estado de meta nos módulos do
Controlador de Rede. Coletar logs.
O Perfil de Porta não é aplicado no
host ou o host não está acessível pelo
Controlador de Rede. Validar se a
chave do Registro HostID corresponde
à ID da Instância do recurso do
servidor
Exclua uma das opções, pois o Agente
de Host do Controlador de Rede dá
suporte apenas a um vSwitch com a
extensão VFP habilitada
Verifique se os certificados apropriados
foram implantados (o nome da
assunto do certificado deve
corresponder ao FQDN do host).
Verifique também a conectividade do
host com o Controlador de Rede
Verifique se os certificados apropriados
foram implantados (o nome da
assunto do certificado deve
corresponder ao FQDN do host).
Verifique também a conectividade do
host com o Controlador de Rede
Verifique se os certificados apropriados
foram implantados (o nome da
assunto do certificado deve
corresponder ao FQDN do host).
Verifique também a conectividade do
host com o Controlador de Rede
Erro de pilha TCPIP. Pode exigir a
limpeza dos vNICs de Host de PA e DR
no servidor no qual esse erro foi
relatado
Verifique se o atributo de endereço IP
estático estático está configurado no
recurso NIC
 C Ó DIGO M ESSA GE
CertificateNotTrusted Falha ao se conectar ao Mux devido a
CertificateNotAuthorized erros de rede ou certificado
HostUnreachable O MUX não está 100%(o caso comum
é O BGPRouter desconectado)
HostNotConnectedToController O agente host SLB não está conectado
PortBlocked A porta VFP está bloqueada devido à
falta de políticas de VNET/ACL
Sobrecarregado O Loadbalancer MUX está
sobrecarregado
RoutePublicationFailure O Loadbalancer MUX não está
conectado a um roteador BGP
VirtualServerUnreachable O Loadbalancer MUX não está
conectado ao gerenciador de SLB
QosConfigurationFailure Falha ao configurar políticas de QOS
Verificar a conectividade de rede entre o controlador de rede e o Host Hyper-V (serviço agente host NC)
Execute o comando netstat abaixo para validar se há três conexões ESTABLISHED entre o Agente de Host NC e
os nós do Controlador de Rede e um soquete LISTENING no Host Hyper-V
ESCUTAndo na porta TCP:6640 no Host Hyper-V (Serviço de 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
AÇÃO
Verifique o código numérico fornecido
no código da mensagem de erro: isso
corresponde ao código de erro
winsock. Os erros de certificado são
granulares (por exemplo, certificado
não pode ser verificado, certificado não
autorizado etc.)
O par BGP no comutador RRAS
(máquina virtual BGP) ou ToR (topo do
rack) está inacessível ou não é possível
fazer o peer com êxito. Verifique as
configurações de BGP no recurso Load
Balancer multiplexador de software e
no par BGP (máquina virtual ToR ou
RRAS)
Verifique se o serviço agente de host
SLB está em execução; Consulte logs
do agente host SLB (execução
automática) por motivos, caso o NC
(SLBM) tenha rejeitado o certificado
apresentado pelo estado de execução
do agente host mostrará informações
nuances
Verifique se há outros erros, o que
pode fazer com que as políticas não
sejam configuradas.
Problema de desempenho com o MUX
Verifique se o MUX tem conectividade
com os roteadores BGP e se o peering
BGP está configurado corretamente
Verificar a conectividade entre o SLBM
e o MUX
Veja se a largura de banda suficiente
está disponível para todas as VMs se a
reserva QOS for usada
 NOTE
Pode haver apenas 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 os serviços do Agente host

O controlador de rede se comunica com dois serviços de agente de host nos hosts Hyper-V: Agente de Host SLB
e Agente de Host NC. É possível que um ou ambos os serviços não sejam executados. Verifique seu estado e
reinicie se eles não estão em execução.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag

Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Verificar a saúde do controlador de rede

Se não houver três conexões ESTABLISHED ou se o Controlador de Rede parecer sem resposta, verifique se
todos os nós e módulos de serviço estão em execução usando os cmdlets a seguir.

# 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 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

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

Correçã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 de 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 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 Assunto do certificado) para a comunicação (SouthBound) entre os nós host Hyper-V (serviço agente
host NC) e controlador de rede. Verifique também se o certificado REST do Controlador de Rede tem o nome da
assunto CN= .
 # 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 seguintes parâmetros de cada certificado para verificar se o nome da entidade é
o esperado (hostname ou FQDN REST nc ou IP), o certificado ainda não expirou e se todas as autoridades de
certificação na cadeia de certificados estão incluídas na autoridade raiz confiável.
Nome do assunto
Data de Validade
Confiável por autoridade raiz
Correção Se vários certificados têm 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 de 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 apresentará o conjunto atual de recursos do Controlador de Rede em
arquivos JSON, todas as configurações de IP de cada host hyper-V (servidor) e política de rede local das tabelas
de banco de dados do Agente 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

$cred = Get-Credential
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
 NOTE
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 de Estado de Configuração do SLB podem ser encontradas no arquivodiagnostics-

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 de SLB, que é usado pelo
Controlador de Rede para coordenar a configuração e a saúde entre os agentes de host SLB Muxes e
SLB.
MuxState – esta seção lista um valor para cada SLB Mux implantado, dando o estado do mux
Configuração do roteador – esta seção lista o ASN (Número do Sistema Autônomo) do roteador
upstream (par BGP), o endereço IP de trânsito e a ID. Ele também lista o SLB Muxes ASN 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 lista os intervalos de pool de IP vip público e privado. O VIP do SLBM será
incluído como um IP alocado de um desses intervalos.
Rotas Mux – esta seção lista um valor para cada SLB Mux implantado que contém 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 de locatário,
incluindo prefixo de rota anunciado, Host hyper-V e pontos de extremidade DIP.

NOTE
O estado SLB pode ser verificado diretamente usando o script DumpSlbRestState disponível no repositório de GitHub
microsoft SDN.

Validação de gateway
Do Controlador de Rede:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Da VM do Gateway:

Ipconfig /allcompartments /all

Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

Na par te superior do rack (ToR) Alternar :

sh ip bgp summary (for 3rd party BGP Routers)

Windows Roteador BGP

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 no FabricConfig.psd1 é menor em comparação com o que as pessoas tentam atribuir às
Conexões de Rede (Túneis S2S) no TenantConfig.psd1. Isso pode ser verificado facilmente comparando as saídas
dos seguintes comandos:

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 foi implantado, as redes virtuais de locatário e as sub-redes foram criadas e
as VMs foram anexadas às sub-redes virtuais, testes de nível de malha adicionais podem ser executados pelo
hoster para verificar a conectividade do locatário.
Verificar conectividade de rede lógica do provedor de 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 de HNV (endereços IP PA) ao host
Hyper-V. Esses IPs serão provenientes do pool de IPS da rede lógica do provedor de HNV e serão gerenciados
pelo controlador de rede. Para descobrir quais são esses dois endereços IP de HNV

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 endereços IP do provedor de HNV (PA IPs) são atribuídos a adaptadores de 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 de HNV (transporte).
A conectividade entre dois hosts Hyper-V usando a rede lógica do provedor 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 o
PAhostVNICs é criado. 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> ...

NOTE
Os adaptadores de host vNIC do 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 de provedor de HNV (PA) de:

H O ST DO H Y P ER- V EN DEREÇ O IP PA 1 EN DEREÇ 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 address on Hyper-V Host 1 in
compartment (-c) 3
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 address on Hyper-V Host 1 in
compartment (-c) 3
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 address on Hyper-V Host 1 in
compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Correção Se o ping do provedor HNV não funcionar, verifique a conectividade da rede física, incluindo a
configuração de VLAN. As NICs físicas em cada host Hyper-V devem estar no modo de tronco sem uma VLAN
específica atribuída. O host de gerenciamento vNIC deve ser isolado para a VLAN da rede lógica de
gerenciamento.

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 MTU e o suporte a quadros Jumbo na rede lógica do provedor de HNV
Outro problema comum na rede lógica do provedor de HNV é que as portas de rede física e/ou a placa Ethernet
não têm uma MTU grande o suficiente configurada para lidar com a sobrecarga do encapsulamento VXLAN (ou
NVGRE).

NOTE
Alguns drivers e placas Ethernet dão suporte à nova palavra-chave * EncapOverhead, que será automaticamente definida
pelo agente de host do controlador de rede para um valor de 160. Esse valor será então adicionado ao valor da palavra-
chave * JumboPacket cujo somatório é usado 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 de HNV dá suporte ao tamanho de MTU maior de ponta a ponta, use o
cmdlet Test-LogicalNetworkSupportsJumboPacket :

# 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
Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is 160
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
Physical Nic <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is 160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo
packets.

Remediação
Ajuste o tamanho de MTU nas portas do comutador físico para que seja pelo menos 1674B (incluindo o
cabeçalho e o trailer de Ethernet 14B)
Se a placa NIC não oferecer suporte à palavra-chave EncapOverhead, ajuste a palavra-chave JumboPacket
para ter pelo menos 1674B
Verificar conectividade NIC de VM de locatário
Cada NIC de VM atribuída a uma VM convidada tem um mapeamento de CA-PA entre o endereço do cliente
privado (CA) e o espaço de endereço do provedor HNV (PA). Esses mapeamentos são mantidos nas tabelas do
servidor OVSDB em cada host do 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

NOTE
Se os mapeamentos de CA-PA esperados não forem impressos para uma determinada VM de locatário, verifique os
recursos de configuração de IP e NIC de VM no controlador de rede usando o cmdlet Get-
NetworkControllerNetworkInterface . Além disso, verifique as conexões estabelecidas entre o agente do 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 de solução de problemas específicos

As seções a seguir fornecem orientações para solucionar problemas de cenários específicos.
Nenhuma conectividade de rede entre duas máquinas virtuais de locatário
1. Vários verifique se Windows Firewall em máquinas virtuais de locatário não está bloqueando o tráfego.
2. Vários Verifique se os endereços IP foram atribuídos à máquina virtual de locatário executando ipconfig.
3. Hoster Execute Test-Vir tualNetworkConnection do host Hyper-V para validar a conectividade entre as
duas máquinas virtuais de locatário em questão.

NOTE
O VSID refere-se à ID de sub-rede virtual. No caso de VXLAN, esse é o VNI (identificador de rede VXLAN). Você pode
encontrar esse valor executando o cmdlet Get-PACAMapping .

Exemplo

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force

$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Criar CA-ping entre "VM verde da Web 1" com SenderCA IP de 192.168.1.4 no host "sa18n30-
2.sa18.nttest.microsoft.com" com IP de gerenciamento de 10.127.132.153 para ListenerCA IP de 192.168.1.5
ambos anexados à sub-rede virtual (VSID) 4114.
 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. Vários Verifique se não há políticas de firewall distribuídas especificadas na sub-rede virtual ou nas interfaces
de rede de VM que bloquearam 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 as sub-redes virtuais que fazem

referência a essa ACL
1. Hoster Execute Get-ProviderAddress em ambos os hosts do 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> do host Hyper-v para validar a conectividade na rede lógica do provedor de HNV
2. Hoster Verifique se as configurações de MTU estão corretas nos hosts Hyper-V e em qualquer dispositivo de
comutação de camada 2 entre os hosts Hyper-V. Execute Test-EncapOverheadValue em todos os hosts Hyper-
V em questão. Verifique também se todos os comutadores de camada 2 no entre têm MTU definido como
menos 1674 bytes para considerar a sobrecarga máxima de 160 bytes.
3. Hoster Se os endereços IP PA não estiverem presentes e/ou se a conectividade de CA for interrompida,
verifique se a política de rede foi recebida. Execute Get-PACAMapping para ver se as regras de encapsulamento
e os mapeamentos de CA-PA necessários para a criação de redes virtuais de sobreposição são estabelecidas
corretamente.
4. Hoster Verifique se o agente de host do controlador de rede está conectado ao controlador de rede. Execute
netstat -anp tcp |findstr 6640 para ver se o
5. Hoster Verifique se a ID do host em HKLM/corresponde à ID da instância dos recursos do servidor que
hospeda as máquinas virtuais de locatário.
6. Hoster Verifique se a ID do perfil de porta corresponde à ID de 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, registro em log e rastreamento avançados.
Log centralizado do controlador de rede
O controlador de rede pode coletar automaticamente os logs do depurador e armazená-los em um local
centralizado. A coleta de log pode ser habilitada quando você implanta o controlador de rede pela primeira vez
ou a qualquer momento mais tarde. Os logs são coletados do controlador de rede e elementos de rede
gerenciados pelo controlador de rede: máquinas host, SLB (balanceadores de carga de software) e máquinas de
gateway.
Esses logs incluem logs de depuração para o cluster do controlador de rede, o aplicativo do controlador de rede,
os logs do gateway, o SLB, a 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 nessas máquinas.
Habilitar o registro em log
O registro em log é habilitado automaticamente quando você instala o cluster do 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 que seja um compartilhamento de arquivos remoto (não local).
os logs de cluster do controlador de rede estão armazenados em % programData% \ Windows Fabric
\log\Traces. Você pode especificar um local centralizado para a coleta de log com o parâmetro
DiagnosticLogLocation com a recomendação de que esse também seja um compartilhamento de arquivo
remoto.
Se você quiser restringir o acesso a esse local, você pode fornecer as credenciais de acesso com o parâmetro
LogLocationCredential . Se você fornecer as credenciais para acessar o local do log, você também deverá
fornecer o parâmetro CredentialEncr yptionCer tificate , que é usado para criptografar as credenciais
armazenadas localmente nos nós do controlador de rede.
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 de 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 local centralizado para armazenar logs, poderá voltar para
o log localmente nos nós do controlador de rede com o UseLocalLogLocation parâmetro (não recomendado
devido a requisitos de espaço em disco grande).
Escopo de log . Por padrão, todos os logs são coletados. Você pode alterar o escopo para coletar somente os
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 maneira circular. Você tem três dias de
dados de registro em log por padrão, independentemente de usar o log local ou o registro em log
 centralizado. Você pode alterar esse limite de tempo com o parâmetro LogTimeLimitInDays .
Tamanho de envelhecimento do log . Por padrão, você terá um máximo de 75 GB de dados de log se
estiver usando o registro em 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 registro em log centralizado para o controlador de rede por padrão. O local
de 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 o Service Fabric do 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 em C:\NCDiagnostics
Diagnóstico de SLB
Erros de malha do SLBM (ações do provedor de serviço de hospedagem )
1. Verifique se o SLBM (Gerenciador de Load Balancer de software) está funcionando e se as camadas de
orquestração podem se comunicar entre si: SLBM-> SLB MUX e SLBM-> agentes de 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 do nó do controlador de rede
(preferivelmente o nó do controlador de rede primário-get-NetworkControllerReplica):
a. O mecanismo de Load Balancer (LB) está conectado ao SLBM? (Total de configurações de LBEngine do
SLBM > 0)
b. O SLBM não conhece pelo menos seus pontos de extremidade? (Total de pontos de extremidade VIP
>= 2)
c. Os hosts do Hyper-V (DIP) estão conectados ao SLBM? (Clientes HP conectados = = número de
servidores)
d. O SLBM está conectado ao Muxes? (Muxes conectado == Muxes íntegro no SLBM == Muxes
Reporting Healthy = # SLB Muxes VMS).
3. Verifique se o roteador BGP configurado está emparelhando com êxito com o SLB MUX
a. Se estiver usando o RRAS com acesso remoto (ou seja, máquina virtual BGP):
a. Get-BgpPeer deve mostrar conectado
b. Get-BgpRouteInformation deve mostrar pelo menos uma rota para o próprio VIP de SLBM
b. Se estiver usando o comutador ToR (Top-of-rack físico) como par de BGP, consulte a documentação
a. Por exemplo: # show BGP Instance
4. Validar os contadores SlbMuxPerfCounters e SLBMUX no perfmon na VM SLB MUX
5. Verificar o estado de configuração e os intervalos VIP no recurso do Gerenciador de Load Balancer de
software
 a. Get-NetworkControllerLoadBalancerConfiguration-Conexãouri <https:// | ConvertTo-JSON-Depth 8
(verifique os intervalos VIP em pools de IPS e garanta o AUTOvip de SLBM
(LoadBalanacerManagerIPAddress) e quaisquer VIPs voltados para o locatário estão dentro desses
intervalos)
a. Get-NetworkControllerIpPool-networkid "<ID de recurso de rede lógica VIP pública/privada>"-
Subnetid "<ID de recurso de sub-rede lógica VIP pública/privada>"-ResourceId " " – conexãouri
$URI | ConvertTo-JSON-Depth 8
b. Debug-NetworkControllerConfigurationState-
Se qualquer uma das verificações acima falhar, o estado SLB do locatário também estará em um modo de falha.
Correção Com base nas seguintes informações de diagnóstico apresentadas, corrija o seguinte:
Garantir que os multiplexadores SLB estejam 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 (provedor de serviços de hospedagem e ações de locatário)
1. Hoster Marque debug-NetworkControllerConfigurationState para ver se há recursos de balanceador de
carga em estado de erro. Tente mitigar seguindo a tabela itens de ação no apêndice.
a. Verificar se um ponto de extremidade VIP está presente e anunciar rotas
b. Verifique quantos pontos de extremidade DIP foram descobertos para o ponto de extremidades VIP
2. Vários Validar Load Balancer recursos especificados corretamente
a. Validar que 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 de back-end do
balanceador de carga
3. Hoster Se os pontos de extremidade DIP não forem descobertos ou conectados:
a. Verificar debug-NetworkControllerConfigurationState
a. Valide se o NC e o agente de host SLB estão conectados com êxito ao coordenador de eventos
do controlador de rede usando netstat -anp tcp |findstr 6640)
b. Verifique o hostid na RegKey do serviço nchostagent (o código de erro HostNotConnected de
referência no apêndice) corresponde à ID de 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 de MUX SLB
As informações do software Load Balancer Muxes também podem ser determinadas por meio de Visualizador
de Eventos.
1. Clique em "Mostrar logs analíticos e de depuração" no menu Visualizador de Eventos exibição
2. navegue até "Logs de aplicativos e serviços" > Microsoft > Windows > SlbMuxDriver > rastreamento
Visualizador de Eventos
3. Clique com o botão direito do mouse e selecione "habilitar log"
 NOTE
É recomendável que você só tenha esse log habilitado por um curto período enquanto estiver tentando reproduzir um
problema

Rastreamento de 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
 Tecnologias do System Center para SDN
11/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

System Center inclui as seguintes tecnologias para uso com a SDN (Rede Definida pelo Software):
System Center Operations Manager
System Center Virtual Machine Manager

System Center Operations Manager

System Center 2019 e 2016 Operations Manager fornecem monitoramento de infraestrutura flexível e
econômico, ajuda a garantir o desempenho previsível e a disponibilidade de aplicativos vitais e oferecem
monitoramento abrangente para seu datacenter e nuvem, tanto privados quanto públicos.
Para obter mais informações, consulte Operations Manager

System Center Virtual Machine Manager

Com System Center 2019 e 2016 Virtual Machine Manager (VMM), você pode:
Provisionar e gerenciar redes virtuais em grande escala.
Implante e gerencie a infraestrutura SDN, incluindo controladores de rede, balanceadores de carga de
software e gateways.
Defina e controle as políticas de rede virtual centralmente e vincule-as a seus aplicativos ou cargas de
trabalho.
Quando sua carga de trabalho é implantada ou movida, a configuração de rede se ajusta
automaticamente. Isso é importante porque ela remove a necessidade de reconfiguração manual de
hardware de rede, reduzindo a complexidade operacional ao salvar seus valiosos recursos para o
trabalho de maior impacto.
Ajuda a controlar o fluxo de tráfego entre redes virtuais, incluindo a capacidade de definir largura de
banda garantida para seus aplicativos críticos e cargas de trabalho.
Para obter mais informações, consulte Configurar uma infraestrutura de SDN (Rede Definida pelo Software) na
malha do VMM.
 Microsoft Azure e rede definida pelo software
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Azure Stack HCI, versão 20H2, Windows Server 2019 e Windows Server
2016

Microsoft Azure é a plataforma de nuvem da Microsoft: uma coleção crescente de serviços integrados –
computação, armazenamento, dados, rede e aplicativo – que ajudam você a se mover mais rapidamente, fazer
mais e economizar dinheiro.
A abordagem da Microsoft à SDN (Rede Definida pelo Software) inclui projetar, criar e operar redes de
datacenter de escala global para serviços como Microsoft Azure. Microsoft Azure datacenters globais executam
dezenas de milhares de alterações de rede todos os dias, o que é possível apenas devido ao SDN.
O Microsoft Azure é executado na mesma plataforma do Windows Server e do Hyper-V que está incluída no
Windows Server. Windows O servidor e System Center incluem melhorias e práticas recomendadas com base
na experiência da Microsoft em operar redes de datacenter de escala global como Microsoft Azure para que
você possa implantar as mesmas tecnologias para flexibilidade, automação e controle ao usar tecnologias SDN.
Para obter mais informações, consulte O que é Microsoft Azure?.
 Entrar em contato com a equipe de rede na nuvem
e Datacenter
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

As soluções ( SDN ) de Rede Definida pelo Software e Rede de Contêiner da Microsoft são criadas pela Equipe
de Rede de Nuvem e Datacenter. Use esta página para entrar em contato com a equipe – para fazer perguntas,
fornecer comentários, relatar bugs ou fazer solicitações de recursos.
Há muitas vias para entrar em contato com as equipes da Microsoft e, embora façamos nosso melhor na equipe
do SDN para seguir todas as vias usadas por nossa comunidade, aqui está uma lista de fóruns que tendem a ser
os mais ativos. Esses são os principais recursos para nossos usuários e, como tal, eles são as vias que
observamos mais próximos.

Twitter
Recentemente, lançamos nossa presença no Twitter como @Microsoft_SDN . Sinta-se à vontade para usar nosso
alça do Twitter para fazer perguntas, fornecer comentários ou fazer solicitações de recurso/documentação.

Além de um local em que você possa entrar em contato com perguntas/comentários/solicitações, considere
o Twitter o local para obter seu "feed" em tudo o que o SDN e a rede de contêineres do Windows
relacionados – o Twitter é o primeiro lugar em que postaremos notícias, anunciaremos novos recursos e
apontaremos a comunidade para todos os nossos blogs e recursos mais recentes.

GitHub (microsoft/SDN repo)

Acesse aqui para enviar problemas para a equipe do SDN por meio de nosso GitHub repositório. Esse é o
melhor lugar para obter ajuda para solucionar problemas ou relatar bugs.

GitHub é o melhor lugar para entrar em contato conosco sobre tópicos que envolvem mais detalhes do que
os tipos de coisas que você pode ajustar facilmente em um Tweet. Precisa de ajuda com a implantação do
SDN? Não tem certeza de como nossos recursos podem atender às necessidades exclusivas da sua
organização? Está sendo mantido por um possível bug? Todos os bons motivos para entrar em contato
conosco enviando um GitHub problema.

Microsoft Docs
Nossa documentação de Rede de Contêineres pode ser encontrada Microsoft Docs (docs.microsoft.com), que
tem a funcionalidade de comentário. Para sair ou responder a um comentário Microsoft Docs basta entrar, role
para baixo até a parte inferior da página Microsoft Docs que você deseja referenciar e, em seguida, faça e envie
seu comentário para lá.

Microsoft Docs é o novo site de documentação unificada da Microsoft. Embora a maioria da documentação
do SDN da nossa equipe permaneça no TechNet, nossa documentação de Rede de Contêineres agora está
Microsoft Docs.
Em geral, se você tiver um tópico no Microsoft Docs que a spark uma pergunta ou deixar você desejar mais,
basta deixar um comentário nessa página para compartilhar seus comentários com a equipe da Microsoft
 que pode ajudar.

Container-Specific fóruns
Sinta-se à vontade para usar qualquer caminho nesta página para fornecer comentários relacionados a
contêineres e rede de contêineres. No entanto, se você estiver procurando os fóruns principais da Microsoft
para a comunidade de contêineres especificamente, consulte o seguinte:
Voz do usuário – melhor para solicitações de recursos
Github (repo de virtualização) – melhor para buscar a solução de problemas de ajuda e relatar bugs
Não está vendo o fórum para você?
Sempre que possível, incentivamos o uso de nossos fóruns públicos para que a comunidade mais ampla possa
se beneficiar do acesso às perguntas e comentários que vêm em nosso caminho. No entanto, também
reconhecemos que há situações em que o email é simplesmente a maneira preferencial de entrar em contato
conosco. Se você estiver em uma dessas situações, envie um email para e teremos o prazer de
sdn_feedback@microsoft.com saber de você.
 VPN (rede virtual privada)
11/08/2021 • 2 minutes to read

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

no Windows Server 2016, a função de servidor de acesso remoto é um agrupamento lógico das tecnologias de
acesso à rede relacionadas a seguir.
Serviço de acesso remoto (RAS)
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 DirectAccess e VPN (RAS) , você está implantando o gateway de serviço de
acesso remoto (Gateway de Ras ). Você pode implantar o gateway RAS como um servidor de rede virtual
privada (VPN) de gateway de RAS de locatário único que fornece muitos recursos avançados e funcionalidade
aprimorada.

NOTE
Você também pode implantar o gateway RAS como um servidor VPN multilocatário para uso com o SDN (rede definida
pelo software) ou como um servidor DirectAccess. Para obter mais informações, consulte Gateway de Ras, rede definida
por software (SDN)e DirectAccess.

Tópicos relacionados
Always on recursos e funcionalidades de VPN: neste tópico, você aprende sobre os recursos e a
funcionalidade de Always on VPN.
configurar túneis de dispositivo vpn no Windows 10: Always On VPN oferece a capacidade de criar um
perfil VPN dedicado para o 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 de dispositivo é usado para cenários de
conectividade pré-login e para fins de gerenciamento de dispositivos. 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 RAS 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 revisar os guias de design e implantação para cada uma das
tecnologias usadas nesta implantação.
guia técnico de VPN Windows 10: orienta você pelas decisões que você fará para Windows 10 clientes
em sua solução de VPN corporativa e como configurar sua implantação. você pode encontrar referências
ao provedor de serviços de configuração do VPNv2 (CSP) 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ê aprende 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 do
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 de perfil vpn no Windows 10 e saiba como
configurar perfis vpn usando o Intune ou o Configuration Manager. você pode definir todas as
configurações de VPN no Windows 10 usando o nó ProfileXML no CSP VPNv2.
 Serviço de Cadastramento na Internet do Windows
(WINS)
13/08/2021 • 2 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows Server 2016

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 o WINS-em vez disso, implante o DNS
do sistema de nome 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 o 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, encerrar o
WINS.
 Serviço de Horário do Windows (W32Time)
11/08/2021 • 3 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10 ou posterior

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 Ser ver 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. Sob condições operacionais razoáveis, você pode manter uma precisão de
1 ms com relação ao UTC ou melhor para membros de domínio do Windows Server 2016 e da Atualização
de Aniversário do Windows 10.
Limite de supor te 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 a precisão de 1 ms (milissegundo) ou melhor (com respeito ao UTC).
Tempo do Windows 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 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.
Referência técnica do Ser viç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 Ser viç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 Ser viç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.
Tópicos relacionados
Para obter mais informações sobre a hierarquia de domínio e o sistema de pontuação, confira "O que é o
Serviço de Tempo do Windows?" .
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
13/08/2021 • 2 minutes to read

Suporte a segundo bissexto

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows 10, versão 1809

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.
Para obter mais informações, consulte:
Nosso blog de comunicado
Guia de Validação para Desenvolvedores
Guia de Validação para Profissionais de TI

Protocolo de tempo de precisão

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows 10, versão 1809

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.
Para obter mais informações, consulte:
Nosso blog de comunicado
Guia de Validação para Profissionais de TI

Carimbo de data/hora do software

Aplica-se a: Windows Server 2022, Windows Server 2019 e Windows 10, versão 1809

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.
Para obter mais informações, consulte:
Nosso blog de comunicado
Guias de validação para desenvolvedores e profissionais de TI
 Hora precisa no Windows Server 2016
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10 ou posterior

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.

NOTE
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

IMPORTANT
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.

NOTE
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.

NOTE
Para obter mais informações sobre a hierarquia de domínio e o sistema de pontuação, confira "O que é o Serviço de
Tempo do Windows?" .

NOTE
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

Referências adicionais
Aprimoramentos de precisão de tempo para o Windows Server 2016
 Limite de suporte para a hora de alta precisão
13/08/2021 • 4 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows 10 versão
1607 ou posterior

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 o Windows 10 ou o Windows Server 2016 e versões mais
recentes podem fornecer uma precisão de 1 segundo, 50 ms (milissegundos) ou 1 ms.

IMPORTANT
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.

IMPORTANT
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 unidirecional 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 requisitos adicionais para obter precisão de 50 ms para um sistema de destino específico são:
O computador de destino deve ter latência de rede melhor que 5 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

NOTE
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 requisitos adicionais 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

NOTE
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
13/08/2021 • 5 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016 e Windows 10 versão
1607 ou posterior

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

WARNING
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

 IMPORTANT
Obser vaçã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.
 TIP
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 Hora do Windows –
Ferramentas do Serviço de Hora do Windows.
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.

DESC RIÇ Ã O VA LO R

Localização principal HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Confi

g

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.

DESC RIÇ Ã O VA LO R

Localização principal HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Confi

g

Configuração 6
 DESC RIÇ Ã O VA LO R

Resultado O intervalo de sondagem máximo agora é de 64 segundos.

O seguinte comando sinaliza o Horário do Windows para selecionar as configurações atualizadas:

w32tm /config /update

UpdateInterval
O número de tiques de relógio entre os ajustes de correção de fase.

DESC RIÇ Ã O VA LO R

Localização principal HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Confi

g

Configuração 100

Resultado O número de tiques de relógio entre os ajustes de correção

de fase agora é de 100 tiques.

O seguinte comando sinaliza o Horário do Windows para selecionar as configurações atualizadas:

w32tm /config /update

SpecialPollInterval
Configura o intervalo de sondagem em segundos quando o sinalizador SpecialInterval 0x1 está habilitado.

DESC RIÇ Ã O VA LO R

Localização principal HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\TimeP

roviders\NtpClient

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
DESC RIÇ Ã O VA LO R

Localização principal HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Confi

g

Configuração 2
 Horário do Windows para rastreabilidade
10/08/2021 • 6 minutes to read

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

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 Ser vices
Log\Microsoft\Windows\Time-Ser vice\Operational .

Lista de logs de eventos

A seção a seguir descreve os eventos registrados para uso em cenários de rastreabilidade.
257
258
259
260
261
262
263
264
265
266

Esse evento é registrado em log quando o Serviço de Horário do Windows (W32Time) é iniciado e registra
informações em log sobre a hora atual, a contagem atual de tiques, a configuração do runtime, os provedores
de horário e a taxa atual do relógio.
 DESC RIÇ Ã O DO EVEN TO IN ÍC IO 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 limitação Nenhum. Esse evento é disparado sempre que o serviç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
13/08/2021 • 6 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10 ou posterior

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.

NOTE
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 no Windows Server 2008, o serviço de diretório é denominado AD DS
(Active Directory Domain Services). 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.

WARNING
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.

IMPORTANT
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 isso, confira Tempo Preciso do Windows 2016 e
Limite de suporte para configurar o Serviço de Horário do Windows para ambientes de alta precisão para obter mais
informações.

Tópicos relacionados
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
Artigo 902229 da Base de Dados de Conhecimento Microsoft
 Como funciona o serviço Horário do Windows
13/08/2021 • 27 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10 ou posterior

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

NOTE
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.

NOTE
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 é chamado de AD DS (Active
Directory Domain Services). 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

IMPORTANT
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. Confira Tempo Preciso do Windows 2016 e Limite de suporte para configurar o
Serviço de Horário 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 Ser viç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 NtpSer ver. 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

C O N T RO L A DO R DE C O N F IA B IL IDA DE DA
N ÚM ERO DA C O N SULTA DO M ÍN IO LO C A L F O N T E DE H O RÁ RIO

1 Controlador de domínio pai No local Prefere uma fonte de

horário confiável, mas
poderá sincronizar com
uma fonte de horário não
confiável se for o que está
disponível.

2 Controlador de domínio No local Só sincroniza com uma

local fonte de horário confiável.
 C O N T RO L A DO R DE C O N F IA B IL IDA DE DA
N ÚM ERO DA C O N SULTA DO M ÍN IO LO C A L F O N T E DE H O RÁ RIO

3 Emulador de PDC local No local Não se aplica.

Um controlador de
domínio não tenta
sincronizar com ele
mesmo.

4 Controlador de domínio pai Fora do site Prefere uma fonte de

horário confiável, mas
poderá sincronizar com
uma fonte de horário não
confiável se for o que está
disponível.

5 Controlador de domínio Fora do site Só sincroniza com uma

local fonte de horário confiável.

6 Emulador de PDC local Fora do site Não se aplica.

Um controlador de
domínio não tenta
sincronizar com ele
mesmo.

Obser vaçã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

STAT US DO C O N T RO L A DO R DE DO M ÍN IO P O N T UA Ç Ã O

Controlador de domínio localizado no mesmo site 8

Controlador de domínio marcado como uma fonte de 4

horário confiável

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 NtpSer ver . 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 por ta para o Ser viço de Horário do Windows

N O M E DO SERVIÇ O UDP TC P

NTP 123 N/D

SNTP 123 N/D

Consulte Também
Referência técnica do Serviço de Horário do Windows Ferramentas e configurações do Serviço de Horário do
Windows Artigo 902229 da Base de Dados de Conhecimento Microsoft
 Ferramentas e configurações do Serviço de Tempo
do Windows
18/08/2021 • 32 minutes to read

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012
R2, Windows Server 2012 e Windows 10

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, geralmente é configurado para sincronizar a hora com
uma fonte de hora 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 Windows Server 2016.
Cau t i on

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
/quer ysntp 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.

NOTE
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.

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:

PA RÂ M ET RO DESC RIÇ Ã O

/? 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 name>] [/computers:<name> Monitora o Serviço de Hora do Windows.

[,<name>[,<name>...]]] [/threads:<num>]
/domain : especifica o domínio a ser monitorado. Se
nenhum nome de domínio for especificado ou se a
opção /domain nem 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 controlador de
domínio primário. 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 <NT time epoch> 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 <NTP time epoch> 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.
PA RÂ M ET RO
/resync [/computer:<computer>] [/nowait] [/rediscover]
[/soft]
/stripchar t /computer:<target> [/period:<refresh>]
[/dataonly] [/samples:<count>] [/rdtsc]
DESC RIÇ Ã O
Informa a um computador que ele deve ressincronizar seu
relógio assim que possível, descartando todas as estatísticas
de 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.
Exibe um gráfico de faixas da diferença entre este e outro
computador.
/computer :< target > : o computador em relação ao
qual a 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 <count> e, em
seguida, interrompe o processo. 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
RdtscStar t , RdtscEnd , FileTime , RoundtripDelay e
NtpOffset , em vez do gráfico de texto.
RdtscStar t : 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.
PA RÂ M ET RO
/config [/computer:<target>] [/update] [/manualpeerlist:
<peers>] [/syncfromflags:<source>] [/LocalClockDispersion:
<seconds>] [/reliable:(YES|NO)] [/largephaseoffset:
<milliseconds>]**
/tz
/dumpreg [/subkey:<key>] [/computer:<target>]
DESC RIÇ Ã O
/computer :< target > : ajusta a configuração de <target>.
Se não for especificada, o padrão será o computador local.
/update : notifica o Serviço de Hora do Windows de que
a configuração foi alterada, fazendo com que as
alterações entrem em vigor.
/manualpeerlist:< peers > : define a lista de pares
manual como <peers>, que é uma lista delimitada por
espaços de DNS e/ou endereços 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. <source> deve
ser uma lista separada por vírgula 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) : define se este computador é uma
fonte de hora 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:< milliseconds > : define a diferença de
hora entre a hora local e a da rede que o W32Time vai
considerar um pico.
Exibe as configurações de fuso horário atuais.
Exibe os valores associados a uma determinada chave do
Registro.
A chave padrão é
HKLM\System\CurrentControlSet\Ser vices\W32Ti
me (a chave raiz do Serviço de Hora do Windows).
/subkey:< key > : exibe os valores associados à
subchave da chave padrão.
/computer :< target > : consulta as configurações do
Registro para o computador <target>
 PA RÂ M ET RO DESC RIÇ Ã O

/quer y [/computer:<target>] {/source | /configuration | Exibe as informações do Serviço de Hora do Windows do

/peers | /status} [/verbose] computador. Esse parâmetro foi disponibilizado pela primeira
vez no cliente de Hora do Windows no Windows Vista e no
Windows Server 2008.
/computer :< target > : consulta as informações de
<target>. 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 /file:<name> /size:/<bytes>
/entries:<value> [/truncate]}}
habilita ou desabilita o log privado do Serviço de Hora do
Windows do computador local. Esse parâmetro foi
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:

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 a hora usando um computador especificado
manualmente para sincronizar a hora automaticamente da hierarquia de domínio do AD, execute o seguinte:
 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:

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.

IMPORTANT
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 hora, deverá especificar o sinalizador (0x2) Ntpser ver UseAsFallbackOnly para
retirar a prioridade de um deles. Por exemplo, se quiser priorizar ntpserver.contoso.com com relação a
clock.adatum.com , execute o comando a seguir.

w32tm /config /manualpeerlist:"ntpserver.contoso.com,0x8 clock.adatum.com,0xa" /syncfromflags:manual

/update

Além disso, você pode executar o seguinte comando e ler o valor de NtpServer na saída:

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 : ajusta o relógio do comutador gradualmente usando a taxa do
relógio.
CurrentTimeOffset ≥ MaxAllowedPhaseOffset : define 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 × 1.000 × 10.000)
PhaseCorrection = min( PhaseCorrection_raw , MaximumCorrection )

Windows Server 2012 R2 e versões anteriores:

 PhaseCorrection = | CurrentTimeOffset | ÷ ( PhaseCorrectRate × UpdateInterval )

Todas as versões do Windows usam a mesma equação final para verificar PhaseCorrection :

PhaseCorrection ≤ SystemClockRate ÷2

NOTE
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 de tiques do
relógio
| CurrentTimeOffset | = 4 min = 4 × 60 × 1.000 × 10.000 = 2.400.000.000 de tiques do 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: FALSE
Portanto, W32tm.exe atrasaria o relógio imediatamente.

NOTE
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 de tiques do
relógio
| CurrentTimeOffset | = 3 min = 3 × 60 × 1.000 × 10.000 = 1.800.000.000 de tiques do relógio

É CurrentTimeOffset ≤ MaxAllowedPhaseOffset ?

1.800.000.000 ≤ 6.000.000.000: TRUE

E atende à equação a seguir?

(| CurrentTimeOffset | ÷ ( PhaseCorrectRate × UpdateInterval )≤ SystemClockRate ÷ 2)

3 minutos × (1.800.000.000) ÷ (30.000 × 1) é ≤ 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 de Hora 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.

NOTE
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\Time Providers\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.

NOTE
Quando você remove uma configuração de Política de Grupo, o Windows remove a entrada correspondente da área de
política do Registro.

P O L ÍT IC A DE GRUP O 1 LO C A L IZ A Ç Õ ES DO REGIST RO 2, 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

 P O L ÍT IC A DE GRUP O LO C A L IZ A Ç Õ ES DO REGIST RO

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

WARNING
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\Ser vices\W32Time nas seguintes subchaves:
\Config
\Parameters
\TimeProviders\NtpClient
\TimeProviders\NtpSer ver
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.

NOTE
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 passam a ser 5 × 60 × 1.000 × 10.000 = 3.000.000.000 tiques do relógio.

Entradas de configuração
As entradas de subchave Config estão localizadas em HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config .

EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O

EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O

AnnounceFlags Todas as versões Controla se este computador está

marcado 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 .

ChainEntr yTimeout 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).
EN T RA DA DE REGIST RO VERSÕ ES
ChainMaxHostEntries
ClockAdjustmentAuditLimit Windows Server 2016 versão 1709 e
versões posteriores; Windows 10
versão 1709 e versões posteriores
ClockHoldoverPeriod Windows Server 2016 versão 1709 e
versões posteriores; Windows 10
versão 1709 e versões posteriores
EventLogFlags Todas as versões
FrequencyCorrectRate Todas as versões
DESC RIÇ Ã O
Controla o número máximo de
entradas permitidas na tabela de
encadeamento para um host
específico. O valor padrão é 4
(entradas).
Especifica os menores ajustes do
relógio local que podem ser
registrados no log de eventos do
serviço W32time no computador de
destino. O valor padrão é 800 (PPM –
partes por milhão).
Indica o número máximo de segundos
que um relógio do sistema pode
manter nominalmente a precisão sem
sincronizar com uma fonte de hora. Se
esse período passar sem o W32time
obter novas amostras de um dos
provedores de entrada, o W32time
iniciará uma redescoberta de fontes de
hora. Default: 7.800 segundos.
Controla os eventos que o serviço de
hora 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 .
Controla a velocidade na qual o relógio
é 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 .
Obser vação
Zero não é um valor válido para a
entrada do Registro
FrequencyCorrectRate . Em
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
Hora do Windows vai alterá-lo
automaticamente para 1 .
EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O

HoldPeriod Todas as versões Controla o período para o qual a

detecção de picos é desabilitada, a fim
de colocar o relógio local em
sincronização rapidamente. Um pico é
uma amostra de horário que indica
que o horário está incorreto em um
número de segundos e, geralmente, é
recebido depois que amostras de
horário correto são retornadas de
maneira consistente. O valor padrão
em membros do domínio é 5 . O valor
padrão em clientes e servidores
autônomos é 5 .

LargePhaseOffset Todas as versões Especifica que uma diferença de

horário 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 versões Mantida pelo W32Time. Contém

dados 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 versões Controla a dispersão (em segundos)

que você 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 versões Especifica a diferença máxima (em

segundos) 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 .
EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O

MaxClockRate Todas as versões Mantida pelo W32Time. Contém

dados reservados usados pelo sistema
operacional Windows. Qualquer
alteração nessa configuração pode
causar resultados 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 versões Especifica a maior correção de horário

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.
Obser vação
O valor 0xFFFFFFFF é um caso
especial. Esse valor significa que o
serviço sempre corrigirá a hora.
O valor padrão para membros do
domínio é 0xFFFFFFFF . O valor
padrão para clientes e servidores
autônomos é 54.000 (15 horas).

MaxPollInter val Todas as versões Especifica o maior intervalo, em log2

segundos, permitido para o intervalo
de sondagem do sistema. Observe
que, embora um sistema deva sondar
de acordo com o intervalo agendado,
um provedor poderá se recusar a
produzir amostras quando solicitado.
O valor padrão para controladores de
domínio é 10 . O valor padrão para
membros do domínio é 15 . O valor
padrão para clientes e servidores
autônomos é 15 .

MaxPosPhaseCorrection Todas as versões Especifica a maior correção de horário

positivo 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.
Obser vação
O valor 0xFFFFFFFF é um caso
especial. Esse valor significa que o
serviço sempre corrigirá a hora.
O valor padrão para membros do
domínio é 0xFFFFFFFF . O valor
padrão para clientes e servidores
autônomos é 54.000 (15 horas).
EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O

MinClockRate Todas as versões Mantida pelo W32Time. Contém

dados reservados usados pelo sistema
operacional Windows. Qualquer
alteração nessa configuração pode
causar resultados 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 .

MinPollInter val Todas as versões Especifica o menor intervalo, em

segundos na base de log 2, permitido
para o intervalo de sondagem do
sistema. Observe que, embora um
sistema não solicite amostras com
mais frequência do que isso, um
provedor poderá produzir amostras
em horários 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 versões Controla a velocidade na qual o erro

de fase é 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 valor padrão em
clientes e servidores autônomos é
7.
Obser vação
Zero não é um valor válido para a
entrada do Registro
PhaseCorrectRate . Em
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
Hora do Windows vai alterá-lo
automaticamente para 1 .

PollAdjustFactor Todas as versões Controla a decisão de aumentar ou

diminuir o 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 servidores autônomos é 5 .
 EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O

RequireSecureTimeSyncRequests Windows 8 e versões posteriores Controla se o controlador de domínio

responderá às solicitações de
sincronização de 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 versões Especifica o tempo pelo qual uma

diferença 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 versões Um inteiro sem sinal que indica o

limite de 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.

UpdateInter val Todas as versões Especifica o número de tiques do

relógio entre 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 .
Obser vação
Zero não é um valor válido para a
entrada do Registro
UpdateInter val. 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 Windows posteriores ao Um valor igual a 1 indica que o

Windows 10 build 1511 W32Time usa vários carimbos de
data/hora SSL para propagar um
relógio grosseiramente impreciso.

Entradas de parâmetros
As entradas de subchave Parameters estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters .
EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O

AllowNonstandardModeCombinat Todas as versões Indica que as combinações de modo

ions não padrão são permitidas na
sincronização entre pares. O valor
padrão para membros do domínio é 1 .
O valor padrão para clientes e
servidores autônomos é 1 .

NtpSer ver Todas as versões Especifica uma lista de pares delimitada

por espaço da qual um computador
obtém 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.
0x01 SpecialInterval
0x02 UseAsFallbackOnly
0x04 SymmetricActive: para
obter mais informações sobre
esse modo, confira Servidor de
Hora do Windows.
0x08 Cliente

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 .

Ser viceDll Todas as versões Mantida pelo W32Time. Contém

dados reservados usados pelo sistema
operacional Windows. Qualquer
alteração nessa configuração pode
causar resultados 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.

Ser viceMain Todas as versões Mantida pelo W32Time. Contém

dados 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 é
SvchostEntr y_W32Time . O valor
padrão em clientes e servidores
autônomos é
SvchostEntr y_W32Time .
 EN T RA DA DE REGIST RO VERSÕ ES DESC RIÇ Ã O

Tipo Todas as versões Indica de quais pares a sincronização

será aceita:
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 NtpSer ver .
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

EN T RA DA DE REGIST RO VERSÃ O DESC RIÇ Ã O

AllowNonstandardModeCombinat Todas as versões Indica que as combinações de modo

ions não padrão são permitidas na
sincronização entre pares. O valor
padrão para membros do domínio é 1 .
O valor padrão para clientes e
servidores autônomos é 1 .

CompatibilityFlags Todas as versões Especifica os seguintes valores e

sinalizadores de compatibilidade:
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 .
EN T RA DA DE REGIST RO VERSÃ O DESC RIÇ Ã O

CrossSiteSyncFlags Todas as versões Determina se o serviço escolhe os

parceiros de sincronização fora do
domínio do 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 as versões Especifica a localização da DLL para o

provedor de horário.
A localização padrão dessa DLL em
membros de domínio e clientes e
servidores autônomos é
%windir%\System32\W32Time
.dll.

Habilitada Todas as versões Indica se o provedor NtpClient está

habilitado no Serviço de Hora atual.
1 – Sim
0 – Não
O valor padrão em membros do
domínio é 1 . O valor padrão em
clientes e servidores autônomos é 1 .

EventLogFlags Todas as versões Especifica os eventos registrados em

log pelo Serviço de Hora do Windows.
0x1 : alterações de
acessibilidade
0x2 : distorção de amostra
grande (aplicável somente ao
Windows Server 2003, ao
Windows Server 2003 R2, ao
Windows Server 2008 e ao
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 .
EN T RA DA DE REGIST RO VERSÃ O DESC RIÇ Ã O

InputProvider Todas as versões Indica se o NtpClient deve ser

habilitado como um InputProvider, que
obtém 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 as versões Especifica a distorção de amostra

grande para o log, em segundos. Para
estar em 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 servidores
autônomos é 3.

ResolvePeerBackOffMaxTimes Todas as versões Especifica o número máximo de vezes

a dobrar o intervalo de espera quando
há 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 as versões Especifica o intervalo inicial de espera,

em minutos, antes da tentativa de
localizar um par com o qual será feita a
sincronização. O valor padrão em
membros do domínio é 15 . O valor
padrão em clientes e servidores
autônomos é 15 .
 EN T RA DA DE REGIST RO VERSÃ O DESC RIÇ Ã O

SpecialPollInter val Todas as versões Especifica o intervalo de sondagem

especial, em segundos, para os pares
manuais. Quando o sinalizador
SpecialInter val 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

SpecialPollInter val está contido nos
valores do Registro de configuração
MinPollInter val e MaxPollInter val.

SpecialPollTimeRemaining Todas as versões Mantida pelo W32Time. Contém

dados reservados usados pelo sistema
operacional 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 configuração
pode causar resultados 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 NtpClient estão localizadas em
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer .

EN T RA DA DO REGIST RO VERSÕ ES DESC RIÇ Ã O

AllowNonstandardModeCombinations Todas as versões Indica que as combinações de modo

não padrão são permitidas na
sincronização entre 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 as versões Especifica a localização da DLL para o

provedor de horário. A localização
padrão dessa DLL em membros de
domínio e clientes e servidores
autônomos é
%windir%\System32\W32Time.dll .

habilitado Todas as versões Indica se o provedor NtpServer está

habilitado no Serviço de Hora atual.
1 – Sim
0 – Não
O valor padrão em membros do
domínio é 1 . O valor padrão em
clientes e servidores autônomos é 1 .
 EN T RA DA DO REGIST RO VERSÕ ES DESC RIÇ Ã O

InputProvider Todas as versões Indica se o NtpClient deve ser

habilitado como um InputProvider, que
obtém 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 do
domínio e clientes autônomos: 1

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:

EN T RA DA VERSÕ ES DESC RIÇ Ã O

FileLogEntries Todas as versões Controla o número de entradas criadas

no arquivo de log de Hora do
Windows. O valor padrão é nenhum,
que não registra nenhuma 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

FileLogName Todas as versões Controla a localização e o nome do

arquivo de log de Hora do Windows. O
valor padrão é em branco e não deve
ser alterado, a 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.
 EN T RA DA VERSÕ ES DESC RIÇ Ã O

FileLogSize Todas as versões Controla o comportamento de log

circular dos arquivos de log de Hora
do Windows. Quando FileLogEntries
e FileLogName são 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.

C O N F IGURA Ç Ã O DA P O L ÍT IC A DE GRUP O VA LO R PA DRÃ O

AnnounceFlags 10

EventLogFlags 2

FrequencyCorrectRate 4

HoldPeriod 5

LargePhaseOffset 1.280.000

LocalClockDispersion 10

MaxAllowedPhaseOffset 300

MaxNegPhaseCorrection 54.000 (15 horas)

MaxPollInterval 15

MaxPosPhaseCorrection 54.000 (15 horas)

MinPollInterval 10

PhaseCorrectRate 7

PollAdjustFactor 5
 C O N F IGURA Ç Ã O DA P O L ÍT IC A DE GRUP O VA LO R PA DRÃ O

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.

C O N F IGURA Ç Ã O DA P O L ÍT IC A DE GRUP O VA LO R PA DRÃ O

NtpServer time.windows.com , 0x1

Type NTP – use para computadores não conectados ao domínio

NT5DS – use para computadores conectados ao domínio

CrossSiteSyncFlags 2

ResolvePeerBackoffMinutes 15

ResolvePeerBackoffMaxTimes 7

SpecialPollInterval 3.600

EventLogFlags 0

Informações relacionadas
Confira RFC 1305 – Protocolo NTP da IETF (Internet Engineering Task Force).