locked
MDT 2013 SP2 Déploiement se bloque au state restore RRS feed

  • Question

  • Bonjour,

    En déployant une image de windows 10 pro 1803 capturée sur MDT 2013 SP2 le processus se bloque à l'étape state restore, l'auto logon ne se fait pas, après avoir introduit le mot de passe il ne se passe plus rien ...

    J'ai sur c:\ un dossier MININT et _SMSTaskSequence avec les logs de déployement

    Pourriez-vous m'indiquer dans quel log je peux trouver la cause de ce blocage ?

    Les images capturées sur l'ancien MDT 2012 et déployées sur le MDT 2013 n'ont pas ce soucis, uniquement les nouvelles images capturées ( sans erreur ) sur le nouveau MDT 2013

    Cordialement


    • Modifié Fredbzf mercredi 2 janvier 2019 12:22
    mercredi 2 janvier 2019 12:21

Réponses

  • Bonjour,

    Lors d'un plantage de capture il y a un mois j'avais mal interprété la solution et en mettant IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE lors de la capture le sysprep ne s'effectuait du coup pas correctement ...

    J'ai restesté avec IMAGE_STATE_COMPLETE pour une nouvelle capture et le déploiement s'effectue sans soucis

    Merci pour le temps accordé et l'aide apportée 

    L'incident est clos

    • Marqué comme réponse Fredbzf vendredi 8 février 2019 10:18
    vendredi 8 février 2019 10:18

Toutes les réponses

  • Bonjour Fredbzf,

    Recherchez le fichier SMSTS.log qui est utilisé pour dépanner des erreurs liées à la Séquence de tâches. Vous pouvez aussi consulter le fichier BDD.log. Les articles suivants peuvent vous aider:
    Troubleshooting Reference for the Microsoft Deployment Toolkit
    MDT 2010 & 2012 – My deployment failed. What and where are logs I should review?

    Cordialement,
    Nina


    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    jeudi 3 janvier 2019 11:44
  • Bonjour,

    Merci pour les infos et désolé du retard

    Voici la différence entre un log d'une machine qui va au bout du déploiement et celui d'une machine qui s'arrête a user state

    Les deux images capturées sont différentes mais la tâche de déploiement est la même

    Le déploiement qui pose soucis s'arrête a ce stade, après reboot pas d'autologin Administrator, en se connectant manuellement le déploiement ne continue pas et pas d'erreur

    The task sequencer log is located at X:\WINDOWS\TEMP\SMSTSLog\SMSTS.LOG.  For task sequence failures, please consult this log. ZTINextPhase 1/3/2019 8:55:40 AM 0 (0x0000)
    Property PHASE is now = STATERESTORE ZTINextPhase 1/3/2019 8:55:40 AM 0 (0x0000)
    ZTINextPhase COMPLETED.  Return Value = 0 ZTINextPhase 1/3/2019 8:55:40 AM 0 (0x0000)
    ZTINextPhase processing completed successfully. ZTINextPhase 1/3/2019 8:55:40 AM 0 (0x0000)
    Command completed, return code = -2147021886 LiteTouch 1/3/2019 8:55:41 AM 0 (0x0000)
    Property LTIDirty is now = FALSE LiteTouch 1/3/2019 8:55:41 AM 0 (0x0000)
    If there is a drive letter defined, make sure we clear it now so we can *force* recalcutation. LiteTouch 1/3/2019 8:55:41 AM 0 (0x0000)
    Property OSDTargetDriveCache is now = DIRTY LiteTouch 1/3/2019 8:55:41 AM 0 (0x0000)
    LTI initiating task sequence-requested reboot. LiteTouch 1/3/2019 8:55:41 AM 0 (0x0000)


    Celui qui ne pose pas de soucis continue après l'autologin administrator et le déploiement s'effectue entièrement sans erreurs

    The task sequencer log is located at X:\WINDOWS\TEMP\SMSTSLog\SMSTS.LOG.  For task sequence failures, please consult this log. ZTINextPhase 1/11/2019 2:28:08 PM 0 (0x0000)
    Property PHASE is now = STATERESTORE ZTINextPhase 1/11/2019 2:28:08 PM 0 (0x0000)
    ZTINextPhase COMPLETED.  Return Value = 0 ZTINextPhase 1/11/2019 2:28:08 PM 0 (0x0000)
    ZTINextPhase processing completed successfully. ZTINextPhase 1/11/2019 2:28:08 PM 0 (0x0000)
    Command completed, return code = -2147021886 LiteTouch 1/11/2019 2:28:08 PM 0 (0x0000)
    Property LTIDirty is now = FALSE LiteTouch 1/11/2019 2:28:08 PM 0 (0x0000)
    If there is a drive letter defined, make sure we clear it now so we can *force* recalcutation. LiteTouch 1/11/2019 2:28:08 PM 0 (0x0000)
    Property OSDTargetDriveCache is now = DIRTY LiteTouch 1/11/2019 2:28:08 PM 0 (0x0000)
    LTI initiating task sequence-requested reboot. LiteTouch 1/11/2019 2:28:08 PM 0 (0x0000)
    Property LogPath is now = C:\MININT\SMSOSD\OSDLOGS LiteTouch 1/11/2019 2:37:07 PM 0 (0x0000)
    Property start is now =  LiteTouch 1/11/2019 2:37:06 PM 0 (0x0000)
    Microsoft Deployment Toolkit version: 6.3.8330.1000 LiteTouch 1/11/2019 2:37:07 PM 0 (0x0000)
    ZTIUtility!GetAllFixedDrives (False) LiteTouch 1/11/2019 2:37:07 PM 0 (0x0000)
    New ZTIDisk : \\SPAL1705001\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0" LiteTouch 1/11/2019 2:37:07 PM 0 (0x0000)
    New ZTIDiskPartition : \\SPAL1705001\root\cimv2:Win32_DiskPartition.DeviceID="Disk #0, Partition #1"    \\SPAL1705001\root\cimv2:Win32_LogicalDisk.DeviceID="C:" LiteTouch 1/11/2019 2:37:07 PM 0 (0x0000)
    New ZTIDisk : \\SPAL1705001\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0" LiteTouch 1/11/2019 2:37:07 PM 0 (0x0000)
    New ZTIDisk : \\SPAL1705001\root\cimv2:Win32_DiskDrive.DeviceID="\\\\.\\PHYSICALDRIVE0" LiteTouch 1/11/2019 2:37:07 PM 0 (0x0000)
    ZTIUtility!GetAllFixedDrives =   C:  LiteTouch 1/11/2019 2:37:07 PM 0 (0x0000)
    etc ...

    Si une personne a une idée de la cause de ce blocage ?

    Cordialement

    jeudi 31 janvier 2019 09:33
  • Bonjour,

    Lors d'un plantage de capture il y a un mois j'avais mal interprété la solution et en mettant IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE lors de la capture le sysprep ne s'effectuait du coup pas correctement ...

    J'ai restesté avec IMAGE_STATE_COMPLETE pour une nouvelle capture et le déploiement s'effectue sans soucis

    Merci pour le temps accordé et l'aide apportée 

    L'incident est clos

    • Marqué comme réponse Fredbzf vendredi 8 février 2019 10:18
    vendredi 8 février 2019 10:18