Sou um novato completo com o MDT 2012, mas tive muita sorte em obter uma implantação para o Server 2008 R2.
Eu tenho um sistema de referência, e faço um sysprep e capture muito usando a sequência de tarefas do modelo sem alterações.
Minha implantação tem algumas instalações de aplicativos e outros itens de configuração, mas nada muito exótico.
Meu problema é este: durante a implantação, depois de aplicar o sistema a partir do WinPE, executo a reinicialização final. Neste ponto, a ação esperada é que um logon automático ocorra e que a conta de Administrador local execute c: \ Litetouch.vbs, que faz algumas limpezas finais e algumas tarefas que exigem que o sistema de destino esteja em execução.
Isso não está acontecendo no meu sistema. E uma olhada no registro mostra que o material de autologon não foi configurado, então isso nunca acontecerá. Não é uma questão de ter uma conta incorreta ou uma contagem de 0, nenhuma das chaves de registro de logon automático está presente.
Na tentativa de resolver isso (acredito que funcionou quando comecei!) Eu limpei minha implantação para um par de seqüências de tarefas que não tinham nenhuma personalização na captura ou seqüências de tarefas de implantação e ainda sem sorte. Então, acredito que algo mudou no meu sistema de referência - mas infelizmente não consigo reverter.
O que está me deixando um pouco maluco é que não posso dizer quando a informação de logon automático deve ser inserida no registro. Existe um código em Litetouch.wsf que parece fazê-lo, na função PopulateAutoAdminLogon, mas não consigo criar um cenário no qual essa função seja chamada. Eu estou supondo que, talvez, o sysprep o faça ao criar o WIM, mas não consigo encontrar boas informações sobre isso.
Eu fiz muita pesquisa sobre isso e, infelizmente, o espaço de resposta é cheio de pessoas que têm um problema semelhante, mas completamente diferente - eles querem que o sistema implantado faça um autologon e, após a implantação, o sistema é ativado com a tela de logon, em vez de fazer o que eles querem. Eu vi algumas pessoas postarem problemas semelhantes aos meus, mas ninguém recebeu uma resposta.
Em suma: ao implantar um sistema usando o MDT 2012, em que ponto os itens de logon de unattend.xml serão armazenados no registro para uso após a restauração / reinicialização de estado na sequência de tarefas? E o que pode dar errado com isso?Meu problema estava sendo causado por uma falha do sysprep - a contagem de rearmamentos na minha imagem silenciosamente subiu para 2 devido a descuido.
O que é estranho é que uma falha tão grande no processo não gerou sinais vermelhos óbvios. Eu realmente tive que cavar para encontrar o problema. O fracasso do sysprep caiu em cascata em uma dezena de outros problemas que eram todos sinais vermelhos. Trabalhando para trás, finalmente desisti da resposta.
Se você tiver SkipFinalSummary = YES no seu arquivo customsettings.ini (Regras), não verá o assistente de resumo que mostra que a sequência de tarefas foi concluída com êxito. Ele só será exibido se a sequência de tarefas falhar. Os scripts do Lite Touch limpam a máquina quando a sequência de tarefas termina, incluindo a remoção das configurações de logon automático. Isso é explicado no blog do TechNet de Michael Niehaus “ MDT 2010 Novo recurso # 15: ações de finalização ”.
Se sua sequência de tarefas estiver falhando e não estiver mostrando o assistente de resumo, um bom local para começar a solucionar esse problema é verificar os arquivos de log para ver se há um motivo pelo qual a implementação falhou e quais erros podem ter ocorrido. O artigo do TechNet “ Noções básicas sobre falhas e arquivos de log ” deve ser de grande ajuda para isso.
Por fim, muitos artigos e vídeos que ajudarão com o MDT podem ser encontrados no Entregar e implantar o Windows 7 página da série Springboard no TechNet.
O MDT armazena todas essas informações no arquivo de resposta. Se a execução da sequência de tarefas não conseguir copiar essas informações para o seu arquivo de imagem, tente reconstruir sua sequência de tarefas, a incrível quantidade de problemas no MDT pode ser resolvida simplesmente recriando uma nova sequência de tarefas. Verifique o BDD.log, sempre há pistas nesse arquivo.