Windows 2000 não resolve por nome após upgrade do DC para Windows Server 2019: diagnóstico, correções e migração segura

Após promover um controlador de domínio de Windows Server 2012 para 2019, um servidor Windows 2000 com SQL Server 2000 parou de responder pelo hostname, embora o acesso por IP funcione. Este guia prático mostra diagnóstico, correções imediatas e mitigação de risco sem recorrer a soluções improvisadas.

Índice

Visão geral do problema

O cenário é clássico em ambientes com sistemas legados: após a mudança de controlador de domínio (DC) para Windows Server 2019, o servidor Windows 2000, ainda membro do domínio e executando SQL Server 2000, deixa de ser acessível pelo nome. As aplicações que dependem do nome (por exemplo, cadeias de conexão como Server=SQL2000;) falham, enquanto conexões diretas por endereço IP continuam operando. Isso aponta para uma causa primária de resolução de nomes e, em segundo plano, para endurecimentos de segurança típicos de versões modernas do Windows.

Por que isso acontece

O Windows Server 2019 endurece padrões de segurança e atualiza defaults de serviços (DNS, descontinuação de SMB 1.0, políticas de NTLM, assinaturas SMB, entre outros). Já o Windows 2000 usa protocolos e clientes DNS/NetBIOS mais antigos. Quando o DC 2012 é promovido e o ambiente é atualizado, pequenas mudanças — como zonas DNS sem os registros corretos, exclusão de WINS, bloqueios de firewall, ou políticas de NTLM muito rígidas — podem romper a resolução nominal do host 2000 e/ou sua autenticação com o domínio.

Sintomas e testes rápidos

Funciona por IP, falha por nome: ping 10.1.2.3 responde; ping SQL2000 ou ping SQL2000.seudominio.local resolve para IP errado ou não resolve.
Clientes recebem erros de aplicação como “server not found”, “SQL Server does not exist or access denied” (08001/17) quando a cadeia usa nome.
Em logs, eventos de Netlogon/DNS no Windows 2000 e avisos de segurança/NTLM no DC 2019.

Mapa de soluções e recomendações

Área	Ações sugeridas	Observações
DNS / Resolução de nomes	Apontar o Windows 2000 para o(s) DNS interno(s) do domínio. Criar/validar registros A e, se possível, PTR. Forçar `ipconfig /registerdns` ou criar registros estáticos.	Se a rede ainda depende de NetBIOS, manter WINS ou usar LMHOSTS como contingência. A prova de que IP funciona reforça a hipótese DNS.
Configuração de rede	Revisar IP/máscara/gateway/DNS nos servidores. Confirmar ausência de duplicidade de IP/hostname e que o DC 2019 responde a consultas DNS/NetBIOS.	Em ambientes modernos, NetBIOS muitas vezes está desativado; reativar apenas para o segmento legado pode ajudar.
Firewall	Liberar portas do SQL 2000 (TCP 1433, UDP 1434) e, se necessário para diagnósticos antigos, portas NetBIOS/SMB.	Protocolos antigos (SMB 1.0, NTLMv1) são arriscados. Avalie riscos e isole o legado.
SQL Server 2000	Na Server Network Utility, confirmar escuta no IP correto/porta padrão; habilitar TCP/IP. Testar com `telnet <nome> 1433`.	Verifique também a Client Network Utility nos clientes que chamam o SQL 2000.
Compatibilidade / NTLM	Ajustar GPO “LAN Manager authentication level” no DC/OU do host legado ou configurar o próprio Windows 2000 para usar NTLMv2.	Restrinja o escopo da exceção a uma OU ou política dedicada ao legado.
Drivers e atualizações	Aplicar Windows 2000 SP4 + Rollup e drivers de NIC mais estáveis que existirem no acervo local.	Ainda que sem suporte, essas correções mitigam falhas de DNS/NetBIOS.
Ferramentas de compatibilidade	No 2019 não há “modo compatibilidade” para serviços remotos; pode‑se ativar componentes herdados (SMB 1.0/CIFS) apenas na zona isolada.	Reveja rotinas de backup e plano de rollback antes de mudar políticas.
Estratégia de longo prazo	Migrar o SQL 2000 para versão suportada ou virtualizar o Windows 2000 em rede isolada.	Elimine protocolos inseguros, reduza superfície de ataque e simplifique suporte.

