none
MDT 2013 : Problème fichier de réponse (Unattend.xml) ou séquence de tâche RRS feed

  • Discussion générale

  • Bonjour,

    Je travaille actuellement sur la migration de notre parc Windows 7 Pro en Windows 10 Pro : il s'agit donc de passer en W10 les postes W7 actuellement en fonctionnement.
    Il s'agit donc d'une mise à niveau ou Upgrade, avec récupération des profils et données utilisateur.

    Pour cela, MDT a été mis en place sur notre serveur WDS (2012 R2), il s'agit de MDT 2013 Update 2 (dernière version).
    La version de W10 que nous souhaitons déployer et que nous avons récupérée est la dernière (Pro x64 v. 1511).

    MDT est bien configuré (customsettings.ini, bootstrap.ini, task sequence "Standard Client Upgrade) et fonctionne : le lancement du script LiteTouch.vbs depuis un poste permet de bien redescendre l'image wim présente dans MDT.
    Mon problème est le suivant : le fichier de réponse que j'ai crée associé à ma task sequence (Unattend.xml) ne s'exécute pas a priori.
    La migration de W7 vers W10 fonctionne parfaitement, sauf en ce qui concerne les paramètres du fichier de réponse qui ne s'appliquent pas.
    Je suis sûr de mon fichier de réponse, et je pense donc qu'il n'est pas "lu" au moment de l'install. C'est d'autant plus étonnant que la task sequence s'exécute (si je mets le paramètre à No sur SkipTaskSequence dans le customsettings, j'ai bien le choix de la task sequence). 
    Cela ressemble à un problème ou un bug MDT. Par exemple, en mettant le paramètre à Yes, l'install fonctionne parfaitement. En le mettant sur No, l'install plante à la fin à 100%, je suis obligé de forcer le redémarrage du poste puis celui-ci reboote en permanence (install corrompue).

    A moins qu'il y ait un paramètre de MDT que je ne connais pas pour faire reconnaître le fichier de réponse?

    Toute aide ou conseil à ce sujet serait apprécié...
    Merci d'avance.

    dimanche 21 février 2016 17:48

Toutes les réponses

  • L'unattend s'applique après la descente de la wim. Possible de voir les logs ?
    dimanche 21 février 2016 18:34
  • Merci de la réponse : je regarde pour les logs dans le courant de la semaine et je répondrai plus longuement.
    dimanche 21 février 2016 23:09
  • Bonjour,

    Utilise tu le fichier unattend.xml de la séquence de tache ou un autre que tu as créé ? Et quels sont les paramètres qui ne s'applique pas dans ton fichier ?


    signatureforums

    lundi 22 février 2016 17:11
    Modérateur
  • Désolé pour le délai de réponse, je n'ai pas pu le faire plus tôt.

    Concernant les logs, il n'y a à ma connaissance que le fichier "Audit" dans le répertoire MDT, qui ne 
    dit pas grand chose. De plus à la fin de l'install, la fenêtre MDT indique "Success : Operating system 
    deployment completed successfully" avec 0 erreurs.

    Yannick : oui, j'utilise le fichier Unattend de la task sequence, je le modifie toujours en l'éditant 
    depuis la task sequence (Propriétés > OS Info > Edit Unattend.xml).
    Aucun paramètre ne s'applique, ce qui n'est pas normal. Tout me semble bon, et j'ai un peu l'habitude 
    des fichiers de réponse (déjà fait pour nos masters W7 et ils fonctionnent très bien).
    Par exemple je te mets quelques uns des paramètres que j'ai mis.

    Modification info OEM (Microsoft Windows Shell Setup > OOBE passe):
    <Model>Tronc Commun W7.2011.05 mis à jour vers W10</Model>

    (Ce paramètre d'info OEM par exemple, je l'avais déjà mis pour nos masters W7 (même endroit dans le 
    fichier de réponse) et il s'exécute parfaitement pour les redescentes d'images W7.)

    Commande Powershell pour accès réseau (en RunSynchronousCommand : Microsoft Windows Deployment > passe Specialize):
    -<RunSynchronousCommand wcm:action="add">
    <Description>Donne accès réseau</Description>
    <Order>5</Order>
    <Path>cmd /c powershell.exe Set-SmbClientConfiguration -RequireSecuritySignature $true</Path>

    Modification d'une clé de registre pour test (idem que précédent):
    -<RunSynchronousCommand wcm:action="add">
    <Description>WaitToKillServiceTimeOut</Description>
    <Order>6</Order>
    <Path>cmd /c reg add HKLM\System\CurrentControlSet\Control /v WaitToKillServiceTimeOut /t REG_SZ /d 
    1000 /f</Path>

    J'ai même essayé de passer un batch que j'ai fait (qui fonctionne lancé manuellement) en FirstLogonCommands (Microsoft Windows Shell Setup > OOBE passe), il ne s'exécute pas:
    -<FirstLogonCommands>
    -<SynchronousCommand wcm:action="add">
    <CommandLine>C:\Sources\W10.bat</CommandLine>
    <Description>Lance W10.bat</Description>
    <Order>2</Order>
    </SynchronousCommand>
    </FirstLogonCommands>


    vendredi 26 février 2016 18:22