none
MDT 2012 U1 task sequence just stops, never finishes RRS feed

  • Question

  • I'm having a problem where a ts gets to the State Restore phase but then just stops, it doesn't throw any errors, doesn't run any of my custom scripts in the State Restore phase and never brings me to the finish screen though I'm using SkipFinalSummary=NO in customsettings.ini.  This ts is deploying Win7 x86.

    I had specified the SLShare property set in customisettings.ini but no logs were ending up on the server, I'm assuming because the deployment wasn't finishing, so I've now added the SLShareDynamicLogging property and a bdd.log appeared there.  I've opened it with trace32, no red or yellow lines appear but the last few lines of the log are:

    Property PHASE is now = STATERESTORE ZTINextPhase 16-04-2014 2:36:15 PM 0 (0x0000)
    ZTINextPhase COMPLETED.  Return Value = 0 ZTINextPhase 16-04-2014 2:36:15 PM 0 (0x0000)
    ZTINextPhase processing completed successfully. ZTINextPhase 16-04-2014 2:36:15 PM 0 (0x0000)
    Event 41001 sent: ZTINextPhase processing completed successfully. ZTINextPhase 16-04-2014 2:36:16 PM 0 (0x0000)

    The bdd.log is here: bdd.log

    Any help would be appreciated.

    Wednesday, April 16, 2014 7:28 PM