Procedimento mínimo para restaurar a funcionalidade

Consertar o DNS: crie/valide o registro A do servidor Windows 2000 na zona do domínio e, se possível, o PTR correspondente.
Limpar caches: em clientes, ipconfig /flushdns; reinicie o serviço DNS Client se necessário. No Windows 2000, reinicie o Netlogon ou execute ipconfig /registerdns.
Testar resolução: nslookup SQL2000 e nslookup SQL2000.seudominio.local. Depois confirme ping SQL2000.
Verificar autenticação: se ainda houver falhas de logon/conexão, ajuste a política de NTLM (no DC com escopo restrito ou no próprio Windows 2000 para utilizar NTLMv2).
Checar portas: liberar TCP 1433 e UDP 1434 no caminho entre clientes e o servidor SQL 2000.

Dica de contingência: se não puder ajustar o DNS no momento, inclua temporariamente uma entrada em C:\Windows\System32\drivers\etc\hosts nos clientes mapeando o nome do servidor ao seu IP (remova após normalizar o DNS).

Diagnóstico aprofundado e correções

DNS e resolução de nomes

Confirme que o Windows 2000 usa apenas os DNS internos do domínio. Evite DNS público no campo do adaptador de rede.

Criar/validar registros:
- Registro A: SQL2000 → 10.1.2.3 na zona do AD.
- Registro PTR correspondente em Reverse Lookup Zone (se existente).
Replicação de zona: se há múltiplos DCs/DNS, valide que a zona replicou e que não há registros divergentes.
Forçar registro do host no Windows 2000: ipconfig /registerdns nbtstat -RR
Testes de consulta a partir de um cliente: nslookup SQL2000 nslookup SQL2000.seudominio.local nslookup 10.1.2.3 ping -a 10.1.2.3 Os quatro devem apontar para o mesmo par nome⇄IP.
Sufixos DNS: garanta que o cliente adiciona o sufixo do domínio (ex.: seudominio.local). Ajuste em “Lista de Sufixos de Pesquisa DNS” apenas se necessário.

Fallback com NetBIOS, WINS e LMHOSTS

Ambientes com aplicações antigas podem ainda depender de NetBIOS sobre TCP/IP e de WINS para resolver nomes curtos. Em caráter transitório:

Ative NetBIOS sobre TCP/IP no adaptador do Windows 2000 e dos poucos clientes que falam com ele.
Se existir WINS, crie ou verifique o mapeamento do nome do host.
Como último recurso, use LMHOSTS nos clientes: # Em C:\Windows\System32\drivers\etc\lmhosts 10.1.2.3 SQL2000 #PRE #DOM:SEUDOMINIO Em seguida: nbtstat -R nbtstat -c

Mantenha esse fallback apenas enquanto estabiliza o DNS; remova assim que possível.

Firewall e portas essenciais

Garanta que o tráfego flui do cliente até o Windows 2000 sem bloqueios intermediários.

Serviço	Porta/Protocolo	Uso
SQL Server 2000	TCP 1433	Conexão da instância padrão
SQL Browser antigo	UDP 1434	Descoberta de instâncias (se usado)
NetBIOS Name	UDP 137	Resolução NetBIOS
NetBIOS Datagram	UDP 138	Serviços datagrama
NetBIOS Session	TCP 139	Sessão NetBIOS
SMB	TCP 445	Compartilhamentos/SMB (evite expor)

Exemplo de regra no Windows Server 2019 (host cliente ou “jump server” que acessa o SQL 2000):

netsh advfirewall firewall add rule name="SQL2000 TCP 1433" dir=out action=allow protocol=TCP localport=any remoteport=1433 remoteip=10.1.2.3
netsh advfirewall firewall add rule name="SQL2000 UDP 1434" dir=out action=allow protocol=UDP localport=any remoteport=1434 remoteip=10.1.2.3

Compatibilidade de autenticação NTLM e SMB

O Windows 2000, por padrão, pode negociar NTLMv1; já muitos ambientes em 2019 definem políticas para exigir NTLMv2 apenas e/ou desabilitam SMB 1.0. Embora o SQL 2000 por TCP/1433 não dependa de SMB, o logon no domínio e certos acessos auxiliares podem ser afetados.

