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

Há duas escolas de pensamento para o processo de descomissionamento de controladores de domínio do Active Directory que são muito usadas como servidores DNS.

Adicione o endereço IP do controlador de domínio de saída a um novo controlador de domínio e verifique se o DNS está escutando nesse endereço.
Rebaixe o controlador de domínio antigo, deixe a função DNS nele e configure um encaminhador de DNS global para o seu novo servidor.

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

Existe uma prática recomendada clara aqui?

windows domain-name-system active-directory

— MDMarra
fonte

Ou um terceiro, altere todas / todas as referências ao antigo servidor DNS na rede?

— Gravyface

É claro que esse é o objetivo final, e foi por isso que o chamei de paliativo. Mas em alguns ambientes muito grandes, isso não é uma opção, se você deseja que seja feito em tempo hábil. Eu disse:

Obviously, both are stopgaps until all servers and devices have been configured to use the primary IP address of a new server, but sometimes that transition period can be relatively long depending on the size of the environment.

certo?

— precisa saber é o seguinte

semântica ... você está certo, mas eu prefiro alterar sistematicamente a configuração DNS dos dispositivos, monitorar a atividade, começar com escopos DHCP e depois trabalhar nos servidores na ordem do menos importante ao importante (servidores membros para outros controladores de domínio) ) que personifique o servidor antigo e / ou deixe-o por mais tempo que o necessário.

— Gravyface

É claro que essa é a melhor opção, mas quando digo um ambiente "muito grande", estou falando de uma infraestrutura distribuída globalmente com mais de 300 DCs e muitas equipes de TI diferentes, gerenciando diferentes componentes da infraestrutura. Às vezes, realmente não é possível garantir que você tenha todos os dispositivos no primeiro balanço durante uma atualização.

— precisa saber é o seguinte

@gravyface Você não está errado, mas em ambientes grandes e geograficamente dispersos com gerenciamento descentralizado de diferentes componentes, nem sempre é possível concordar com um plano de jogo, colocar todos em linha e trabalhar em direção a um objetivo comum. Às vezes você apenas tem que tomar uma decisão para avançar e encontrar uma solução ou uma solução para garantir que ele tem tão poucas implicações para os outros quanto possível

— Mathias R. Jessen

Respostas:

Eu hesito em responder porque acho que essa é mais uma questão de "discussão" do que uma pergunta estritamente de perguntas e respostas ... mas é uma manhã de sábado preguiçosa, então eu o farei de qualquer maneira.

Existe uma prática recomendada clara aqui?

Não. (Droga, talvez essa tenha sido uma resposta fácil a todos ...)

A Microsoft fornece uma orientação Bingable muito genérica e facilmente ~~Googleable~~ sobre como rebaixar controladores de domínio e executar migrações de AD e DNS, mas não vou me incomodar em vincular a eles nem pretendo que eles abordem sua pergunta específica, porque a Microsoft obviamente não pode documentar todos os casos específicos para cada ambiente da organização.

Portanto, administradores / engenheiros de sistemas como nós são deixados a 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 mesmo problema, já que também trabalho em ambientes de abrangência mundial com dezenas ou mais controladores de domínio, florestas diferentes do AD que coabitam nas mesmas redes, dispositivos não Windows também consomem Serviços DNS dos mesmos controladores de domínio, etc. Mudar para novos datacenters e sair dos antigos, precisar migrar para um novo hardware ou novas versões de sistemas operacionais e políticas comerciais antigas e simples são todos os possíveis motivos para descomissionar controladores de domínio que potencialmente ainda estavam sendo usados. E quando você tem várias organizações heterogêneas atualmente usando esses servidores DC / DNS, geralmente é um processo árduo e prolongado de reconfigurar todos os clientes (muitos dos quais podem não estar sob seu controle) antes de descomissionar o controlador de domínio, envolvendo gerentes de projeto,

Então é por isso que eu digo que eu não acho que ninguém pode dar-lhe a resposta a esta pergunta. Existem milhares de maneiras pelas quais você pode fazer isso e algumas serão melhores que outras, dependendo da estrutura e das necessidades da sua organização.

Algo que fizemos para resolver esse problema é criar um VIP para cada datacenter e agrupar todos os controladores de domínio nesse datacenter atrás desse VIP. (Este VIP é para o serviço DNS única , por razões óbvias, eu estou não falar sobre o balanceamento de carga Kerberos e LDAP.) Dessa forma, os clientes podem ser configurados para usar esse VIP para a sua resolução de DNS, e somos livres para adicionar e tirar controladores de domínio por trás desse VIP quando e como quisermos.

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

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

Rebaixe o controlador de domínio antigo, deixe a função DNS nele e configure um encaminhador de DNS global para o seu novo servidor.

Eu escolheria a opção 1, porque seu objetivo é descomissionar o servidor antigo o mais rápido possível, e a opção 2 não ajuda você a se livrar do servidor antigo. Com a opção 2, a existência do servidor ainda é necessária. Também não concordaria com a sugestão de zonas de stub de Mathias R. Jessen, porque, novamente, você ainda precisa deixar o servidor antigo no local e no serviço, o que não é propício ao seu objetivo final.

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

Edit: Pensando um pouco mais em nosso bate-papo, acho que posso ter projetado meus próprios requisitos para você, porque tenho requisitos o mais rápido possível em algumas coisas agora, de modo que 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 isto, não estou mudando minha sugestão, pois ainda a preferiria. Aderir o IP extra a um controlador de domínio existente funcionou bem para mim no passado em cenários muito semelhantes, e eu prefiro que ter um apêndice vestigial estranho de um servidor sentado lá por um período indeterminado de tempo.

— Ryan Ries
fonte

Eu acho que isso se enquadra good subjectiveno post Subjetivo Bom, Subjetivo Ruim que definiu a regra "questões para discussão". Pelo menos eu espero que sim.

— MDMarra

@MDMarra Eu concordo. +1 para uma pergunta interessante e instigante. :)

— Ryan Ries

Além disso, apenas para o registro, eu normalmente fazer o oposto de sua sugestão: D

— MDMarra

O caminho para o inferno do Active Directory é pavimentado com ataduras temporárias. Atribuir o endereço IP de um servidor DNS descomissionado ou a ser descomissionado ao seu novo servidor DC e DNS é um curativo temporário.

Como o @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 de DNS do cliente para o novo IP, em vez do antigo, antes de descomissionar completamente o antigo controlador de domínio.

Entendo que garantir que todos os clientes tenham sido reconfigurados não seja necessariamente possível a tempo, mas certamente considero a opção número 2 (encaminhamento de todo o espaço para nome) como a opção menos questionável aqui.

Além de permitir que o servidor antigo encaminhe solicitações mesmo depois de rebaixá-lo, eu recomendaria ativar o Log de Depuração para solicitações recebidas no servidor DNS - isso facilita um pouco a avaliação, não apenas se os clientes ainda estão apontando para o servidor DNS antigo, mas também identificação dos referidos clientes.

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

Rebaixe o controlador de domínio, mantenha a função DNS e adicione todas as zonas que ele mantinha anteriormente como zonas de stub - encaminhe todo o resto. Dessa forma, você impõe aos clientes que realmente entrem em contato com os Controladores de Domínio que eles deveriam usar, em vez de fazer o trabalho por eles

— Mathias R. Jessen
fonte