Answers

  • Thanks for posting your bdd.log to OneDrive (it's super easy for me to view these files using CMTrace <whew!>)

    There are a couple of mysteries here:

    1. While ZTIDiskPart is running, I can see some entries made by ZTIConfigure, which makes no sense. Not sure how this is possible, either an error in the log, or some catastrophic error with the deployment share.

    2. There are a lot of time jumps in the log moving from 12:00 to 2:00. That should not happen. :^(
         If this log is from SLShareDynamicLogging, that could explain it, but it puts the entire log file in doubt.
         Generally I try to avoid SLShareDynamicLogging for just this reason.

    3. Finally this line is also weird:

    //settings[@pass="oobeSystem"]/component[@name="Microsoft-Windows-Shell-Setup"]/UserAccounts/LocalAccounts not found in V:\MININT\Unattend.xml, unable to update.	ZTIConfigure	4/16/2014 2:23:03 PM	0 (0x0000)
    

    There should be a OOBESystem --> Microsoft-Windows-Shell-Setup --> UserAccounts/LocalAccounts section in your unattend.xml file in order for the machine to autologon and complete State restore.

    Notes:

    Ensure that your image has been syspreped. MDT assumes that the OS will be executed from within the UNattend.xml file during OOBE, that only happens if the OS has been syspreped.

    Can you grab the logs directly from the machine (as compare to SLShareDynamicLogging?

    Also check the c:\minint\unattend.xml file, that should be present. It should contain the "<CommandLine>wscript.exe %SystemDrive%\LTIBootstrap.vbs</CommandLine>" command, if not did you modify the unattend.xml file?

    During OOBE setup, the OS will execute the c:\LTIBootStrap.vbs command, verify the file is present. You can also call c:\LTIBOotStrap.vbs once in the full OS. If Litetouch continues, I would blame the c:\minint\unattend.xml file, if it does *not* continue, I would blame th LTI environment (bad scripts caused by an upgrade of the MDT Share?)


    Keith Garner - keithga.wordpress.com

    • Marked as answer by Keith GarnerMVP, Moderator Thursday, April 17, 2014 4:47 PM
    • Unmarked as answer by J. Wall Tuesday, April 22, 2014 7:56 PM
    • Marked as answer by J. Wall Monday, April 28, 2014 5:59 PM
    Thursday, April 17, 2014 4:47 PM
    Moderator
  • Oh you can deploy 32bit images without issue from a 64bit "server" running MDT (I deploy 7 and 8 for both architectures), but you can't build a catalog for a 32bit OS from a 64bit system. You do not need to build a server, simply a 32bit client that can run the latest ADK. Open WISM, then click on File and Select Windows Image. Navigate to your deployment share and then to whichever folder contains the 32bit image you need to build a catalog for. After a few minutes, your catalog is built and you can close out of it.

    You don't have to build a 32bit VM if you don't want to but it can come in handy to have a 32bit VM on the MDT server that you can fire up and is clean, built only to service your 32bit needs.

    FYI the catalog is not the same as the unattend.xml. The catalog will be in the same folder as your WIM, the unattend.xml will be in the control folder
    • Edited by Dan_Vega Tuesday, April 22, 2014 8:07 PM
    • Marked as answer by J. Wall Monday, April 28, 2014 6:00 PM
    Tuesday, April 22, 2014 8:04 PM
  • Wait a minute, if I'm not sysprepping (running unattend.xml) because I've disabled those steps in the TS under State Restore > Imaging and State Restore > Sysprep , should C:\LTIBootstrap.vbs be called after booting into Windows?  Maybe what I'm experiencing is expected behaviour?

    I took your advice and I've created a second deploymentshare, added just what I need to test this netbook thing and I get the same result, it boots into Windows and doesn't run C:\LTIBootstrap.vbs, so that got me thinking this is how it's supposed to work.  Ideas anyone?

    • Marked as answer by J. Wall Monday, April 28, 2014 5:59 PM
    Friday, April 25, 2014 5:06 PM

All replies

  • Thanks for posting your bdd.log to OneDrive (it's super easy for me to view these files using CMTrace <whew!>)

    There are a couple of mysteries here:

    1. While ZTIDiskPart is running, I can see some entries made by ZTIConfigure, which makes no sense. Not sure how this is possible, either an error in the log, or some catastrophic error with the deployment share.

    2. There are a lot of time jumps in the log moving from 12:00 to 2:00. That should not happen. :^(
         If this log is from SLShareDynamicLogging, that could explain it, but it puts the entire log file in doubt.
         Generally I try to avoid SLShareDynamicLogging for just this reason.

    3. Finally this line is also weird:

    //settings[@pass="oobeSystem"]/component[@name="Microsoft-Windows-Shell-Setup"]/UserAccounts/LocalAccounts not found in V:\MININT\Unattend.xml, unable to update.	ZTIConfigure	4/16/2014 2:23:03 PM	0 (0x0000)
    

    There should be a OOBESystem --> Microsoft-Windows-Shell-Setup --> UserAccounts/LocalAccounts section in your unattend.xml file in order for the machine to autologon and complete State restore.

    Notes:

    Ensure that your image has been syspreped. MDT assumes that the OS will be executed from within the UNattend.xml file during OOBE, that only happens if the OS has been syspreped.

    Can you grab the logs directly from the machine (as compare to SLShareDynamicLogging?

    Also check the c:\minint\unattend.xml file, that should be present. It should contain the "<CommandLine>wscript.exe %SystemDrive%\LTIBootstrap.vbs</CommandLine>" command, if not did you modify the unattend.xml file?

    During OOBE setup, the OS will execute the c:\LTIBootStrap.vbs command, verify the file is present. You can also call c:\LTIBOotStrap.vbs once in the full OS. If Litetouch continues, I would blame the c:\minint\unattend.xml file, if it does *not* continue, I would blame th LTI environment (bad scripts caused by an upgrade of the MDT Share?)


    Keith Garner - keithga.wordpress.com

    • Marked as answer by Keith GarnerMVP, Moderator Thursday, April 17, 2014 4:47 PM
    • Unmarked as answer by J. Wall Tuesday, April 22, 2014 7:56 PM
    • Marked as answer by J. Wall Monday, April 28, 2014 5:59 PM
    Thursday, April 17, 2014 4:47 PM
    Moderator
  • Thanks for the help Keith.   More background on this might be necessary.  Normally when I create an image I first upload a non-sysprepped image, then a sysprepped image that actually gets deployed.  The non-sysprepped image I use the next time I need to update my image; I download it, make my changes then reupload another non-sysprepped followed by a new sysprepped image.


    In this case I've uploaded the first non-sysprepped image as a backup, added it to a task sequence and now I'm trying to restore it back to the same machine to make more changes.  I hadn't edited the unattend.xml, but now I just opened the TS > OS Info tab > Edit Unattend.xml and after a minute I get this error.

    When I click the finish button I get another message that says "Unable to edit the unattend.xml for this OS because no catalog could be located or generated" with an OK button.  If I didn't already mention it this is MDT 2012 U1. Does this mean that I cannot deploy a x86 OS from this x64 server?

    Tuesday, April 22, 2014 5:38 PM
  • Two things I'd suggest.

    1. Use Hyper-V to build your reference image. You can make a checkpoint while the task sequence is suspended, then you can roll back to that to add patches, etc. That will solve your issue.

    2. Create a x86 virtual machine with ADK installed. You can then open the WIM file from your deployment share and build the catalog using the VM. Once it's built you can use MDT on your x64 system to edit the unattend.xml from within MDT

    • Proposed as answer by Dan_Vega Tuesday, April 22, 2014 7:09 PM
    Tuesday, April 22, 2014 7:09 PM
  • 1. I understand the benefits of building images on a vm but I've tried that before, I can't remember the reasons now, but I've had problems.  It will be something that I look into again but for now I have this problem to sort out.

    2. Can you please provide more details on this?  In the past I've taken the unattend.xml created by MDT for Win7x64 and edited that with WISM, but I've never created one from scratch.  Can I just plop one of my unattend.xml files for Win7x64 in the TS folder?  Are they specific to the OS?

    Building a new server just to edit an xml file sounds like a lot of work, I find it hard to believe there's not a simpler way.   How do other people to it?   I should add that we're deploying XPx86 from this server now without issue.


    Tuesday, April 22, 2014 7:55 PM
  • Oh you can deploy 32bit images without issue from a 64bit "server" running MDT (I deploy 7 and 8 for both architectures), but you can't build a catalog for a 32bit OS from a 64bit system. You do not need to build a server, simply a 32bit client that can run the latest ADK. Open WISM, then click on File and Select Windows Image. Navigate to your deployment share and then to whichever folder contains the 32bit image you need to build a catalog for. After a few minutes, your catalog is built and you can close out of it.

    You don't have to build a 32bit VM if you don't want to but it can come in handy to have a 32bit VM on the MDT server that you can fire up and is clean, built only to service your 32bit needs.

    FYI the catalog is not the same as the unattend.xml. The catalog will be in the same folder as your WIM, the unattend.xml will be in the control folder
    • Edited by Dan_Vega Tuesday, April 22, 2014 8:07 PM
    • Marked as answer by J. Wall Monday, April 28, 2014 6:00 PM
    Tuesday, April 22, 2014 8:04 PM
  • Thanks Dan, I'll try that.  So is the catalog file the lang.ini?  This exists in the same directory as my wim at this point
    Tuesday, April 22, 2014 9:02 PM
  • It'll end in .clg

    Might be something like: WIN81X86_WIN81X86CDrive.clg

    Tuesday, April 22, 2014 9:14 PM
  • Ok, I've created the .clg file on a Win7 x86 machine, I can open the unattend.xml from the MDT server now (I haven't edited it) but when I image a machine it still just logs into Windows after imaging and then just stops.  The last line in the new BDD.log is "Event 41017 sent: LTI initiating task sequence-requested reboot."

    Regardless of whether I edit unattend.xml the TS should at least still finish correct?

    Thursday, April 24, 2014 5:02 PM
  • Could be some driver problems. I see you're using the MakeModel alias script but according to the log your Acer AO751h is being labeled as unknown.

    Property MAKEALIAS is now = Unknown ZTIGather 4/24/2014 11:31:02 AM 0 (0x0000)
    Property MODELALIAS is now = Unknown ZTIGather 4/24/2014 11:31:03 AM 0 (0x0000)

    Which is leading to a bunch of:
    Skipping Device IDE\DiskST9160310AS_____________________________0303____ No 3rd party drivers found. 6 ZTIDrivers 4/24/2014 11:34:40 AM 0 (0x0000)

    Did the image you captured have any group policies applied to it that might cause interference with MDT's process?


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, April 24, 2014 6:39 PM
  • No the machine the image was captured from was not added to the domain so did not have GPOs applied.

    How did you know it's an Acer AO751h?

    I have the Preinstall > Inject Drivers step set to inject Nothing, at this point I'm just trying to restore my image. I know the Windows 7 inbox drivers will work with this netbook, the only issue is the inbox video driver does not do the native resolution of the display but that's an issue I'll sort out later.

    The reason I'm using a MakeModelAlias script is because we have several Acer models and Acer is not very diligent with populating the Make and Model properties in WMI so I use the MAC address to determine the make and model.  The script is not setup at this point to determine this Acer netbook model using the MAC so MakeAlias is being set to Unknown.  The same goes for ModelAlias.

    This only really comes into play if I had a driver selection profile injecting drivers based on the detected make and model correct?  MDT doesn't otherwise care what the make and model is does it?

    I've commented out the UserExit script temporarily and I'm imaging again just to be sure the script is not the problem.  I'll let you know.

    Thursday, April 24, 2014 7:36 PM
  • The netbook just finished imaging, same issue with the UserExit script taken out of the equation.  The BDD.log is here.

    This is kinda off topic but it's been a couple years since this was setup, once I've created and populated the the MakeAlias and ModelAlias properties these values get written to the built in Make and Model properties later in the customsettings.ini correct?  I see we have this further down in the .ini file:

    [MMSettings]
    SQLServer=imgm
    Instance=IMGMSQLEXPRESS
    Database=MDT
    Netlib=DBNMPNTW
    SQLShare=DeploymentShare$
    Table=MakeModelSettings
    ;Parameters=MakeAlias, ModelAlias
    Parameters=Make, Model
    MakeAlias=Make
    ModelAlias=Model

    MMSettings is commented out at the top of the .ini, and I know this is using the database, which we've never used only experimented with, but this is essentially how we'd populate Make and Model on the Acer models that are populated at the factory correct?

    Thursday, April 24, 2014 8:01 PM
  • I think you have too many half used settings going on there and if it's been a couple years since it was setup you're probably better off just creating a new deployment share. It doesn't take very long to do. For your drivers I'd recommend the "total control" driver management method. http://www.deploymentresearch.com/Research/tabid/62/EntryId/112/MDT-2013-Lite-Touch-Driver-Management.aspx

    Make use of the modelaliasexit script. In the "Check by Make" section of that script you can create your aliases for Acer computers. In the example below you'd then just need to create an Acer folder and then a Aspire One folder inside of that in your Out-of-box drivers.

    Select Case sMake
    
            Case "Acer"
    
                ' Next line is optional use, modelalias with spaces removed
                ' SetModelAlias = Replace(sModel, " ", "")
    
                Select Case sModel
    				Case "AO751h"
    					SetModelAlias = "Aspire One"
    				Case "AO752"
    					SetModelAlias = "Aspire One"
    				Case Else
                        SetModelAlias = sModel 
                        oLogging.CreateEntry "USEREXIT:ModelAliasExit.vbs|SetModelAlias - Alias rule not found.  ModelAlias set to Model value." , LogTypeInfo
    			End Select
    Do this for any models that share the same driver set so that you don't have to make quite so many folders in the out-of-box drivers in MDT. By the way I knew that you deployed to the machine because it's all in the log files.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, April 24, 2014 9:02 PM
  • Also if your MDT server is Imgm.rrdsb.com

    I'd suggest changing the UNC path in MDT to \\imgm.rrdsb.com\deploymentshare$ and change your "DeployRoot=" to match. It'll workout better for you if you ever need to deploy from different subnets.

    Here's some info to help you out more with the modelalias script: http://deploymentbunny.com/2012/05/01/modelalias-user-exit-for-microsoft-deployment-toolkit-20102012/


    If this post is helpful please vote it as Helpful or click Mark for answer.


    • Edited by Dan_Vega Thursday, April 24, 2014 9:16 PM
    Thursday, April 24, 2014 9:11 PM
  • Thanks Dan, I appreciate your help so far.  Rebuilding the deployment share may be worthwhile but do you really think that is the problem here, where State Restore just does not run?

    will say that we do have intermittent issues with another task sequence where *sometimes* the machines will image and arrive at the Windows login screen where we then need to login as local Administrator to kick start the TS to start running again (so a similar issue to this), we'll eventually get to the finish screen this way but it doesn't autoadminlogin as expected. 

    If I create a new deployment share does that mean I need to recreate all my task sequences?  Rebuilding and testing all these doesn't sound fun.  I also have a lot of custom vbs scripts that I use in the State Restore phase to configure our machines.  I can have both deployment shares running at once though right, I'd just have multiple boot images in WDS and then I'd need to select the correct one?

    I'm not at the office now but since we're still on MDT 2012 U1 (not 2013) I don't believe we have the option of using DriverGroups as mentioned on Johan's blog.  Also, our Imgm server only deploys to one subnet, we have several different sites each on their own subnet but they all have a dedicated MDT server.  I have 1 bootstrap.ini file which is setup to choose the proper deployment server based on the IP gateway of the client, then when I replicate from Imgm to our other sites they can all use the same bootstrap file.

    Friday, April 25, 2014 3:33 AM
  • Wait a minute, if I'm not sysprepping (running unattend.xml) because I've disabled those steps in the TS under State Restore > Imaging and State Restore > Sysprep , should C:\LTIBootstrap.vbs be called after booting into Windows?  Maybe what I'm experiencing is expected behaviour?

    I took your advice and I've created a second deploymentshare, added just what I need to test this netbook thing and I get the same result, it boots into Windows and doesn't run C:\LTIBootstrap.vbs, so that got me thinking this is how it's supposed to work.  Ideas anyone?

    • Marked as answer by J. Wall Monday, April 28, 2014 5:59 PM
    Friday, April 25, 2014 5:06 PM
  • Sysprepping is a requirement when taking an image and applying to another machine.

    LTIBootStrap.vbs is excuted from the unattend.xml file, the unattend.xml file is only processed from OOBE phase of setup, and the only way to force the OS to enter OOBE phase upon next boot is to sysprep the machine.

    This is by design.


    Keith Garner - keithga.wordpress.com

    Friday, April 25, 2014 5:17 PM
    Moderator
  • So if my TS is setup like this then I'll never get to the Finish screen correct?


    • Edited by J. Wall Friday, April 25, 2014 6:06 PM
    Friday, April 25, 2014 6:01 PM
  • I apologize for wasting peoples time here, I didn't totally understand how the deployment process works.  My problem is solved.
    Monday, April 28, 2014 5:58 PM
  • Sorry for not getting back earlier as I was out on vacation for a few days. Well glad you tracked it down, as for the driver management I've been doing that since MDT 2010 so yes you can use it in 2012 U1. I'm not sure if you have a MDT server on each subnet due to the amount of machines you have to service but if you use a FQDN for your MDT server you can easily service multiple subnets. That's why I had suggested changing your deployroot path. To help learn more subscribe to the following RSS feeds:
    http://www.deploymentresearch.com/Blog/tabid/62/rssid/1/Default.aspx
    http://keithga.wordpress.com/feed/http://blogs.technet.com/b/mniehaus/rss.aspx

    If this post is helpful please vote it as Helpful or click Mark for answer.

    Tuesday, April 29, 2014 1:44 PM
  • How did you fix it?  Just syspreping your custom wim before capturing?
    Monday, April 13, 2015 11:32 PM
  • Syspreping your custom image is a hard requirement for deploying images through MDT

    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Tuesday, April 14, 2015 12:20 AM
    Moderator
  • The problem ended up being the image was not sysprepped when captured. It was a coworker who captured the image and decided not to sysprep it, when I took over and began deploying the image I was unaware that decision was made, once I learned that it all made sense.
    Thursday, April 16, 2015 7:51 PM