Opção A (mais segura): configurar o próprio Windows 2000 para usar NTLMv2.

Pela Política de Segurança Local: Políticas Locais → Opções de Segurança → Segurança de rede: Nível de autenticação do Gerenciador de contas LAN → “Enviar respostas NTLMv2 apenas”.
Ou, via Registro (requer reg.exe do Resource Kit ou edição manual): HKEYLOCALMACHINE\System\CurrentControlSet\Control\Lsa LMCompatibilityLevel = 3 (DWORD)

Opção B (rápida, com risco controlado): flexibilizar no DC 2019 apenas para o host legado, por GPO com escopo limitado (OU específica), a política:

Configuração do Computador → Configurações do Windows → Configurações de Segurança → Políticas Locais → Opções de Segurança → Segurança de rede: Nível de autenticação do Gerenciador de contas LAN → “Enviar LM e NTLM – usar NTLMv2 se negociado”.
Considere também não recusar LM/NTLM apenas para esse host e ativar auditoria de NTLM para monitorar uso.

Sobre SMB 1.0: evite reativar globalmente. Se precisar testar acessos a compartilhamentos do Windows 2000, habilite SMB 1.0 somente em uma máquina de administração na zona de legado isolada e restrinja o escopo via firewall.

SQL Server 2000 no servidor Windows 2000

Valide a pilha de rede do SQL.

Server Network Utility (SVRNETCN.EXE, geralmente em ...\Microsoft SQL Server\80\Tools\Binn): habilite TCP/IP, confirme IP/porta, reinicie o serviço SQL.
Client Network Utility (cliconfg.exe) nos clientes: habilite TCP/IP e remova dependência de Named Pipes se não necessária.
Teste básico: telnet SQL2000 1433 osql -E -S SQL2000 -Q "select @@version" osql -U sa -S SQL2000 -Q "select db_name()"

Se o teste com IP (osql -S 10.1.2.3) funciona e por nome não, volte ao bloco de DNS até alinhar a resolução.

Logs e eventos úteis

Windows 2000 (Visualizador de Eventos): System e Application, buscando eventos de Netlogon, DNS Client, LSA.
Windows Server 2019: Security (auditoria de NTLM), DNS Server, e alertas de política de segurança.

Snippets e comandos prontos

PowerShell no DC 2019 para criar A/PTR estáticos

# Ajuste ZoneName, Name e IP
Add-DnsServerResourceRecordA -ZoneName "seudominio.local" -Name "SQL2000" -IPv4Address "10.1.2.3" -TimeToLive 01:00:00
Add-DnsServerResourceRecordPtr -ZoneName "2.1.10.in-addr.arpa" -Name "3" -PtrDomainName "SQL2000.seudominio.local."

Forçar clientes a atualizarem a resolução

ipconfig /flushdns
ipconfig /registerdns
nbtstat -RR

Validar duplicidade de nomes por NetBIOS

nbtstat -a SQL2000
nbtstat -c

Boas práticas de segurança e mitigação de risco

Zona de legado isolada: coloque o Windows 2000 e seus consumidores imediatos em VLAN/segmento próprio, com ACLs explícitas permitindo apenas portas necessárias (1433/1434) e acesso estritamente de hosts autorizados.
GPO de exceção com escopo mínimo: caso precise flexibilizar NTLM/SMB, aplique apenas à OU do Windows 2000. Não herde para o restante do domínio.
Monitoramento: ative auditoria de NTLM no DC 2019 para enxergar quem ainda usa protocolos antigos. Revise periodicamente até zerar dependências.
Backups: antes de qualquer mudança de política, tenha System State do DC e backup consistente do Windows 2000/SQL 2000.

Plano de migração por fases

A restauração do nome resolve o incêndio, mas é vital reduzir dívida técnica.

Inventário e congelamento: mapeie aplicações que consomem o SQL 2000, versões de drivers ODBC/OLE DB e cadeias de conexão.
Estratégia de dados: preferencialmente Export/Import com bcp ou “Gerar scripts com dados”. Em cenários complexos, use um salto intermediário (por exemplo, restaurar em SQL 2008/2012 e, daí, migrar para 2016/2019).
Compatibilidade de código: revise T‑SQL legado, tipos de dados depreciados e DTS. Converta pacotes DTS para SSIS fora do horário crítico.
Virtualização do legado: se a migração não é imediata, virtualize o Windows 2000 e o isole. Aplique microsegmentação e mantenha o menor número de consumidores possível.
Desligamento planejado: após estabilizar a nova instância, redirecione conexões, mantenha período de sombra e desative o legado.

