DC do Windows 2003 para o Windows 2008 R2 DC com o mesmo nome e o mesmo IP

Question

Ambiente = domínio nativo do Windows 2003 com 8 DCs

Eu tenho um antigo controlador de domínio executando 2003, função da CA Enterprise, DHCP, DNS, alguns scripts de GPO que apontam para compartilhamentos e algumas outras funções secundárias. Todos os nossos servidores apontam para ele como seu DNS primário, e há muitas referências ao seu IP ou nome em todo o domínio neste ponto (8 anos ou mais depois). Eu realmente não sinto como mudar manualmente tudo isso, seria uma tarefa muito grande.

Eu quero seguir este guia: link para espero acabar com basicamente uma" atualização in-loco "por assim dizer.

Eu considerei apenas fazer um P2V da caixa, mas realmente não queremos mantê-lo funcionando em 2003 para ser honesto. Eu também considerei usar um CNAME e adicionar um segundo IP (o antigo) mas, novamente, parecia que seria mais limpo usando o link anexado.

Minha pergunta atual:

Alguma dica ou sinais de precaução ao fazer o que o link sugere? Alguém foi por este caminho e tem conselhos sobre como proceder?

    

Answer 1

Esta é uma operação relativamente comum. Ace é um bom recurso de AD, então é muito fácil tomar sua palavra sobre isso para o puro CD.

Ele não gasta muito tempo nos outros serviços, que no seu caso são importantes:

• A CA pode ser um pouco dolorosa porque, para fazer isso corretamente, você precisará atualizar o DC que está em vigor, a menos que esteja disposto a perder todas as informações sobre certificados emitidos (cf. link ). Dependendo do que você usa a CA, isso pode ou não ser OK. Eu certamente já vi isso com a perda da configuração da CA e substituí-la sem um grande impacto no ambiente. Apenas certifique-se de não criar a nova autoridade de certificação até que você já tenha renomeado e promovido a nova máquina, pois não é possível realizar essas operações em uma autoridade de certificação.

• A migração dos dados do DNS ocorrerá magicamente, assumindo que o AD está integrado, caso contrário, você precisará configurar como secundário, alterá-lo para primário e reconfigurar após atribuir o IP antigo ao novo servidor.

• A migração dos dados DHCP é possível e não é ruim se você seguir as instruções (consulte link ). Ace cobre isso na página vinculada.

• A migração dos compartilhamentos envolverá os dados e as permissões. Normalmente você usaria algo como o FSMT ( link ), mas você não está fazendo uma alteração permanente no nome do servidor. Então, basta usar o robocopy para copiar os arquivos para o novo servidor, incluindo permissões (/ copyall) e trazer as definições de compartilhamento (à mão ou algo parecido com link ).

Há um tópico no ArsTechnica ( link ) sobre isso, que recomenda o uso de um "servidor de swing". Eu fiz isso nos casos de migração do SBS, mas acredito que seja um exagero no seu caso, já que você tem muitos DCs existentes.

Você não disse se o DNS e o DHCP existem em outros servidores também ou apenas neste; se apenas neste, em primeiro lugar, ruim por causa do ponto único de falha, etc., mas também significa que você está olhando para um tempo de inatividade muito visível para os usuários finais enquanto você está fazendo isso, caso em que um servidor de swing pode faz sentido (dois blips menores em vez de um blip maior).

    

Answer 2

Ótimo material. Tudo parece bem e @MikeBaz é bom apontar a CA, que a ACE não menciona, mas é comum estar em um DC. Menos "tudo ou nada" é simplesmente ir devagar e mover cada serviço para um novo local, como se fosse o seu próprio miniprojeto. O DNS é provavelmente o único em que você precisa se preocupar com o IP (supondo que você não tenha o WINS Server nele).

Sua rede deve ser projetada para que os AD DCs sejam avariados, pois nenhuma falha DC afetaria serviços de rede como DC, DNS, DHCP, CA, netlogon, etc. Eu recomendo a substituição deste servidor como uma chance de melhorar seu design de cada um deles para ser altamente disponível. Uma boa notícia é que cada um pode estar com o mínimo de esforço, tornando a substituição do NEXT DC muito mais fácil.

Para scripts, se eles estão apontando / executando do netlogon que está em todos os DCs (e replicados entre eles), então qualquer nome de servidor nos scripts não deve apontar para \\ old-dc \ netlogon, mas sim \\ domainname.com \ netlogon, que é a maneira preferida para que os clientes possam pegar scripts e suportar arquivos de seu DC mais próximo. Se você estiver armazenando arquivos em outros compartilhamentos em scripts / GPOs, considere usar o DFS + DFSR, que é fácil de usar, e impede que uma única interrupção de compartilhamento de arquivos impeça o acesso ao arquivo.

Para o DNS, com muitos DCs em sua rede, você deve ter todos os clientes e servidores configurados para pelo menos dois servidores DNS. Se for esse o caso, derrubar uma CD não é uma preocupação durante a migração. Para clientes DHCP basta alterar o escopo DHCP para um host DC / DNS diferente, o que você pode fazer agora. Para servidores com IPs estáticos, você pode usar um script ou atribua o jr. Administre a tarefa para garantir manualmente que todos tenham as entradas DNS apropriadas. O DNS é a força vital do AD e, quando possível, eu coloco 3+ entradas de DNS em NICs de servidor (NUNCA menos de 2), por causa de casos como este, nos quais os servidores DNS precisam ser substituídos ou receber novos IPs.