Reiniciando uma VM de um arquivo VHD diferente (mas uma cópia da antiga)

Question

Gostaria de saber se alguém fez isso e, posteriormente, se deparou com algum problema ou se, com base no que descrevi, qualquer pessoa poderia sugerir tipos de problemas que podem ocorrer:

Eu tenho o Windows 2008 R2 Datacenter como meu host do Hyper-v e uma VM guest do Ent 2008 do Windows 2008 R2 em execução nele.

Antes de uma grande atualização, eu tinha salvo uma cópia do arquivo VHD do convidado (essa era a unidade C: na VM guest). Este não foi um instantâneo, apenas uma cópia / colagem do arquivo VHD.

Após algumas dificuldades e frustrações com a atualização do SQL Server 2012, decidi ignorar a solução de problemas (tive uma pequena janela de manutenção para trabalhar) e, em vez disso, interrompi a VM. Em seguida, alterei o arquivo VHD para a cópia anterior que eu havia salvo anteriormente.

A VM inicializou, mas não foi reconhecida pelo controlador de domínio. Eu removi e adicionei novamente ao domínio e depois sem grandes problemas. Concluí o upgrade sem problemas anteriores & instalou o Windows Updates também sem problemas.

Isso é considerado uma prática ruim? Posso manter essa VM como está ou preciso reconstruí-la do zero para evitar anomalias no SO? Se você fosse um lead sysadmin & essa era uma caixa de produção, você permitiria? Obrigado

    

Answer 1

Antes de mais nada, alguns conceitos básicos sobre máquinas / domínios do Windows que você precisa conhecer (e podem ou não saber):

1. Os computadores são entidades de segurança como os usuários

2. Os nomes são apenas referências amigas do homem a um SID subjacente

3. Os computadores são autenticados no domínio na inicialização

4. Contas de computadores também têm senha (que muda a cada 30 dias por padrão)

Basicamente, o que aconteceu quando você bloqueou o antigo VHD em sua máquina é (eu estou apostando), a senha local da conta do computador não correspondia à senha que a DC tinha para a conta do computador, porque a senha foi alterada em algum momento entre o backup que você fez e a hora em que você o restaurou. Como resultado, o controlador de domínio não deixaria o computador autenticar e o erro que você vê é uma relação de confiança com falha.

Isso se baseia em uma suposição ou duas, mais notavelmente que seu backup e a máquina que falhou não tinham SIDs diferentes, o que também quebraria a confiança do domínio. Isso geralmente acontece quando você renomeia um computador ou associa um computador a um domínio com o mesmo nome de uma conta existente. O computador recém-renomeado tentará autenticar com seu novo SID, mas o nome mapeia para o antigo SID, portanto, quando o AD verifica, os SIDs não correspondem e a autenticação falha.

Então, de qualquer forma, você basicamente interrompeu a autenticação entre sua VM e o domínio quando "restaurou" o backup antigo. Eu confio que você pode ver porque isso é ruim. (É menos ruim se fosse apenas a senha da máquina, e não um SID diferente, que vale a pena mencionar).

Por que é "má prática" fazer o que você fez é subjetivo e terá respostas diferentes (ou diferentes preocupações específicas) de diferentes administradores, mas minha resposta seria basicamente que é uma prática ruim porque há uma maneira melhor de fazer isso não quebra a autenticação de domínio ou adiciona complexidade e incógnitas à mistura. (Qual era a idade do backup? O que mudou no sistema entre então e agora? O que está confiando nessas mudanças que poderiam quebrar ou causar monstruosamente difícil solucionar problemas? Etc.) Também é uma prática ruim porque parece que você não tem , backups efetivos ou um processo rápido para restaurar a partir de um backup [real] se / quando necessário. Isso é muito ruim, por razões que eu espero que você não precise de esclarecimentos.

Dito tudo isso, parece que você está relativamente seguro. (Assumindo, é claro, que o backup antigo não está faltando um monte de dados SQL, ou tem uma versão antiga de algo instalado, ou qualquer coisa básica como essa.) A senha diferente da conta do computador não será referenciada em lugar algum e geralmente O SID completo do computador também não será mencionado por muito fora do AD, então alterá-lo não deve causar problemas. (Mas, como qualquer administrador que tenha estado no quarteirão uma ou duas vezes, vi coisas que fariam seu sangue coagular e resultaria em minha qualificação, que de outra forma seriam declarações absolutas.)

Espero que isso seja útil.

    

Answer 2

Os membros do domínio sincronizam credenciais de associação de domínio periodicamente. Quando um sistema está offline por um período prolongado, o domínio não reconhece mais as credenciais do sistema. Contanto que você não renomeie o sistema, você pode entrar novamente no domínio sem uma nota de problema, você também pode tentar NLTEST /SC_RESET:domain_name\DC_name ao invés de reingressar no domínio

    

Answer 3

O problema é fazer isso com um controlador de domínio. Ele tem um banco de dados com números exclusivos que são compartilhados e mantidos em sincronia com os outros controladores de domínio. De repente, reverter um deles para o antigo fora dos números de sincronização é uma má ideia.

Editar: Talvez eu tenha sido um pouco breve. Deixe-me adicionar mais três coisas:

1. Como o único caso em que você restauraria um controlador de domínio da imagem de backup é quando todos os controladores de domínio são perdidos, restaurações autoritativas não devem ser necessárias. Fonte: Microsoft technet .
2. Um banco de dados geralmente tem necessidades específicas. Se é um DB com uso significativo, então você quer ajustar todo o servidor para ele. Isso inclui CPU, RAM (tamanho de RAM versus conjunto de dados usado ativamente) e unidades. (Veja o SF Quais são os diferentes níveis de RAID amplamente utilizados e quando devo considerá-los? "> resposta canônica no RAID para a última parte. Parece estar fazendo referência a isso bastante ultimamente).
3. Um controlador de domínio não precisa de muito, mas você quer que ele seja rápido. O servidor novo mais lento que você pode comprar atm fará muito bem, mas tente executá-lo como tarefa única em um servidor. Mesmo se você precisar comprar um novo servidor para isso. Outros servidores podem ser reinicializados ou desativados, mas em uma rede ms você deseja pelo menos um controlador de domínio que tenha recursos para responder rapidamente.