Atualizando do servidor muito antigo do AD (servidor 2000) para o Server 2012 R2 Essentials

1

Atualmente, temos um sistema do Active Directory com base em dois servidores Windows Server 2000. Gostaríamos de substituir isso por um servidor AD / file baseado no Server 2012 R2 Essentials.

Como não podemos simplesmente adicionar o sistema 2012 como um servidor AD ao sistema antigo, planejamos fazer isso da seguinte maneira. É este o melhor caminho, e há algo que devemos procurar?

S1 = Controlador de domínio primário do servidor 2000.

S2 = Controlador de domínio secundário do servidor 2000.

T1 = Sistema Temporário do Servidor 2008.

F1 = sistema do Final Server 2012.

  1. Atualize o compatível S1 para 2008, usando adprep (forestprep & domainprep) para permitir que o DC 2008 entre no domínio. (FEITO).
  2. Ativar o servidor temporário 2008 - DONE (T1).
  3. Promova T1 para DC - FEITO.
  4. Tornar mestre em T1.
  5. Demote todos os outros DCs existentes (S1 e S2).
  6. Atualize a floresta para o nível funcional de 2003/2008.
  7. promova F1 para DC.
  8. Torne o mestre de F1.
  9. Demote o servidor temporário T1.
  10. Remova o servidor temporário T1 do domínio / existência.
  11. Execute o assistente de instalação do Essentials 2012 na F1.

Isso parece razoável, ou existe uma maneira melhor? Além disso, há alguma coisa que devemos procurar ou que podemos usar para testar as coisas à medida que avançamos.

Finalmente, acredito que há um limite de 21 dias em quanto tempo o servidor 2008 pode estar em um sistema AD com mais de uma máquina. Esse limite começa quando instalamos o sistema operacional ou o adicionamos a um domínio ou quando fazemos dele um servidor AD pela primeira vez.

    
por Simon Callan 06.01.2017 / 12:09

2 respostas

0

Observe que você não pode voltar facilmente no nível da função depois de fazer isso, apenas a partir de uma restauração de backup. Quando fiz isso, desliguei um dos CDs até ter 100% de certeza de que tudo estava bem no nível de função atual. Ir de 2003 a 2008 é aquele que parece ser o maior risco, porque alguns programas antigos podem ter problemas. (Nós não temos nenhum, mas pelo que eu li faz mais alterações)

    
por 06.01.2017 / 17:19
0

Estes são geralmente itens de sistema operacional e domínio. Eu não tenho nenhuma experiência do SBS aka Essentials.

Faça backups antes de começar e ao longo do caminho para que, se as coisas quebrarem, você possa voltar a um bom estado conhecido.

O FRS não está mais presente em 2012. Adicione a etapa 6B para migrar a replicação Sysvol do NTFRS para o DFSR link

Se o seu corntroller de domínio também for o seu servidor DNS, você precisará atualizar o endereço do resolvedor de DNS nos clientes. Mais fácil se tudo for DHCP, mais difícil se muitos clientes tiverem endereços estáticos. De qualquer forma, você pode querer atribuir todos os possíveis endereços de DC como resolvedores antes de começar e, em seguida, remover os endereços aposentados quando terminar.

Falando nisso, você parece estar começando com 2 CDs e terminando com apenas 1. Nunca é uma boa idéia. Sempre tem 2 CDs para redundância.

Você tem algum outro sistema antigo que esteja gastando os controladores de domínio para fornecer criptografia DES? Seus DCs de 2008 e 2012 não usarão mais DES por padrão. Você pode ligá-lo novamente, mas não deveria porque o DES foi mostrado como vulnerável.

Que tipo de intervalo de tempo você planeja fazer o trabalho (horas / dias / semanas)?
A razão pela qual eu pergunto entra em alguns dos detalhes menos freqüentemente falados sobre o Kerberos ...
A conta KRBTGT é uma conta especial usada para assinar todos os tickets do Kerberos no domínio. Cada alteração no nível funcional do domínio também altera a senha na conta KRBTGT. A duração padrão do ticket do Kerberos é de 10 horas. O AD armazena o valor atual e anterior dessa senha para impedir a interrupção do serviço durante as alterações. Mas se essa senha mudar mais de uma vez em 10 horas, você terá problemas com tickets inválidos do Kerberos. Opções:

  1. Aguarde 10 horas entre as alterações no DFL
  2. Modifique a política de domínio para emitir tíquetes Kerberos com um tempo de vida menor ( link )

Se você não esperar ou não mudar a vida útil, esteja preparado para os problemas que exigirão reinicializações e / ou logouts para computadores e usuários obterem novos tickets.

    
por 06.01.2017 / 19:38