Prática recomendada para descomissionar um controlador de domínio que também é um servidor DNS?

Question

Existem duas escolas de pensamento para o processo de descomissionamento dos Controladores de Domínio do Active Directory que são muito usados como servidores DNS.

1. Adicione o endereço IP do DC de saída a um novo controlador de domínio e verifique se o DNS está escutando nesse endereço.

2. Demote o DC antigo, deixe a função DNS nele e configure um encaminhador DNS global para o novo servidor.

Obviamente, ambos são stopgaps até que todos os servidores e dispositivos tenham sido configurados para usar o endereço IP primário de um novo servidor, mas às vezes esse período de transição pode ser relativamente longo, dependendo do tamanho do ambiente.

Existe uma boa prática clara aqui?

    

Answer 1

Estou hesitante em responder, porque acho que isso é mais uma questão de "discussão" do que uma pergunta estritamente Q & A ... mas é um sábado preguiçoso, então vou de qualquer maneira.

Is there a clear cut best practice here?

Não. (Porra, talvez esta seja uma resposta fácil a todos ...)

A Microsoft fornece orientação binária muito genérica, fácil Googleable sobre como rebaixar controladores de domínio e realizar migrações de AD e DNS, mas não vou me incomodar em vincular a eles nem vou fingir que eles abordam sua pergunta específica, porque a Microsoft obviamente não pode documentar cada caso específico para o ambiente de cada organização diferente.

Assim, administradores de sistemas / engenheiros como nós são deixados para preencher as lacunas com nossa própria experiência e experiência, onde a Microsoft não escreveu um script especial apenas para nós, e é isso que nos torna valiosos.

Posso dar um exemplo de algo que fizemos para resolver esse problema, pois também trabalho em ambientes de abrangência global com dezenas ou mais controladores de domínio, florestas de AD distintas que coabitam nas mesmas redes, não-Windows dispositivos que também consomem serviços de DNS dos mesmos DCs, etc. Movendo-se para novos datacenters e saindo dos antigos, precisando migrar para um novo hardware ou novas versões do sistema operacional, e a política empresarial antiga é o motivo pelo qual precisaríamos descomissionar controladores de domínio que ainda estavam sendo usados. E quando você tem várias organizações heterogêneas atualmente usando esses servidores DC / DNS, geralmente é um processo cansativo e demorado de reconfigurar cada cliente (muitos dos quais podem não estar sob o seu controle) antes de desatribuir o controlador de domínio, envolvendo gerentes de projeto, tickets para várias outras equipes que podem levar dias ou semanas para serem trabalhadas, etc.

É por isso que eu digo que não acho que alguém possa lhe dar a resposta a essa pergunta. Existem mil maneiras de fazer isso e algumas serão melhores que outras, dependendo da estrutura e das necessidades da sua organização.

Algo que fizemos para enfrentar esse problema é tornar VIP para cada datacenter e agrupar todos os controladores de domínio naquele datacenter por trás desse VIP. (Este VIP é para o serviço DNS somente por razões óbvias, não estou falando sobre balanceamento de carga Kerberos e LDAP.) Dessa forma, os clientes podem ser configurados para usar esse VIP para o seu resolvedor de DNS, e estamos livres para adicionar e remover controladores de domínio por trás desse VIP sempre que quisermos.

Mas você não está na frente do problema ... então, dadas as opções que você forneceu:

1. Add the IP address of the outgoing DC to a new DC and ensure that DNS is listening on that address.

2. Demote the old DC, leave the DNS role on it, and configure a global DNS forwarder to your new server.

Eu escolheria a opção nº 1, porque seu objetivo é desativar o servidor antigo o mais rápido possível, e a opção nº 2 não ajuda você a se livrar do servidor antigo. Com a opção 2, a existência do servidor ainda é necessária. Nem eu iria com a sugestão de Mathias R. Jessen de zonas de stub, porque, novamente, você ainda tem que deixar o servidor antigo no lugar e em serviço, o que não é propício para o seu objetivo final.

Com a opção 1, por mais feia que seja, você pode aposentar o servidor antigo, reivindicar economia de custos para sua empresa, evitar ter que pagar outro mês de aluguel nesse datacenter e receber um prêmio por ser um funcionário tão bom .

Editar: Pensando em nosso bate-papo um pouco mais, eu acho que posso ter projetado meus próprios requisitos para você, porque eu tenho os requisitos de puxar o plug ASAP em algumas coisas agora, então isso estava fresco em minha mente. Parece que você não tem um requisito imediato para desligar o servidor o mais rápido possível.

Dito isso, não estou mudando minha sugestão, pois ainda preferiria. Tacking o IP extra para um controlador de domínio existente funcionou bem para mim no passado em cenários muito semelhantes, e eu prefiro que do que ter um apêndice de vestígio estranho de um servidor sentado lá por um período de tempo indeterminado.

    

Answer 2

O caminho para o inferno do Active Directory é pavimentado com bandagens temporárias. Atribuir o endereço IP de um servidor DNS decomissionado ou não descomissionado ao seu novo servidor DC e DNS é uma faixa temporária.

Como @gravyface observou nos comentários, no cenário ideal você alteraria todos os escopos DHCP e configurações estáticas para atualizar a preferência DNS do cliente para o novo IP em vez do antigo, antes de você descomissionar totalmente o antigo DC.

Eu entendo que a certeza de que todos os clientes foram reconfigurados não é necessariamente possível a tempo, mas eu certamente considero a opção número 2 (encaminhando o namespace inteiro) como a opção menos questionável aqui.

Além de permitir que o servidor antigo encaminhasse solicitações mesmo depois de rebaixá-lo, eu recomendaria habilitar o Log de depuração para solicitações de entrada no servidor DNS - isso torna um pouco mais fácil avaliar não apenas os clientes se ainda estão apontando para o servidor DNS antigo, mas também identificando esses clientes.

Dito isso, acho que você perdeu a terceira opção óbvia: Zonas de stub !

• Rebaixar o DC, manter a função de DNS e adicionar todas as zonas anteriormente mantidas como zonas de stub - encaminhar todo o resto. Dessa forma, sua obrigatoriedade de que os clientes realmente entrem em contato com os controladores de domínio que eles devem usar, em vez de fazer o trabalho para eles