Perguntas frequentes

“Preciso habilitar SMB 1.0 para o SQL 2000 funcionar?” Não. Conexão ao SQL via TCP 1433 não exige SMB. SMB só entra no jogo para compartilhamentos de arquivos e alguns utilitários antigos.

“Posso confiar apenas na entrada de hosts?” Como contingência temporária, sim. Para produção, normalizar o DNS é essencial, principalmente em ambientes com múltiplos clientes.

“NTLMv2 é suportado pelo Windows 2000?” Sim, com configuração adequada (SP4 recomendado). Faça o possível para elevar o legado ao NTLMv2 em vez de rebaixar o domínio inteiro.

Checklist de validação após a correção

Dois clientes distintos resolvem SQL2000 e o FQDN para o mesmo IP.
nslookup retorna A/PTR coerentes; ping -a converte IP para o nome correto.
telnet SQL2000 1433 conecta; osql autentica e retorna @@version.
Logs do DC não registram falhas de NTLM recorrentes para esses hosts.
Registros temporários em hosts e entradas no LMHOSTS removidos.
Firewall permanece com abertura somente necessária e escopo restrito.

Resumo executivo

O sintoma “acessa por IP, não por nome” pós-upgrade do DC tem como causa predominante a quebra de resolução de nomes aliada a políticas de segurança mais rígidas. Corrija DNS, limpe caches, valide portas e ajuste NTLM com escopo mínimo. Em paralelo, caminhe para a migração de SQL 2000/Windows 2000 ou para o quarentenamento do legado, evitando que protocolos inseguros contaminem o restante da infraestrutura.

Apêndice prático

Modelo de mudança rápida

Etapa	Ação	Critério de sucesso
Preparação	Backup de DNS e System State; janela de manutenção curta; contatos de negócio em alerta.	Planos de rollback documentados.
Correção DNS	Criar/ajustar A/PTR; replicação validada; TTL reduzido temporariamente.	`nslookup` consistente em dois DCs diferentes.
Limpeza de cache	`ipconfig /flushdns` nas pontas; reinício do serviço DNS Client se necessário.	Clientes resolvem o nome sem resquícios antigos.
Teste SQL	`osql`/`telnet` por nome; validação da aplicação de negócio.	Transações voltam a operar nominalmente.
Endurecimento controlado	Aplicar NTLMv2 no Windows 2000 ou GPO de exceção mínima; isolamento de rede.	Sem eventos críticos de NTLM e sem impacto colateral.

Políticas típicas a revisar no DC 2019

Política	Localização	Diretriz para legado
LAN Manager authentication level	Computador → Windows → Segurança → Políticas Locais → Opções de Segurança	GPO de exceção na OU do legado, se o Windows 2000 não puder usar NTLMv2.
Microsoft network client: digitally sign communications	Idem	Evitar “Exigir” globalmente para hosts legados (apenas se houver necessidade de SMB para diagnóstico).
Restrict NTLM	Computador → Windows → Configurações de Segurança → Políticas de Segurança de Rede	Whitelist apenas do servidor legado e, se necessário, dos poucos clientes que o acessam.

Erros comuns e como evitar

Registro A apontando para IP antigo: verifique IPs reaproveitados após upgrades.
Vários CNAMEs para o mesmo host: simplifique; prefira um único nome canônico.
DNS público nas estações: remova; apenas DNS interno deve resolver nomes do AD.
TTL muito alto: em mudanças, use TTL baixo temporariamente para acelerar propagação.
SMB 1.0 habilitado globalmente: não faça; use segmentação e máquina jump dedicada.

Conclusão

Com foco em DNS e compatibilidade controlada, é possível restaurar rapidamente a conectividade nominal ao servidor Windows 2000 e estabilizar as aplicações que dependem do SQL 2000. A médio prazo, migre ou isole o legado para reduzir riscos operacionais e de segurança. Este roteiro fornece um caminho claro tanto para o “agora” quanto para o “depois”.